12 key steps for a successful cloud migration

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.

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 may improve flexibility, while employing the cloud as a storage target may provide convenience. Understand the driving factors such as cost savings, lower infrastructure burden, scalability, availability and enhancing user satisfaction.

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 four main migration approaches:

• Rehost. This approach, often referred to as lift and shift, redeploys existing 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 relatively 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 modified to use a database service available within the cloud rather than an on-premises database.
• Revise. A business can choose to extensively modify the workload's code to use more of the cloud's native services. This 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 in order to function most effectively and efficiently within the cloud provider's 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 as a SaaS product. An organization would migrate only the data for that application. As a simple example, it might be easier to use the cloud provider's workload monitoring utility rather than attempting to deploy and use the same tools that run on premises.

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

Evaluate costs and needs. Have a clear picture of the workload's current cost and performance characteristics. Evaluate local server procurement, operational and maintenance costs. Carefully assess the workload's local performance, gathering metrics such as transactions per second and bandwidth usage through an application performance monitoring (APM) tool. IT and business leaders must objectively compare these costs and performance metrics with those when a workload is migrated to a cloud infrastructure. Remember, cloud costs become a recurring budget item and require planning.

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

• A private cloud is a small-scale cloud that a business implements and operates within its existing data center infrastructure. This demands significant financial and technical commitment, and can lack the services and scalability found in other environments. However, it can be an ideal alternative if a business needs cloud flexibility but must retain complete control over data and workloads.
• The public cloud is the typical commercial computing-as-a-utility service offered by large and small 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 these services in a pay-per-use model.
• A hybrid cloud merges both a private and public cloud to combine the benefits of both environments --  an extremely high level of control, flexibility and scalability for a business. However, hybrid clouds require the highest investment and commitment to implement. In a similar vein, some businesses already adept with one cloud provider may also work to migrate services between two or more cloud providers; this is called a multi-cloud environment.

Choose a deployment model. There are several approaches used to access services from a cloud. Each model varies in its 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 one or more traditional local tools. For example, software developers may use a development PaaS rather than 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.

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 any specific functionality for a given workload. For example, AWS offers a wide array of prepackaged computing instances, while Google Cloud is noted for its machine learning (ML) and artificial intelligence (AI) services.

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

Design the architecture. IaaS users rely on a 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/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 many 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 cutover for production. Thus, design may involve a proof-of-principle project with a number of iterations and refinements before an actual migration/cutover takes place.

Be especially careful to prioritize migration components. Most modern enterprise workloads involve one or more 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 actual workload migration is performed.

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

• inform the user/customer base;
• quiesce and back up the local deployment;
• transfer and synchronize data that 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 staff to respond to queries and troubleshooting;
• open the migrated workload to some (or all) users;
• implement and conduct workload monitoring; and
• establish contingency plans, including rollbacks or recoveries.

Execute the migration. Ultimately, the business implements the migration plan and migrates the workload, dependencies and related data to the prepared cloud infrastructure. This process also involves making network changes such as configuring domain and IP environments and setting up the security environment so that workload 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 and direct contact information for both local IT staff and cloud provider technical support in the event of unexpected problems.

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.

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. These tasks include:

• monitor the workload's performance to foresee utilization trends, spot bottlenecks or support troubleshooting;
• periodically review the deployment configuration for adequate security and compliance;
• check the monthly bill and ensure that the workload stays within the cloud budget;
• evaluate the cost and performance of the migrated workload to ensure that it achieves intended benefits for the business.

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 local data centers. Even the simplest rehosting projects are rarely a direct 1:1 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 applet 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 know the requirements and expectations of the stakeholders in order to create suitable cloud infrastructures for a workload. Similarly, business leaders must trust technology staff for realistic expectations and pragmatic limitations of a migration.

Second, technology staff must know the specific cloud provider's services and APIs -- what the provider offers and how to use those offerings effectively. Leverage training from the provider, such as an AWS solutions architect certification. Companies may invest in testing and experimentation to build proof-of-principle deployments to validate a cloud architecture before committing to an actual migration. Some businesses may opt to expand a cloud-capable staff by hiring cloud architects who are already experienced with specific cloud providers.