Successful Cloud Migrations: Making the Leap

You probably don’t know this, but the cloud as we know it today was first defined by the then-CEO of Google, Eric Schmidt way back in August of 2006. If we’re being honest with ourselves, nobody took this idea seriously (at least not in any practical sense) until MUCH later.

A mere five years down the road, the cloud was achieving relevance and a lot of thought went into the implications of moving legacy applications to cloud platforms. In fact, many of the lessons learned previously in terms of platform migration still apply today.

And as I’ve shared in this forum before, nothing is ever easy, and once you’ve decided to take the cloud leap, the real work begins.

Every successful migration effort requires not only the development of a comprehensive strategy in support of the migration, but also forces making sometimes difficult decisions up front. The most tempting decision is to skip this step all together and dive right in to migration activities, but that “easy” decision can doom a cloud move to failure.

IT professionals that have adopted a best practices model start with an understanding of the desired outcome and a mechanism to both validate and measure success in the journey. From that point, adequate assessment of which applications to migrate and an understanding of the migration goals (e.g. improved performance, reduced latency, scale) can be achieved.

Phase I – Do You Really Want to Do This?

With all of its hype and promise of lower cost models, not every business, nor every application should move to a cloud framework. Don’t get me wrong, many apps are well suited to cloud deployments and some are easier to move than others, but a careful consideration of the business implications is required. All too often, I’ve heard horror stories of an executive ordering IT to “move to the cloud” without a good understanding of what that means…and if you are like me, there is NOTHING better than a good understanding. A better approach is to develop a real business case with respect to the goals you set in your overall strategy. Answer the question, “Why am I doing this?” And, honestly, if the allure of cost savings is the only metric being considered, you might be making a mistake.

Phase II – What Should I Move and Why?

Different professionals call this stage a variety of names, but it’s really about taking inventory of your existing environment. For example, if you have the benefit of running your application in a VMware framework in an on-premises environment, and you are looking for additional scale, taking advantage of the combined F5/VMware/IBM Cloud offering just announced may be right up your alley. By offering a validated solution that leverages not only F5’s BIG-IP suite of virtual services but the automated provisioning and integration with the IBM Cloud for the VMware Solutions portfolio, we make movement to the cloud much easier.

Some benefits to taking advantage of this solution include:

• Scalable application delivery for reduced downtime
• Leverage of existing investments in F5 programmability to reduce time to market
• Eliminate obstacles to rapid workload deployments
• Provide workload portability between on-premises and the IBM Cloud
• Eliminate downtime with seamless application failover
• Consistent application of F5’s enterprise grade performance, availability, and security services

If you are operating within a different framework, give careful consideration to underlying support facilities (e.g. compute, storage, infrastructure) and restrictions associated with software licensing.

A good rule of thumb during this phase is to really think about the application itself (in addition to what it takes to run it). While it may make sense to move an application that was developed only a few years ago, it likely makes less sense to try and move your application that has been around for a decade. Never forget about the burdens of technical debt – yes, it’s an over-used term these days but the real challenge is the domain-specific knowledge required to make it run normally, let alone in a new frontier. Like CTR/IBM’s Thomas Watson said back in 1911, “THINK!” and you’ll be okay.

Phase III – “I’m Going For It!!!”

Design. Design. Design. Migrate. Validate. Repeat. If you follow this simple advice your chances of success are high. Many enterprises today have adopted a CI/CD (continuous improvement, continuous delivery) strategy for their cloud roll-outs.

Most efforts start with an application that is relatively simple in nature and learn from there. I, too, find this approach to be most effective even when used within my own team. The iterative process lends itself to rapid and continuous improvement in both products and services – in this case, your applications success in the cloud. And after some success with your first move, they’ll get easier as you learn.

Of course, be sure you have a strategy outlined for testing the newly deployed application and shutdown of the legacy system(s) once you’ve sure things are running as they should and that the universe hasn’t ended.

My last advice for this phase…I’ve personally found the best (and most successful) deployments are those where both the application development and the network operations teams are well aligned and work together throughout the whole process.

Phase IV – Adopt Modern, Cloud-Oriented Practices

As your first step in the cloud journey, and as your first application is migrated away from those legacy systems you abandon, keep in mind that modern IT is about systems-level thinking, not task-level engagement. Become a button creator, not just a button pusher.

In my next post, I’m going to give you some more specific ideas on actual migration options. Stay tuned.