By Mark Mitchell

Most are familiar with the notion that it is the journey, not the destination, that matters. It rings more loudly than ever for CIOs and IT managers today as they confront the daunting task of migrating to the cloud. The capabilities, constraints and cost of migration --- manually or otherwise --- more than define what can be done; whether one likes it or not, migration IS the gateway enterprise passes first. Migration is the Journey.

There has been a lot of discussion on WHY organizations have and will increasingly adopt cloud; valuable discussion for sure. But myopically focusing on WHY --- be it a move to a public, private, or hybrid environment --- loses sight of the simple fact that HOW one begins the steps of migration to the cloud matters most. That is fundamentally a determination of what migration approach or solution will be used. Having just come through the summer circuit of IT conferences, it is abundantly clear CIOs and IT managers are now setting into this journey. They want a real and credible answer to HOW to migrate legacy servers into the cloud within a range of scenarios.

The follow-up questions are real and matter. Which source environments? Physical, virtual, cloud? x86, Windows, Linux? Are agents or run times used? Are servers stopped during the migration and how do I deal with cut overs of continuous services? Which template and what if it is a square peg / round hole? Which target environments? What about security? Should we re-architect everything from the ground up first natively? Can my IT resource handle this? What is the cost of all this? Are there recurrent fees? Are we locked in to this target forever? What if requirements change? Is a broader “cloud” transformation plan needed first? What remains on premises or in a private cloud? How to federate into a hybrid scenario? And, oh, what about OpenStack?

The questions are neither few nor trivial. It may seem a bit more nightmare than proverbial journey.

I’d offer better framing the HOW question around the following three pillars of decision to make the journey a good one:

1. Minimize Lock-In. The migration approach should be the antithesis of “lock-in” – it should accommodate and enable a range of sources, targets, federation of environments and approaches and indeed be the foundation for flexibility in cloud adoption now and over time.
2. Low, Elastic, Fee Structure. The cost of migrations should be a function of one’s need and success, it should be elastic – this is the cloud after all and cost should be measured by low “by the drink” fees only as consumed.
3. Minimize Change (But Get To The Cloud Rapidly) and Continuously Improve. The approach taken should accommodate and support brownfield server migrations, and not be a compromise such as requiring a template or shim in the target, much less, requiring the first step to be re-building everything from the ground up natively for cloud. Yes transformations are a good thing but taking baby steps, managing tribal knowledge in server stacks, matters more. Get to the cloud rapidly and then continuously improve.

Yes, WHY one looks to the cloud matters. Yes, the target matters. Certainly lowering operating expenses or capital investment are the outcomes. But attending to the three pillars will ensure that the decision is smart in the short and long run.