The pressure for IT leaders to support more workloads and remote staff with limited resources is as contagious as the pandemic. The most powerful tool in their arsenal is to migrate to the cloud with the caveat that while the move there is a no-brainer, landing there safely takes planning and preparation.
For all new applications and workloads, cloud-native is the way to go. Most enterprises don’t have that luxury—they must migrate existing applications and legacy systems to the cloud. It isn’t as easy as just moving code from one server (on-premises) to another (in the cloud). There’s additional work involved to extend, enhance, and re-write portions of your applications—and that’s the work of cloud transformation—the planning and preparation I mentioned.
So, let’s break down what it takes to get there in 7 steps—to take a cloud-smart rather than cloud-first approach to your migration. These steps focus more on the how, rather than just the what, and drive an outcomes-based approach to get optimal benefits from performance, cost, and risk perspectives.
Step 1: Set your goals and priorities
Migrating to the cloud is a means to an end, not a goal in and of itself. It’s how you enable the digital transformation that will deliver your anticipated business benefits. For example, not all workloads belong in the cloud. Your cloud transformation initiative will have IT-centric decision points and metrics, but those should be made within the context of the business goals and priorities of the transformation with a sharp eye on desired business outcomes. Don’t get distracted by the complexity of the execution or the end goal of a full cloud migration, because that may not be what’s best for your workload performance.
Step 2: Evaluate your options
The best path to the cloud depends on a variety of factors and will drive the level and type of transformation work required as described below.
- Lift and shift or rehosting: Moving an existing application workload along with other dependent workloads over to a cloud environment. It requires the least amount of transformation but could result in overprovisioning and other issues that make your cloud deployment sub-optimal.
- Extend to the cloud: Existing workloads are extended to use cloud service resources when needed. This approach primarily focuses on cloud resources for compute and storage.
- Cloud-optimized: Requires rearchitecting and rewriting parts of an application to take advantage of more advanced cloud services while keeping the core of the existing application intact.
- Cloud-native: Replace an application with a new one that’s architected and written specifically to fully leverage all aspects of cloud deployment.
- Replace with SaaS: Existing applications are replaced with a SaaS offering. This may be more appropriate for non-core applications (think HR, billing, Salesforce management, etc.) than those that are central to your make-or-break competitive strategy.
Step 3: Discover your inventory and inter-dependencies
Regardless of the migration path, eventually some workloads must move from on-premises or private-cloud deployments into the public cloud. Given the complexity of modern IT environments, it may not be obvious which workloads need to be migrated to avoid breaking dependencies. Workload inter-dependencies also help determine the sequences of migration, and even what should stay on-premises. But it’s not enough to just build an inventory. You want to characterize those workloads to measure utilization and performance, and to identify any ongoing issues with your current hosts or VMs. This information enables you to create a baseline assessment of the health, utilization, and performance of the target environment—and it’s critical to understand this before you begin migration.
Step 4: Profile your workloads
The next step is to develop initial cloud configurations with associated cost analysis. But if the workloads from step 3 number in the hundreds or thousands, you first want to group them. Using the workload characterization data, you can cluster workloads with similar resource, utilization, and time-based characteristics to create affinity groups, significantly condensing the complexity and scale of the profiling process. Next, create a representative workload for each affinity group from which to make your candidate cloud configuration choices and build initial cost estimates.
Step 5: Test and refine your configurations
Test your proposed configurations and understand the performance and cost impact of variations before making any financial commitments. “Play back” the profiles of the representative workloads at a high fidelity to validate the cloud configuration meets desired performance levels while minimizing cost. Iterate to refine selections. At this point, you know the conditions of migrating workloads and where they are coming from and the conditions they’re going into. It’s move time.
Step 6: Monitor and optimize
Your work isn’t done. Verify that the application’s performance and utilization are meeting expectations. If there are deviations, create a plan to remediate the issues. Continue monitoring on an ongoing basis. As business evolves workloads evolve, so cloud offerings and costs change frequently. Uncover potential issues before they become big problems, and look for opportunities to optimize to keep your cloud infrastructure right sized and cost efficient over the long-term.
Step 7: Measure and quantify results
You’ve now successfully executed your cloud transformation initiative to support the business goals and priorities from step 1. Don’t forget to capture and report on metrics that tie results directly back to the objectives that the business cares about for a successful cloud experience.
We know this time has been anything but easy for most but taking advantage of the benefits of cloud does not need to be one of the many headaches you’re facing.
By Scott Leatherman
