Prepare to Adopt the Cloud: A 10-Step Cloud Migration Checklist

Having been involved in cloud computing for more than a decade, I’ve heard from many IT executives working to move key enterprise applications to the public cloud. In several cases, their teams have struggled or had only limited success in their cloud migrations. But they never gave up and they used the lessons they learned to improve results in subsequent attempts. If your organization is looking to modernize mission-critical applications and you’re planning a cloud migration as part of this process, you don’t want to repeat the mistakes of others.

So this post leverages those learnings to build a 10-step checklist of the major areas you need to consider and address to maximize your chances of a successful cloud migration.

Step 1: Establish the Migration-Architect Role

Before you begin your cloud migration, establish the migration architect role to lead the effort. The migration architect is a system architect-level position responsible for planning and completing all aspects of the migration. Their core responsibility should include defining the necessary refactoring required to make the migration successful, designing strategies for data migration, defining cloud-solution requirements, and determining migration priorities and production switchover mechanisms.

During the course of a large migration project, there are many decisions and technical plans that must be made, and having a migration architect who is responsible for all aspects of the migration is critical to the success of the project.

Step 2: Choose Your Level of Cloud Integration

When you move an application from an on-premises data center to the cloud, there are two ways you can migrate your application — a shallow cloud integration or a deep cloud integration.

For a shallow cloud integration (sometimes called “lift-and-shift”), you move the on-premises application to the cloud, and make no — or limited — changes to the servers you instantiate in the cloud for the purpose of running the application. Any application changes are just enough to get it to run in the new environment. You don’t use cloud-unique services. This model is also known as lift-and-shift because the application is lifted “as is” and moved, or shifted, to the

For a deep cloud integration, you modify your application during the migration process to take advantage of key cloud capabilities. This might be nothing more advanced than using auto-scaling and dynamic load balancing, or it might be as sophisticated as utilizing serverless computing capabilities such as AWS Lambda for portions of the application. It might also involve using a cloud-specific data store such as Amazon S3 or DynamoDB.

Step 3: Choose a Single Cloud or Go Multicloud

Before you begin your cloud migration, address this question: Do you want to pick a single cloud provider and migrate your application so it runs optimized for that single environment, or do you want your application to run on multiple cloud providers?

Optimizing your application to work with a specific cloud provider is relatively simple. Your development teams have just one set of cloud APIs to learn and your application can take advantage of everything your chosen cloud provider offers.

The downside to this approach is vendor lock-in. Once you’ve updated your application to work with only that one provider, moving your application to a different provider could require just as much effort as the original cloud migration. Additionally, having a single cloud provider might negatively impact your ability to negotiate important terms — such as pricing and SLAs — with the cloud provider.

But wait, it gets even more complicated. There are several different models for using multiple cloud providers:

One application in one cloud; another application in a different cloud. Perhaps the simplest multi-cloud approach runs one set of applications in one cloud provider and another set in another. This approach gives you increased business leverage with multiple providers, as well as flexibility for where to put applications in the future. It also lets you optimize each application for the provider on which it runs.

Split your application across multiple cloud providers. Some companies choose to run parts of an application in one cloud provider and other parts of it in another. This approach lets you utilize key advantages each provider offers (for example, one provider might have better AI capabilities and another might be known for its database speeds). The risk here is that your application is tied to the performance of both providers, and any problems with either provider could impact your application’s customer experience.

Build your application to be cloud-agnostic. Other companies build their applications to run on any cloud provider. With this approach, you could run your application simultaneously on multiple providers or split your application load across them. This model gives you the ultimate flexibility in vendor negotiations, because you can easily shift loads from one cloud provider to another. The downside is that you may find it difficult to use the key capabilities of each cloud provider, reducing the benefits of hosting your application in the cloud.

Step 4: Establish Cloud KPIs

Key Performance Indicators (KPIs) are metrics that you gather about your application or service to measure how it is performing against your expectations. The best KPIs for a cloud migration show how your in-progress migration is doing, illuminating visible or invisible problems that may be lurking within your application. Most important, perhaps, cloud migration KPIs can help you determine when the migration is complete and successful.

There are several key categories of cloud migration KPIs:

For each category, determine which metrics are the most important to your business and which metrics will be most impacted by the migration to the cloud.

Read more…