Cloud Migration Checklist: 8 Steps to Ensure a Smooth (and Safe) Cloud Journey

Moving mission-critical apps and data to the cloud is a massive project that requires in-depth planning if you hope for a high ROI. Without a sound strategy, your cloud migration will likely cause more profit losses and headaches than business benefits.

This article offers a cloud migration checklist that ensures your move to the cloud goes smoothly, safely, and without unpleasant surprises. You can use our checklist as a baseline for the migration process as the step-by-step plan below covers all major aspects of moving an app to the cloud.

Cloud Migration Checklist

Struggling with cloud migration is a common problem for businesses. Recent studies reveal that 55% of cloud migrations either run into significant delays or go over budget.

Also, 62% of organizations currently transitioning to the cloud describe the process as either difficult or failing. Most of these companies rush into the transition without thoroughly considering:

• The total cost of ownership (TCO).
• How the team will move massive amounts of data and mission-critical apps to the cloud.
• Different options for cloud deployments and integration.
• Potential new cybersecurity risks.
• How prepared the in-house team is to operate in the cloud.

The cloud migration checklist below ensures you consider these factors before the team starts moving apps and services to the cloud.

Choose a Go-To Migration Architect(s)

Cloud migration involves numerous technical decisions and plans, so you must designate a single specialist or a team of experts to lead the effort. Whether you go with one or more staff members, the role of a migration architect is to:

• Evaluate services to see whether they better fit on-prem or cloud hosting.
• Create a timeline for the migration and the cloud roadmap.
• Design optimal strategies for moving data and apps.
• Identify and oversee necessary app refactoring.
• Determine migration priorities.
• Define the required toolchain.

The dedicated architect should also provide a complete picture of your IT. This process involves answering the following questions:

• What apps do you have, and who uses them (and how often)?
• How business-critical are apps you're looking to migrate?
• What resources do programs consume, and do they depend on other apps?
• What SLAs, business continuity measures, and compliance measures are currently in place?
• Are there performance issues that are affecting current operations?

Depending on the analysis, the migration architect should assess whether your current workforce has the necessary know-how to:

• Perform the migration.
• Operate in the cloud environment.

Never start the transition to the cloud unless you are sure your team can thrive in the new setting.

The dedicated migration team should also determine the total cost of ownership (TCO) to illustrate the ROI of cloud migration. The TCO assessment for cloud migration includes factors such as:

• The overall cost of migration.
• Post-migration cloud costs (primarily the price of bandwidth and networking).
• The cost of staff training.
• Regular post-migration maintenance.
• The cost of potential downtime.
• Space, cooling, and electricity costs (for an on-prem private cloud).

Set Migration Goals and KPIs

The next step is to establish the migration's primary objective(s). Some common high-end goals are:

• Modernizing a legacy app.
• Speeding up a particular service.
• Improving operational capabilities.
• Increasing system resiliency.
• Enhancing user experience.
• Achieving better service scalability.
• Reducing running costs.
• Improving data security.

Besides the general goal, the team should define cloud migration Key Performance Indicators (KPIs). These metrics will measure how a migrated app or service performs against expectations. There is no limit to the number of KPIs your team can track, but all metrics fall under one of two categories:

• KPIs you follow during the migration process.
• Post-migration KPIs.

Here are the most common KPIs a business can keep track of during the migration process:

• Duration of the migration (both as a whole and per app).
• Availability of critical services.
• Downtime length of services and data centers.
• Degradation of service due to downtime.
• The number of generated service tickets.
• Cost of migration.

Let us look at some post-migration KPIs that your team can track:

• Infrastructure KPIs (CPU usage, service memory footprint, disk performance, load balancing, latency, network throughput, etc.).
• App performance metrics (error rates, number of time-outs, the average response time (ART), the peak response time (PRT), uptime, availability, etc.).
• User experience KPIs (number of request spikes, HTTP status code errors, thrown and logged exceptions, lag, response times, etc.).
• Business impact metrics (duration of the check-out process, subscribe and unsubscribe rates, engagement rates, etc.).
• Cost KPIs (monthly billing, staffing costs, third-party tools, consulting costs, etc.).

You need to set a baseline value for every KPI before deciding what to track. Baselining is the process of measuring the current (pre-migration) state of an app and service. These KPIs enable you to determine whether post-migration performance is acceptable or not.

Perform Data and App Assessment

Data assessment is a vital step of this cloud migration checklist as moving data is typically the trickiest part of adopting the cloud. Carefully assessing data enables your team to evaluate:

• Data risk levels.
• The volume and type of data you plan to migrate.
• Overall data resilience.
• Legal data privacy requirements (if any).
• Most significant threats to data integrity.
• Potential post-migration data breach or leakage scenarios.

Where your data resides can impact the performance of an or and service. Moving data to the cloud when the data-access methods still operate on-prem can significantly affect performance. The same holds true if the database is still on-prem but the service accessing it resides in the cloud.

Besides evaluating data, your on-prem apps should get the same treatment. Before migrating, the team should create an inventory of all on-premises apps and their servers. You should also assess any current virtual machines and account for potential app dependencies.

As a result, you can determine which apps require refactoring before moving them to the cloud. The team can also start prioritizing which apps to migrate first.

Evaluate Cloud Migration Options

The next step of the cloud migration checklist is to assess which apps require what type of integration with the cloud. You have two options:

