Today, organizations of all sizes are interested in a technology model that fully embraces the transformational promise of the cloud. But if they approach cloud migration the wrong way, they are destined for disillusionment. Simply migrating workloads to the cloud with great anticipation—but with no strategic plan—and then sitting back and waiting for magic doesn’t work. These folks are left wondering why they aren’t achieving the promised benefits: Where is the cost reduction? The dramatic improvement in scalability? The ease of maintenance?
Don’t blame the cloud! The fault is in the migration approach. In my broad experience working with customers on cloud transformation projects, disillusionment primarily results from taking one of two misguided paths:
- Customers take a simple lift and shift approach to cloud migration without any kind of effort to optimize for the cloud, and stop there. While simple lift and shift can work for a small subset of applications where outages or downtime won’t cause big problems for the business, that approach doesn’t take into account uptime, tuning, monitoring, automation and a whole host of other factors that affect most workloads.
- Companies go all out and try to cloud-optimize all of their workloads all at once—and then everything falls apart. You’d think an aggressive approach to optimization would work, but it doesn’t. Companies need to do some basic foundation work and prioritize their workload migration before they move on to advanced optimization, or else they won’t succeed with cloud adoption.
To have a successful and operationally meaningful migration, the best approach is to envision cloud optimization as a lifecycle with five stages. Every workload or application needs to move through each stage in order to be fully cloud optimized and deliver benefits to the business.
- Lift & Shift – This is the foundation for the lifecycle. It’s about making sure an application runs in the cloud at the most basic level. Cloud migration starts here, but shouldn’t end here.
- Operations – At this stage, we can implement operational monitoring and application monitoring. Now the application runs smoothly in the cloud and is constantly checked for status, scaling requirements and problems.
- Assumptions – Next we examine how the application operates in a cloud model, challenging assumptions about the environment and implementing core SLA requirements. The goal of this stage is to reshape the architecture that supports the application, without changing the application itself (which happens, but in Stage 5). In Microsoft Azure, an example would be the implementation of a SQL cluster as opposed to a single SQL server.
- Tune – Tuning is essential to allocating cloud resources efficiently and cost-effectively. For example, ensuring the application has enough compute power without overspending. This stage also includes tuning for automation, which is an important driver for cloud benefits.
- Cloud Optimization – The final stage involves application refactoring to create fully cloud-optimized applications. The goal is to transition from the Infrastructure as a Service (IaaS) part of the cloud stack, to Platform as a Service (PaaS) where cloud provides an ongoing, flexible application development platform.
In terms of timing, one application can take a few weeks to complete, and an entire data center with multiple applications can take months to fully cloud optimize. The good news is that the process will get faster over time since automation and tuning practices you implement in initial rounds can be reused for subsequent workloads. I know it’s tempting to transition multiple applications at once, but I recommend tackling individual applications and workloads to complete the process successfully. Taking your time and following this staged strategy will allow you to gain the full complement of cloud benefits.