12-step checklist for cloud migration success

12 key cloud migration steps

While migration drivers and goals can vary, the migration process can generally be divided into 12 distinct steps that form the basis of a comprehensive migration checklist.

1. Build a business case

Why does the business need to migrate this particular workload? There is no one size, purpose or benefit to fit every cloud use case. Migrating a workload to the cloud can improve flexibility, while employing the cloud as a storage target can provide convenience and improve governance. Understand the driving factors, such as cost savings, lower infrastructure burden, scalability, availability and enhancing user satisfaction.

2. Determine the right migration approach

Perhaps the most impactful decision in any cloud migration is whether -- or how much -- to adjust an app to best take advantage of cloud benefits. Depending on their cloud and workload expertise, businesses can employ these five main migration approaches:

• Rehost. This approach, often referred to as lift and shift, redeploys data and applications on cloud storage and compute resources without modifications. It's often the fastest and most direct migration approach. It doesn't work with every type of application, but it works well when there is little cloud expertise or access to the underlying codebase.
• Refactor. This approach modifies a small portion of the underlying codebase to optimize a workload for improved reliability or performance in the public cloud. For example, a workload might be refactored to use a cloud database service instead of an on-premises database, eliminating the need to deploy and maintain a separate database application in the cloud as well.
• Revise. A business can extensively modify a workload's code to use more of the cloud's native services. It requires a clear and detailed understanding of the cloud provider's resources, services and infrastructure. However, the overall features and functionality of the workload remain, ideally, unchanged.
• Rebuild. This is typically the most complex and demanding migration approach. It fundamentally recreates the workload from scratch so it can function most effectively and efficiently in a cloud environment. For example, an aging legacy workload might be redesigned and rebuilt using a cloud-native architecture, such as microservices.
• Replace. Rather than deploy, modify or recreate a workload, the business opts to abandon its current workload and switch to a third-party vendor's application -- often a SaaS product -- and only migrate the data. As a simple example, it might be easier to use the cloud provider's workload monitoring utility rather than trying to deploy the same tools that run on-premises.

Migration alternatives are not all-or-nothing efforts, and different approaches can be adopted for different workloads or use cases. But everything else, from costs to cloud architecture decisions, hinges on which approach you choose.

3. Evaluate costs and needs

Have a clear picture of the workload's current cost and performance characteristics. Evaluate the procurement, operational and maintenance costs of the local services required to run it. Carefully assess the workload's local performance, gathering metrics such as transactions per second and bandwidth usage through an application performance monitoring tool. IT and business leaders must objectively compare these costs and performance metrics with what they might be when the workload migrates to cloud infrastructure. Remember, cloud costs become a recurring budget item and require planning. Adding more cloud resources, such as a larger VM instance, can potentially improve workload performance in the cloud, but then cloud costs increase as well.

4. Choose a cloud environment

Next, consider the target environment that best reflects long-term business needs. Typically, the options are private cloud, public cloud and hybrid cloud.

• Private cloud. A business implements and operates this small-scale cloud in its existing data center infrastructure. It demands significant financial and technical commitment and can lack the services and scalability found in other environments. However, a private cloud can be an ideal alternative if a business needs cloud flexibility but must retain complete control over data and workloads.
• Public cloud. This is the typical commercial computing-as-a-utility service offered by third-party providers. Public clouds are typically extensive and highly scalable, possess a global reach and offer a wealth of individual services. Public cloud users generally consume the services in a pay-per-use model.
• Hybrid cloud. The hybrid model combines the benefits of private and public clouds to deliver an extremely high level of control, flexibility and scalability. However, hybrid clouds require the most investment and commitment to implement.

In addition, businesses that have become adept at using one cloud provider can migrate services between two or more cloud providers in what's known as a multi-cloud environment.

5. Choose a deployment model

There are three primary models for accessing services from a cloud, each with its own level of convenience and user control:

• Infrastructure as a service. IaaS delivers cloud resources that closely mimic traditional data center infrastructure, such as servers, storage, networking and monitoring. Cloud architects assemble these elements to construct a detailed infrastructure that hosts the organization's workload. IaaS is the typical model for most cloud migrations.
• Platform as a service. PaaS generally offers a more highly integrated deployment environment. It extends beyond hardware-based resources to include software such as databases, development tools, integration layers, runtimes and other ready-made components that replace traditional local tools. For example, software developers might use a development PaaS instead of hosting a development and testing toolchain in-house.
• Software as a service. SaaS provides a ready-made application, which alleviates the need for a business to deploy its own workload in the cloud. The SaaS provider handles all of the workload's development and maintenance. Common SaaS offerings include email and productivity applications as well as financial and HR workloads.

6. Pick a cloud partner

The three principal public cloud providers -- AWS, Google Cloud and Microsoft Azure -- all provide a global presence for IaaS and some PaaS deployments. However, many facets of their clouds' operation can differ significantly, from individual services and APIs to costs and monitoring. Businesses typically choose a provider based on the scope of services offered and specific functionality needed for a given workload. For example, AWS offers a wide array of prepackaged computing instances, while Google Cloud is noted for its machine learning and AI services.

