Decommissioning Legacy to Drive Real Clouds, in the Fast Lane

We even might be so bold as to suggest that only using the cloud for test and development is akin to only driving a Maserti GranTurismo MC Stradale in second gear in the slow lane.

For the CIO, this, in theory, heralds a time when cloud computing then starts to deliver guaranteed performance and functionality across all business operations.

This post-implementation side of the cloud chasm (if we may coin the term) is a new realm where we find tools that provide workflow-monitoring functionality to analyze real-time data flows. Application and data integration issues start to come to the fore and system performance can ultimately start to be fine-tuned to (hopefully) eliminate bottlenecks where they exist.

What’s holding us back?

I’m not going to be analyzing the misgivings that companies typically have concerning the safety and workability of a cloud migration, that job card has already been quite comprehensively undertaken. Rather, there is now a need to question whether companies view some sort of decommissioning responsibility before they can make the leap across the cloud chasm.

More specifically, when we talk about decommissioning here we are referring to the fact that legacy software installations aren’t always just about the hardware they run on and the software code that they are comprised of. Not at all – there are deeper "relationships" that bind a business to an automated computer-driven process…

… legacy also means the existing skill set of employees who use and operate systems already in place, legacy means partnerships and third-party integrated systems (where they exist), legacy also means the wider technology infrastructure operated by the firm at any point in time, and legacy IT may also even be tied to a firm’s brand value and market goodwill if a business is just particularly "known and recognized" for doing things a certain way.

What’s the killer app factor here?

We might quite reasonably argue here that the safest way to regard this "legacy-to-cloud decommission migration upward gear shift" is not to have the process forced upon the business at a time dictated by the software itself. This needs to happen before the software simply comes to the end of its useful life or some major IT overhaul or change is forced upon the business as the result of some acquisition or merger for example.

Crossing the cloud chasm need not be the arduous and perilous affair that many a naysayer would have us believe. There are also more granular enabling technologies here such as Virtustream with its micro-VM (µVM) technology, which is designed to wrap around an app without the need for re-writing each and every piece of code.

Company CEO & CTO Kevin Reid says that many believe that it is necessary to re-write legacy apps to make them cloud ready, but this is not true. "With 70 percent of the world’s business applications legacy-based, the fear is preventing many businesses from migrating to the cloud. Plus, there are also fears over where data is ‘up there’ and concerns of being in breach of compliance. Virtustream is able to identify where all data is, down to the node and spindle."

Remember, what are we "migrating" for anyway?

Some cloud relocation should indeed by migration in the sense that we will be looking to replicate previously non-virtualized applications and data storage implementations in their new homes.

But – and it’s a really really big but – some cloud migration shouldn’t be migration at all; it should be "innovation" based on the new more flexible and manageable nature of the cloud model. Plus, it’s worth remembering that not every application and piece of data should move to the cloud anyway due to reasons such as mission-criticality and/or compliance.

Forget migration, sometimes.

Sometimes migration should be innovation and sometimes migration should be anchored immobility – and, sometimes, migration should be migration.