Migration Wave Planning Method
Migration wave planning is both a science and an art. It often hinges on a blend of empirical data and the seasoned insights of experts. It includes migration grouping, wave division, and priority determination.

1. Migration grouping
Migration grouping is used to group migration objects based on their dependencies. A group of applications and infrastructure (including applications, hosts, storage devices, databases, and middleware) that have strong dependencies are divided into a migration group. A group of applications and infrastructure must be migrated in the same wave and cut over together.
There are three types of dependencies: shared data dependency, shared server dependency, and inter-application communication dependency.
There are strong dependencies and weak dependencies. Take the shared data dependency as an example. Applications A, B, and C are connected to DB 01. A and B perform many read and write operations per second. C performs batch processing jobs during off-peak hours every night. A and B are tightly coupled with DB 01, while C is loosely coupled with DB 01. A and B must be deployed in the same migration group and migrated together with DB 01. C can be migrated independently and can be deployed in another migration group if necessary.
2. Migration wave division
Enterprise cloud migration is usually performed in waves. A wave can contain one or more migration groups. Migration waves are divided based on the following rules:
- Applications with strong association should be placed in one wave based on the association analysis result.
Applications with strong association should be migrated together in one wave to avoid the impact of on- and off-cloud access latency on businesses.
- The most appropriate time span for a wave is four to eight weeks.
Each wave needs to be sized appropriately. In this way, sufficient workforce and technical resources can be provided to perform the migration, thereby minimizing risks. The best practice in the industry is that a wave spans four to eight weeks, during which deployment, migration, and cutover are performed. This time span excludes the preparation period.
- The size of a wave cannot be too large, or migration risks may increase.
According to the best practice in the industry, the number of migration objects in a wave cannot exceed 20 applications, 150 servers, and 30 databases, or there may be great challenges and high risks (such as task failures and rollbacks). If this rule is not obeyed, you are advised to perform a rigorous check.
If a wave is large, identify strong and weak associations, disconnect weak associations, and divide them into smaller waves to reduce risks.
- Systems of the same supplier should be migrated to the cloud in the same wave or adjacent waves.
Multiple systems of the same supplier are highly coupled. If these systems are migrated to the cloud at the same time, the supplier can pool human resources to support the migration in a short period of time, ensuring collaboration between project teams and facilitating smooth cloud migration.
- Different migration environments are placed in different waves.
The test environment is migrated before the production environment, which can significantly reduce the migration risks of the latter.
3. Migration priority determination
The following table describes factors that affect the cloud migration priority.
Factor |
Result |
Willingness for cloud migration |
Migrate workloads with high willingness first. |
Business environment |
Migrate workloads for the test environment first. |
Business importance |
Migrate general workloads prior to critical workloads. |
Business association |
Migrate workloads with simple associations first. |
Infrastructure complexity |
Migrate workloads with simple underlying infrastructure and a small number of instances first. |
Allowed downtime |
Migrate workloads with longer allowed downtime first. |
Migration strategy |
Migrate applications that can use the rehosting approach ("lift-and-shift") before those requiring re-architecting. |
Business departments' willingness for cloud migration is crucial and should be prioritized first, followed by other factors. You can score each factor for further determination of priorities.
Category |
Factor |
Reference Score |
---|---|---|
Business environment |
Development |
5 |
Test |
3 |
|
Production |
1 |
|
Business importance |
Minor |
5 |
Major |
3 |
|
Core |
1 |
|
Association |
Simple |
5 |
Complex |
3 |
|
Very complex |
1 |
|
Infrastructure complexity |
Simple (1–3 instances) |
5 |
Complex (4–10 instances) |
3 |
|
Very complex (11 instances and more) |
1 |
|
Allowed downtime |
More than 120 minutes |
5 |
60 to 120 minutes |
3 |
|
Less than 60 minutes |
1 |
|
Migration strategy |
Rehost |
5 |
Replatform |
3 |
|
Rearchitect |
1 |
Application Migration Wave Planning Example
App |
Strategy |
Wave |
First Wave |
Second Wave |
Third Wave |
Fourth Wave |
---|---|---|---|---|---|---|
N/A |
N/A |
N/A |
2025.01.01–2025.03.31 |
2025.04.01–2025.06.30 |
2025.07.01–2025.09.30 |
2025.10.01–2025.12.31 |
The table header information provided here is for reference only. Fill the table with real business data. |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot