Concept card

Migration Wave Planning

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is Migration Wave Planning?

Without wave planning, SAP migration programmes drift to 24-36 months without ever cutting over; with 6-8 sequenced waves of 3-4 months each, the same scope ships in 18-24 months.

Migration wave planning is the programme-level discipline of breaking a multi-year SAP migration — S/4HANA brownfield, S/4 greenfield, or a BW-to-BDC modernisation — into a sequence of six to eight waves, each running three to four months, each cutting over a defined unit of scope: a line of business, a region, a legal entity, or an end-to-end process domain. The discipline matters because the alternative is not a faster migration without wave planning, it is a migration that never actually finishes: programmes that attempt a single "big bang" cutover, or that sequence work informally without an explicit wave structure, routinely drift to two or three years without ever reaching a stable, fully cut-over state, while comparable-scope programmes with disciplined wave planning ship the same scope in eighteen to twenty-four months with visible, predictable monthly progress that keeps sponsor confidence intact.

The Dimensions Along Which Waves Are Designed

Why it matters

Master-data foundation must precede every transactional cutover — skip it and the first transactional wave fails on data gaps, cascading delay into every subsequent wave.
Each wave has four hard gates (design-complete, build-complete, UAT-pass, go-live); missing Gate 2 of wave N routinely forces wave N+1's delay.
Wave-too-large — a single wave covering 5+ LoBs in 4 months — is the single most common mistake, compressing build/test until quality collapses.

Key points

Five design dimensions: geographic · LoB-functional · legal-entity · process-domain · risk.
Dependency-driven: master-data first · close before subsidiary · shared-services before consumers · reporting alongside.
Four gates: design · build · UAT · go-live.
6-8 waves sweet spot · 3-4 months each.
Hypercare 4-8 weeks per wave · 30-50% of build budget.
Cutover-window: plan 96h, communicate 48h reality.
FR/DACH calendar: avoid Dec close · Jun semi-annual · Q1 CSRD.
Master-data is wave-zero, never skipped.
Migration Wave Planning is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.

Terms used on this page

Migration wave: 3-4 month sequenced unit of cutover; 6-8 waves cover a Tier-1 multi-LoB programme.
Wave-zero: Master-data foundation wave preceding all transactional waves. Never skipped.
Four gates: Per-wave milestones: design-complete · build-complete · UAT-pass · go-live.
Hypercare: 4-8 week post-go-live elevated support phase; 30-50% of wave-build budget.
Cutover window: Production-cutover time block (typically 48-96h). Plan 96h, communicate 48h.
Reporting blackout: Period when analytics layer cut over after operational systems; 4-12 weeks if not managed.
Risk graduation: Wave-ordering pattern: pilot LoB first (low risk) · mid-tier · flagship last.
Calendar freeze: Period blocked from cutover by business cycles: FR Dec close · Jun semi-annual · Q1 CSRD.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →