← Cloud projects

Cloud · Architecture Concept

Migration Wave Planning

Turn assessed applications, dependencies, owners, business constraints, and migration treatments into executable waves with clear entry, cutover, rollback, and exit criteria.

PlatformCloud
DomainMigration
LevelIntermediate
Last reviewed2026-09-19
Use whenConvert an assessed application portfolio into migration waves that teams can execute with controlled risk.
Key decisionPlan around applications, not isolated servers
Key conceptsApplication grouping · Dependency mapping · Wave planning
Cost focusParallel migration team capacity
On this page

Building blocks

Application groupingDependency mappingWave planningCutover sequencingMigration readiness

Design goal

Sequence migration around application dependencies and operational capacity so each wave is small enough to execute, validate, learn from, and recover if needed.

Success criteria

  • Group technical components into applications
  • Identify dependency and sequencing constraints
  • Prioritize waves by risk and business value
  • Define entry, test, cutover, and exit criteria

Architecture

Start with application groups and dependencies, enrich them with business constraints and migration strategy, then create waves with clear ownership, validation, and rollback criteria.

Architecture flow

  • Portfolio inventory
  • Application groups
  • Dependency map
  • Readiness scoring
  • Wave design
  • Cutover backlog
PortfolioApp GroupsDependenciesMigration WavesCutover Backlog
Portfolio
App Groups
Dependencies
Migration Waves
Cutover Backlog

Architecture decisions

Decision

Plan around applications, not isolated servers

Why

Dependencies, outage windows, ownership, and business validation usually follow applications and services rather than individual compute instances.

Trade-off

Application-centric waves reduce dependency surprises, but require accurate ownership, business validation, and dependency mapping before scheduling.

Decision

Keep waves small enough to learn

Why

Early waves should validate landing-zone, migration, testing, and rollback processes before high-risk workloads or large batches are attempted.

Trade-off

Smaller waves reduce blast radius and create feedback, but can extend the overall migration timeline if coordination overhead becomes too high.

Cost drivers

  • Parallel migration team capacity
  • Temporary dual-running environments
  • Testing and rollback windows
  • Network transfer and replication
  • Tooling and specialist support

Design assumptions

  • Application owners can validate grouping and critical dependencies
  • Migration strategy decisions exist or can be made before wave finalization

Implementation plan

  1. Group infrastructure records into applications and assign accountable business and technical owners before building waves.
  2. Map dependencies, data flows, change windows, regulatory constraints, and shared services that control migration order.
  3. Assign the migration treatment and target architecture, then score readiness, complexity, and prerequisite work for each application.
  4. Build waves small enough to contain risk while keeping tightly coupled dependencies together; identify a pilot that can teach the process.
  5. Define test, cutover, rollback, communication, and acceptance criteria for every wave before scheduling production migration.

Validate the design

  • Confirm every workload has an accountable owner, target state, migration treatment, and assigned wave.
  • Check inter-wave dependencies and prerequisites for circular or impossible sequencing.
  • Run a pilot wave and convert lessons learned into explicit changes to the next wave plan.
  • Review cutover, rollback, communications, and acceptance criteria with owners before every production wave.

Architecture basis

Continue a learning path