A guide to a cloud-to-cloud migration with 7 key steps
When an enterprise migrates between cloud environments, planning and process are more important than products and technology -- at least in the short term.
Most enterprises' cloud strategies have evolved beyond a simple either-or choice between on-premises and public cloud deployments. Instead, organizations increasingly seek a multi-cloud approach in which applications can move between platforms or even function as a composite of systems and services that reside on different clouds.
It's an ambitious goal that few organizations have yet to fully achieve. Instead, much of the focus to date has been on implementing processes and technologies to ease migrations between clouds.
It's essential to understand some generic project management and planning considerations that apply, regardless of the situation, before looking at a particular cloud-to-cloud migration scenario. These seven steps can help users build their cloud migration strategy and perform the migration:
1. Determine your goals
The motivation to use cloud platforms will vary by organization. Some seek to create a more robust, distributed disaster recovery (DR) and business continuity environment, while others target software development and test infrastructure. The particular scenarios and cloud goals will affect what, how and when to migrate.
This article is part of
What is cloud migration? Essential guide to moving to the cloud
2. Assess your environment
It's imperative to take stock of applications and data assets. An assessment typically involves the use of automation software to discover and inventory applications and data, along with the relevant system configurations and licenses. It also entails discovering connections and dependencies between applications and data sources. The result is a tactical plan to achieve the cloud-to-cloud migration.
3. Identify and prepare data and apps
The capture and preparation of data and metadata will be a significant part of the premigration process. Tasks include capturing infrastructure configuration details, such as network addressing, CPU specs, memory and storage sizes. Data preparation requires that users create snapshots for volumes and VM or container images, along with prep work to copy or replicate any databases.
4. Perform the migration
Enterprises can copy data to a cloud environment in a variety of ways, such as a network transfer via direct connections or VPNs, as well as bulk transfers via removable hard drives. Other options include packaged software and services designed to automate the creation of DR environments for particular infrastructure, like VMware.
5. Provision the target cloud infrastructure
This is the heavy lifting step. Enterprises create the required cloud infrastructure and services to host migrated applications and data. This can include setting up VMs, storage volumes, networking, databases, load balancers, access management and more.
6. Test and optimize the new environment
Before organizations commit workloads to production, the new cloud environment must be thoroughly tested, under a variety of loading and stress conditions, and optimized to deliver acceptable performance. Testing should also include various failure conditions to determine the efficacy of redundant systems and resources, if there are any.
7. Cut over workloads to the new environment
The final step is to switch production workloads over to the new platform. As with any cutover event, the switch is best done during off-hours and times of low demand since there might be some downtime. Databases often need to be resynced to capture data added since the copying process.
Migration scenarios
There are as many cloud migration scenarios as there are cloud users. Nevertheless, these are the most common cloud-to-cloud migration approaches:
- Rehost/replatform: This approach, also known as lift and shift, typically involves moving an application as is from on premises to the cloud. In a cloud-to-cloud replatform, which involves slightly more tinkering than rehosting, an enterprise swaps cloud-based services, such as databases or container cluster management systems.
- Repurchase: When moving to another cloud, enterprises can repurchase items, or drop and shop. They substitute a self-managed system that provides a commodity service -- such as email and ERP systems -- for an equivalent SaaS product.
- Refactor and rearchitect: This can be as minor as packaging applications into containers before moving to a managed container service or as comprehensive as redesigning the application around cloud-native services, containers and serverless functions.
- Retain or retire: The goal setting and assessment stages lead to a realization that some IT systems are functionally obsolete, underused or best not to move.
Cloud-agnostic and hybrid infrastructure stacks
Sometimes, the replatforming approach leads organizations to perform a strategic appraisal of their infrastructure architecture. Typically, enterprises want a software stack that requires little to no modification and can deploy across multiple cloud platforms. Several large IT vendors have targeted this increasingly common goal with products and services that provide the foundation for hybrid or multi-cloud enterprise environments. Some of the most significant of these include:
- Microsoft Azure Stack
- Google Cloud Anthos
- AWS Outposts
- VMware Cloud on AWS
- Container-based, multi-cloud PaaS, like Cloud Foundry or Red Hat OpenShift
Multi-cloud challenges and limits
While moving applications from on premises to a single cloud provider unlocks a world of high-value services, moving between cloud providers -- whether due to lock-in fear or a desire for high availability -- is often misguided. A cloud-to-cloud migration requires settling for lowest common denominator infrastructure services and sacrificing cloud-specific capabilities, or it means embracing a different form of lock-in -- namely, a multi-cloud stack, like VMware or Cloud Foundry.
