Is your business looking to upgrade some of your IT applications and planning to migrate to the cloud as part of your operation? Then look no further. Our 10 Step Checklist will help you tick off the major areas you need to consider and to address during the whole process. Pooled together using the lessons learnt from those who have gone before us, importantly, created to increase your chances of a successful cloud migration.

The cloud migration checklist includes

1. Establish the migration-architect role

2. Choose your level of cloud integration

3. Choose a single cloud or go multi-cloud

4. Establish cloud KPIs

5. Establish performance baselines

6. Prioritize migration components

7. Perform any necessary refactoring

8. Create a data-migration plan

9. Switch over production

10. Review application resource allocation

Step 1: Establish the migration-architect role

Select a migration architect who will lead the process, being responsible for all facets of the migration. The position involves planning and finalising the migration firstly by, defining necessary refactoring required to make the migration successful. Secondly designing strategies for data migration. Thirdly, defining cloud-solution requirements. And lastly, determining migration priorities and production switchover mechanisms. In other words, the migration-architect role is key to the success of your project as there are many decisions and technical plans that must be formed.

Step 2: Choose your level of cloud integration

There are two ways to migrate an application during the move from an on-premise data centre to the cloud.

The first way to move to the on-premise application to the cloud, is called shallow cloud integration (sometimes called “lift-and-shift”) It involves making little or no changes to the servers you instantiate in the cloud for the purpose of running the application. Any changes that are made are minimal. They’re done just to get the new environment up and running. So, there’s no need to use cloud-unique services. The move is an “as is” move, basically a “lift and shift”

In contrast, the second move called a deep cloud integration, is where during the migration process you can modify your application, taking advantage of the key cloud abilities. For example, using auto scaling, and dynamic load balancing. Or utilizing serverless computing capabilities such as AWS Lambda for portions of the application. In addition, it might involve using a cloud-specific data store such as Amazon S3 or DynamoDB.

Step 3: Choose a single cloud or go multi-cloud

Prior to starting your migration to the Cloud, do you want a single-cloud provider (runs optimized for that single environment) or an application to run on multiple cloud providers?

Having one single provider has its benefits like, just having to learn one set of cloud APIs and your application can take advantage of everything your single cloud provider offers. On the other hand, the drawbacks include vendor lock in, secondly, moving your application to another vendor maybe just as much work as the original migration. In addition, a single cloud provider might prove difficult when it comes to pricing and service level negotiations.

For the multiple cloud providers, there are three different models, so it gets a little more complex.

1. One application in one cloud; another application in a different cloud.

This approach runs one set of applications in one cloud provider and another set in another. And therefore, the simplest approach, that enables increased business leverage and future flexibility to change providers for an application.

2. Split your application across multiple cloud providers

This approach has you running parts of an application in one cloud provider and other parts of it in another. In other words, splitting your application across multiple cloud providers. The benefit is you can use the advantages each provider offers. For instance, one provider might have better database speeds than another) Because a single application is now tied to the performance of two providers, if there’s any problems with your providers, this could prove risky. It can cause a negative effect on your customer experience.

3. Build your application to be cloud agnostic.

This is a more fluid approach as companies build their applications to run on any cloud provider. To clarify, you can run your application at the same time on multiple providers or split your application load across them. This has the best negotiating power with your vendor on price and service level, as the load can easily be moved from one provider to another. This model more complicated, especially effecting the application-development and validation processes. The other thing to consider is trying to sort through the best solution from each provider to suit your applications.

Step 4: Establish cloud KPIs

It is a matter of good practice to measure how migration to cloud is working – your expectations vs performance. Key Performance Indicators KPIs, information that you gather about your application or service, should show;

• how your in-progress migration is doing
• visible or invisible issues that may be hiding within your application
• if they still the right KPIs for an application or service, once it’s in the cloud
• determine when the migration is complete and successful

There are several important categories of cloud migration KPIs

Category	Sample KPI (metrics)
User experience	Page load time Lag Response time Session duration
Application/component performance	Error rates Throughput Availability Apdex
Infrastructure	CPU usage % Disk performance Memory usage Network throughput
Business engagement	Cart adds Conversions and conversion % Engagement rates

Determine in each category which metric is most important for you, and the think about the how this might be affected, once moved to the cloud.