• Shallow cloud integration (a.k.a. lift-and-shift): When you lift and shift an app, you make little to no changes to the code and set the app up in the cloud more or less in its current shape. Migrating an app without any changes is known as rehosting; making minor alterations when moving an app to the cloud is refactoring.
• Deep cloud integration: Unlike its shallow counterpart, deep cloud integration requires you to modify the app to take advantage of cloud features. The changes can range from relatively simple adjustments (such as setting up auto-scaling and dynamic load balancing) to advanced updates (such as enabling serverless computing) that make the app a cloud-native solution.

Shallow cloud integration is a significantly faster option than refactoring major portions of an app. In general, mission-critical apps are typically worth the effort of deep integrations. Less vital apps and services can do with the shallow approach as you can refactor them over time after you migrate to the cloud.

Companies also often decide to retire or retain apps when assessing which service requires what type of integration:

• Retiring is the process of identifying an obsolete app or service that holds no value if uploaded to the cloud.
• Retaining is the decision to keep an app on-prem, typically due to a security or compliance concern.

Choose the Right Cloud Deployment Model

Choosing a suitable cloud deployment model is vital to successful cloud migration. Different models fit different use cases, and the five options you can choose from are:

• Public cloud (a multi-tenant environment that provides access to compute resources over the Internet or through a dedicated direct connection).
• Private cloud (a single-tenant system in which an enterprise runs cloud resources within its own data center).
• Hybrid cloud (a mix of on-prem systems, public, and private clouds in which workloads move between environments via automation and orchestration).
• Multi-cloud (a mix of two or more public cloud IaaS environments).
• Community cloud (infrastructure shared between several companies with shared needs or concerns).

What deployment model you should use depends mainly on your business's unique needs and goals. Here are a few pointers:

• The public cloud provides a scalable environment with a pay-per-usage model. While highly scalable, the public cloud may not be ideal for sensitive workloads.
• A private cloud is perfect for a company with the budget to run an on-prem cloud environment custom-tailored for its mission-critical workloads.
• A hybrid cloud enables you to run sensitive workloads on-prem while also taking advantage of public cloud scalability during spikes in demand.
• While highly beneficial when done right, there are some hybrid cloud challenges you need to be aware of before designing a hybrid architecture.
• Multi-cloud is an excellent choice for firms concerned with vendor lock-in or companies looking to mix and match services from multiple providers.

Choose a Cloud Service Provider

Unless you opted to set up an on-prem private cloud, the next item on the cloud migration checklist should be to find a cloud provider. While most vendors offer similar services, they are not all the same. Some key considerations when choosing a cloud provider are:

• Pricing.
• Services selection.
• Availability in specific regions.
• Uptime guarantees.
• Your in-house team's familiarity with the provider's tech stack.
• Industry-specific compliance requirements (e.g., keeping user data in the location of origin according to CCPA or GDPR).
• Post-migration support and managed IT services.

Remember that the most popular service providers are not always the best fit. Prominent vendors aim to meet a broad set of needs, so they do not always make for a good match with a company in a specific vertical.

For example, a company that operates in healthcare might be better off partnering with a niche provider that better understands and supports compliance with HIPAA.

Perform Necessary Refactoring

Once you know what cloud deployment you need and who to partner with, your team should start making the necessary changes to apps and services before you migrate them to the cloud.

The goal is to make the software work as effectively and efficiently in the cloud as possible. For example, your team may refactor an app to:

• Work with a variable number of running instances to allow near-instant scaling.
• Take advantage of dynamic-cloud capabilities (such as the ability to allocate and de-allocate resources per current needs).
• Create a more service-oriented architecture to quickly move individual services to the cloud (both this time and down the line).

Now is also the right time to rethink governance and security. You will likely need to adjust your governance strategy to rely less on internal security and control, and more on the provider's cloud services. In terms of cloud security, you need to:

• Assess whether the migration can result in new vulnerabilities.
• Understand how your in-house team will work with the provider to keep cloud assets safe.
• Adjust (and potentially improve) your current security measures and practices.
• Decide whether you can benefit from additional security tools the provider offers.
• Set up failover and disaster recovery mechanisms.

Methodically Migrate and Switch Traffic over from On-Prem Operations

While you can migrate everything to the cloud all at once, this approach can be challenging and risky to pull off. Instead, you should migrate apps and services one by one, starting with less critical apps and slowly making your way to the crucial ones.

Here's what this approach to migration should look like:

• Prioritize apps that your team can move with the least amount of risk to operations. Good choices are apps that require only rehosting or use minimal resources (such as low storage or computations).
• Then, start moving apps that hold high value to your business but present a relatively low risk during migration.
• Finally, leave the mission-critical and disruptive workloads for the final stages of migration. Never start moving these apps unless the ones from previous steps are working optimally.
• Use a manual or automated test (or both) to check if the migration was successful or not.

Depending on the architecture of your apps and datastores, you can switch traffic over from the on-prem solution to the cloud in two ways:

• All at once: The team switches all on-prem traffic as soon as the app starts running in the cloud.
• A little bit at a time: You move a few customers over to the new environment once the team sets up the cloud-based app. If everything works as expected, you continue switching customers to the cloud over time until all end-users rely on the new app.

Use Our Cloud Migration Checklist to Migrate with Confidence

While moving to the cloud is often a no-brainer decision, many businesses struggle with or have limited success when moving apps to the cloud. Sticking to the cloud migration checklist above ensures you avoid all common pitfalls, so you can start planning your cloud adoption without the fear of costly missteps.

If you're hoping to keep a cloud migration or expansion smooth, your first step should always be to assess your placement in your industry's cloud maturity model (CMM).