Migration Wave Planning: How to Sequence Workloads Correctly

A cloud migration is not a big-bang event — it is a series of carefully planned waves. Migrating a hundred applications simultaneously risks chaos; sequencing without a strategy wastes months on unnecessary dependency problems. Wave Planning is the discipline of structuring a workload portfolio so that each migration wave remains predictable, testable and reversible.

This article describes how Storm Reply creates wave plans for enterprise portfolios of 50 to over 2,000 workloads in Road.MAP projects — which criteria matter, which tools help and which mistakes most projects make.

Why Wave Planning Determines Success or Failure

The most common cause of delays in migration projects is not technology — it is poor sequencing. Teams start with applications that have complex on-premises dependencies, discover this only at cutover, and lose weeks on rework.

Good wave planning eliminates this problem before the first cutover: through complete dependency mapping, risk-based prioritisation and a clear sequence that places infrastructure foundations before applications and low-risk workloads before business-critical systems.

The Four Dimensions of Workload Prioritisation

In the Road.MAP process, Storm Reply evaluates each workload along four dimensions before assigning it to a wave:

Dimension	Evaluation Criteria	Influence on Wave Position
Technical Complexity	Number of dependencies, database type, OS version, network requirements	High = later waves; Simple = early waves
Business Criticality	Revenue relevance, SLA requirements, number of users, regulatory requirements	Critical = middle waves after process validation
Migration Strategy	Rehost, Replatform, Refactor — effort per strategy	Rehost = early; Refactor = late or post-migration
Dependency Graph	Upstream and downstream applications, shared database services, shared infrastructure	Foundations first, dependent systems after

The Road.MAP Wave Planning Process in Five Steps

1. Build the dependency graph: Based on discovery data (AWS Application Discovery Service or agents), a complete dependency graph is created. Each application is a node; communication relationships are edges. Tools like Migration Hub visualise this graph.
2. Form clusters: Applications that communicate and are tightly coupled are grouped into migration clusters. A cluster migrates in one wave — never split across multiple waves.
3. Prioritise waves: The four dimensions (complexity, criticality, strategy, dependency) are weighted to produce wave assignments. Wave 1 always contains infrastructure components and simple workloads without dependencies — as a process trial run.
4. Plan resources: Each wave gets a timeline: replication start (T-4 weeks), test cutover (T-2 weeks), production cutover (T-0), hypercare end (T+4 weeks). Personnel bottlenecks become visible and are replanned.
5. Define Go/No-Go criteria: Before each cutover, measurable criteria must be met: successful test cutover, monitoring active, rollback plan signed, communication sent to stakeholders. No cutover without a green light.

Wave Architecture: Typical Structure for a 300-App Portfolio

Wave 0 — Infrastructure & Foundation

Shared services, Active Directory, DNS, monitoring agents, backup services. No business applications — only the technical foundation. Duration: 2–4 weeks.

Wave 1 — Pilots (Low Risk)

5–15 non-critical applications without external dependencies. Goal: validate processes, train the team, build confidence. Duration: 4–6 weeks including hypercare.

Waves 2–N — Scale

Iterative migration of remaining applications in clusters of 20–50 servers per wave. Critical systems from Wave 3–4 onwards, once process maturity is proven. Average wave frequency: every 4–6 weeks.

Final Wave — Legacy & Edge Cases

The last 5–10% of the portfolio: applications with special requirements that need individual solutions. Often includes mainframe interfaces and proprietary hardware dependencies.

Common Wave Planning Mistakes and How Road.MAP Prevents Them

Three patterns are observed by Storm Reply consultants in nearly every migration project that starts without structured wave planning:

Mistake 1: Critical applications in early waves. Pressure to show visible progress quickly leads to moving important systems early — before processes are established. Road.MAP prevents this with an explicit rule: Wave 1 contains exclusively low-risk workloads.

Mistake 2: Splitting clusters. Applications that communicate are distributed across different waves for resource reasons. The result: network latency between on-premises and AWS, timeouts, manual workarounds. Road.MAP rule: a cluster always stays together.

Mistake 3: No hypercare planned. After cutover, there are no resources for support. Every workload receives four weeks of hypercare budget in Road.MAP — explicitly in the wave plan and resource planning.

Frequently Asked Questions about Wave Planning

How many applications should be included in a migration wave?

The optimal wave size depends on team size and application complexity. A good rule of thumb: 10–30 servers per wave for a three-person migration factory team. First waves should deliberately be smaller to practise processes and build confidence.

What happens if a wave cannot be completed?

Each wave in the Road.MAP framework has a rollback plan. If an application cannot be migrated successfully, it is removed from the wave and rescheduled in the next wave — after root cause analysis. The other applications in the wave are not affected.

How is the wave plan updated when the portfolio changes?

Wave plans are living documents. The Road.MAP process includes weekly wave review meetings where learnings from completed waves feed into subsequent wave planning. AWS Migration Hub serves as the central status overview.

How does Road.MAP handle SAP migrations in the wave plan?

SAP systems (ECC, S/4HANA, BW) are always treated as their own cluster due to their complexity and criticality, and are planned into middle to late waves. Storm Reply holds SAP on AWS certifications and maintains specific SAP runbooks in the Road.MAP framework.