Common options for private cloud include VMware, Dell EMC, IBM Red Hat, Nutanix, Cisco CloudCenter, Oracle Cloud at Customer, Rackspace Private Cloud and HPE, as well as the OpenStack open source platform. Key factors to consider include familiarity with the technology, ease of integration with existing systems and reliability.

7. Design the architecture

IaaS users rely on an experienced cloud architect to design a cloud architecture that is best suited to host the workload. The design typically cobbles together virtualized compute, storage and networking instances, along with an assortment of services such as databases, logging and monitoring tools, event-driven computing and more.

The architecture can be simple and straightforward, such as a single compute and storage instance to manage a simple rehosting. The architecture can also be a complex and intricate environment, supporting distributed, highly reliable workloads for mission-critical production environments or numerous interrelated components that host microservices workloads in the cloud. An architect will also consider the corresponding cloud costs associated with the desired architecture and ensure that the workload's owner budgets properly.

Prudent design also involves significant testing to validate the architecture and ensure that the workload will function properly once deployed and cut over for production. It can involve a proof-of-principle project with a number of iterations and refinements before the actual migration takes place.

Be especially careful to prioritize secondary migration components. Most modern enterprise workloads involve dependencies, such as the availability of a database or an application monitoring tool. Cloud architects must consider the entire scope of a deployment and install and validate any required dependencies before the migration is performed.

8. Outline the migration steps

With the infrastructure and dependencies in place, IT and business leaders can develop the migration plan, which details the steps needed to conduct the migration from start to finish. A migration plan can be extensive and involve many actions, including the following:

• Inform the user base.
• Quiesce (pause) and back up the local deployment.
• Transfer and synchronize data the workload will need.
• Move or install the workload and its cloud infrastructure.
• Test and validate the completed migration.
• Prepare documentation and the help desk to respond to queries and troubleshooting.
• Open the migrated workload to some (or all) users.
• Implement and conduct workload monitoring.
• Establish contingency plans, including rollbacks or recoveries.

9. Execute the migration

Ultimately, the business implements the migration plan and migrates the workload, dependencies and related data to the prepared cloud infrastructure. The process also involves making network changes, such as configuring domain and IP environments and setting up the security environment so that traffic is successfully and securely redirected to the cloud workload.

To ensure a smooth migration event, test and validate the migration process through careful planning and proof-of-principle projects well in advance. At the same time, keep current, direct contact information for local IT staff and cloud provider technical support in the event of unexpected problems.

10. Test the workload

Once the migration is completed, thoroughly test the workload for both functionality and performance. Collect and evaluate workload metrics and look for vulnerabilities to mitigate. Start with basic testing by the migration staff, and then open the migrated workload to a series of ever-broader user groups until all users can successfully employ the migrated workload.

11. Monitor and adjust

After the migration testing and cutover, you'll need to perform ongoing maintenance as with any deployed workload. This includes monitoring, support, troubleshooting, adjustments, refinements and other general upkeep over time. Tasks include the following:

• Monitor the workload's performance to foresee utilization trends, spot bottlenecks and support troubleshooting.
• Periodically review the deployment configuration for adequate security and compliance.
• Check the monthly bill and make sure the workload stays within the cloud budget -- cloud FinOps groups can often help with optimizing cloud costs.
• Evaluate the cost and performance of the migrated workload to ensure that it achieves intended benefits for the business.
• Employ comprehensive change management to prevent unexpected and unwanted change, which can lead to performance degradation and security vulnerabilities.

12. Beef up cloud skills and training

While cloud providers take great pains to simplify and streamline the migration to cloud infrastructures, cloud environments are simply different than traditional data centers. Even the simplest rehosting projects are rarely a direct one-to-one exchange without some translation from local to cloud environments. Any cloud migration project requires clear knowledge of the specific cloud provider's resources, services, cost structure and processes. No migration wizard app can replace basic expertise and experience. This is accomplished in two ways.

First, establish and foster careful communication and collaboration between IT and workload owners. IT and business leaders must agree about the goals and intended benefits of a cloud migration. Technology staff must understand the stakeholders' requirements and expectations in order to create suitable cloud infrastructures. Similarly, business leaders must trust technology staff to set realistic expectations, explain the pragmatic limitations of a migration and ensure that the chosen technology aligns with business needs and goals.

Second, technology staff must know the specific cloud provider's services and APIs and how to use them effectively. Take advantage of the training offered by the provider, such as an AWS solutions architect certification. Companies should consider investing in testing and experimentation to build proof-of-principle deployments to validate a cloud architecture before committing to a migration. Some businesses might opt to expand a cloud-capable staff by hiring cloud architects who are already experienced with specific cloud providers.

Stephen J. Bigelow, senior technology editor at TechTarget, has more than 30 years of technical writing experience in the PC and technology industry.