Updated on 2025-06-19 GMT+08:00

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.

Figure 1 Wave planning

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.

Table 1 Factors affecting 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.

Table 2 Reference scoring table for migration priority determination

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

Table 3 Example table for wave planning

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.