In the Migrate methodology of the Cloud Adoption Framework, migration to the cloud is already considered to be a hybrid or multicloud process. Most of the guidance in that methodology will remain relevant when you migrate to a hybrid and multicloud environment. The biggest shift from that methodology is related to the long-term objective of migrations.
Typically, migration efforts have been seen as a one-way street. Assets move up to the cloud, or to a new cloud, and stay there. In a hybrid and multicloud environment, migration efforts are more like a multilane highway. Assets move between multiple public and private clouds based on shifting business or technical requirements. This shift in migration strategy has minimal impact on the migration process, but it can directly affect the work that comes before and after migration.
The direct effect of divergences on migration processes is minor, but awareness of them can increase your organization’s likelihood of success. The act of migrating workloads consists of three high-level processes repeated in waves, or sprints, until the migration is complete. Here’s a brief look at how these processes change:
Assess workloads: A few considerations will shape how you assess workloads before migration.
Deploy workloads: Deployment of the waves of workloads is largely unchanged. But you might want to use more of the Azure Migrate ecosystem to accelerate specific types of migrations.
Release workloads: After workloads are deployed, the biggest shift is seen in testing cycles before release to production traffic.
When you migrate workloads in a hybrid and multicloud environment, the real effect is on the efforts that come before and after the migration. Before you migrate workloads in a hybrid and multicloud approach, see Introduction to hybrid and multicloud and Introduction to unified operations to understand what else changes outside of your migration effort.