For tips on identifying metrics to define your KPIs, take a look at tutorials on planning your cloud migration.

Step 5: Establish performance baselines

How is your application performing pre-migration? The result is the baseline for determining application performance post-migration. The baseline will help decide whether the post-migration performance is acceptable and completed. It helps evaluate and diagnose any issues that arise.

• set a baseline metric for each KPI that you’ve decided to measure
• Determine how long you will collect data to determine the baseline.
• Choosing a short baseline period (such as a day) lets you move faster
• Choosing a longer period to baseline (such as a month) is representative data
• determine if you want to collect only baseline data that’s average or representational, or if you want to include data collected over “peak” or “critical” period

Importantly, clearly define what type of data you’re going to collect and for what period of time.

Take a look at tutorials on planning your cloud migration for further details.

Step 6: Prioritize migration components

How will you migrate your applications to the cloud? All at once, or component by component or service by service.

Firstly, look at the connections between your services, and which services depend on what other services. For the larger applications, use a monitoring application such as New Relic APM that can use service maps to generate dependency diagrams. Secondly, use the dependency diagram to decide which components should be migrated and in what order.

Step 7: Perform any necessary refactoring

To make sure your applications work effectively and efficiently in the cloud, you may want to refactor your applications prior to migration;

• So it works effectively with a variable number of running instances to allow dynamic scaling, potentially saving you money on cloud service costs.
• So your resource utilization can better take advantage of dynamic-cloud capabilities, such as the ability to dynamically allocate and de-allocate resources as needed, rather than you statically allocating them ahead of time.
• To move to a more service-oriented architecture before the migration, so that you can more easily move individual services to the cloud.

Step 8: Create a data-migration plan

We recommend you create a data-migration plan before starting, as migrating data is one of the difficult steps of your cloud migration. Moving your data to the cloud when the data-access methods are still primarily on-premises can notably impact performance.

Options for data migration include:

• Using a bi-directional syncing mechanism between your on-premise and cloud databases. Once you’ve moved all consumers of the data to the cloud, remove the on-premise database.
• Use an on-premise database with one-way synchronization to a cloud-based database, and allow consumers to connect only to the on-premise version. When you’re ready, disable access to the on-premise version so the cloud-based version becomes the main database, and enable cloud-based consumers access to the new database.
• Use a cloud data migration service, such as those available from Amazon Web Services and Microsoft Azure.

Keep in mind your migration architect should be across the data-migration planning process as part of their role.

Step 9: Switch over production

Next you need to decide, when and how you switch over from the current on-premise solution to the new cloud version. It will depend on the complexity and design of your application, especially the design of your data and datastores.

There are two common approaches:

Do it all at once.

1. Move the entire application or service over to the cloud

2. Test to make sure it works

3. Then switch traffic from the on-premise stack to the cloud stack.

Do it a little bit at a time.

1. Move a few customers over

2. Test that things are working,

3. Then move a few more customers.

4. Continue this process until you’ve moved all your customers to the cloud-based application

Step 10: Review application resource allocation

Once you’ve made the switch and finished migrating everything to the cloud, there are a few more things to consider. Firstly, and most importantly is resource optimization. As you move into the cloud, which is optimized for dynamic resource allocation, make sure your teams have a plan for distributing resources to your application. You need to ensure your taking advantage of the cloud’s strengths especially when you allocate resources (servers, for example) statically.

Secondly, allocating additional resources to an application in the cloud, are generally available instantly and in quantities as per your requirement from your provider. In other words, you can scale as needed to meet the demand. That’s assuming your teams have the application architecture in place to support dynamic scaling.

Other considerations for your cloud migration

Although we’ve ticked off a lot on preparing to adopt the cloud in the last 10 steps, there are still other things to consider during your cloud migration. Firstly, creating a safe and secure cloud environment is paramount in any cloud migration. Secondly, cloud costs which can vary depending on you calculate it. For more on the topic of cloud costs, check out How to Calculate the Cost of a Cloud Migration. In addition, if you’re serious about planning a cloud migration, research topics like building modern applications using services and microservices. For example twelve-factor applications, and using DevOps methods and procedures as best practices for building and running cloud services and applications.

Finally, make sure to optimize your customer experience once you’re fully migrated to the cloud. How are your customers experiencing your service?