Migration Plan

Understanding This Module

Migration Plan is the transition from analysis to delivery. It follows Discovery and is continuously filled with concrete implementation detail from the Design module.

The goal is to transform findings from Discovery and Design into a detailed, step-by-step migration plan that delivery teams can run with predictable quality.

This module forms the bridge between strategy and implementation and is therefore critical for the overall migration success.

Core Activities

Wave planning

Group applications into logical migration waves based on dependency constraints, business criticality, and technical complexity.

Migration runbooks

Create detailed, step-by-step runbooks per wave or application covering preparation, delivery, cutover, rollback, and post-migration validation.

Resource planning

Define required teams, skills, tools, and expert allocation per wave, including enablement and training planning.

Delivery governance

Establish clear governance processes, ownership, communication cadence, and cutover controls for wave delivery.

Agile by Design

Migration planning must stay adaptive. Programs should start initial waves as early as possible and then continuously refine wave scope and sequencing as additional Discovery and Design outputs become available.

Runbooks are living documents. Teams should review and improve runbooks after every cutover. As runbook quality increases, migration velocity typically increases wave by wave.

Scaling Large Migrations in Practice

In large migration programs, the goal is to scale delivery from initial pilot waves to predictable factory throughput. A typical trajectory is to start with small waves (for example, 5 servers/week) and gradually increase throughput (for example, up to 50-100 servers/week), depending on constraints and delivery maturity.

Early waves are intentionally smaller so portfolio and migration workstreams can stabilize their processes, validate assumptions, and improve runbooks. This learning loop is a key success factor for large migrations.

Migration Factory Operating Model

In this module, the migration factory is typically operated through four components:

Project governance rules

Processes and tools that govern wave orchestration, communication, timelines, and cutovers so teams run tasks in the right sequence and at the right time.

Portfolio runbooks

Runbooks used to prioritize applications, plan waves, and collect migration metadata as the input material for delivery.

Migration runbooks

Runbooks used to run migration waves, load metadata into migration tooling, and complete cutover and validation.

Best practices and health-check matrix

A regular health-check mechanism used to assess progress, identify delivery risks early, and keep delivery on track.

Data Flow Through Portfolio and Migration Workstreams

Runbooks create the data flow across two connected workstreams:

• Portfolio workstream: Prioritizes and prepares applications and metadata for upcoming waves.
• Migration workstream: Runs migrations and cutovers according to approved wave plans.

Teams are usually dedicated to parts of the factory while waves flow through both workstreams. To prevent supply issues, keep enough prepared waves in front of delivery. A common baseline is to keep the portfolio workstream five waves ahead of the migration workstream.

Clear Distinction: Portfolio vs Migration

For governance and capacity planning, it is important to separate function from team ownership:

• Portfolio: Functional and technical wave preparation, including prioritization, dependency clarification, scope shaping, metadata quality, and readiness proof.
• Portfolio Team: Roles that run and own portfolio work (for example, program leadership, domain owners, architects, application owners, and governance).
• Migration: Operational delivery of approved waves, including runbook-driven delivery, change/cutover control, validation, stabilization, and documented closure.
• Migration Team: Roles that run and secure technical migration delivery (for example, factory engineers, platform teams, network/security specialists, test, and operations handover).

Both teams are tightly coupled, but they deliver different outputs:

• Portfolio Team delivers: Approved wave cuts, prioritized backlogs, complete migration metadata, and delivery-ready input packages.
• Migration Team delivers: Successful cutovers, validated target states, lessons learned, and improved runbook versions for upcoming waves.

Dynamic Wave Delivery Pattern

A typical dynamic pattern is:

• Portfolio cadence: About 1-2 weeks per wave for preparation.
• Migration cadence: About 3-4 weeks per wave for delivery and cutover.
• Wave buffer: A five-wave buffer between portfolio and migration workstreams.

Before migration delivery reaches steady throughput, portfolio planning usually establishes an initial wave buffer. Once delivery starts, both workstreams continue in parallel and the buffer helps prevent delivery stalls.

Phase and Module Model in Wave Planning

The following diagram visualizes the operating model based on phases and modules: planning remains anchored in the Migration Plan module (Design and Mobilize), while delivery runs in staggered migration waves.

In this model, phase boundaries are intentionally overlapping:

• Design and Mobilize starts with wave planning and remains active through the planning of Wave 8 (up to Week 3).
• Migrate starts already in Week 3 and continues through the remaining timeline.
• Pilot wave and adjustments: Wave 1 is a shorter pilot wave for initial validation, followed by targeted setup adjustments during the first production waves.

The detailed setup scope is documented in its dedicated chapter: Migration Factory Setup.

Swipe sideways to see the whole diagram

The pattern is intentionally dynamic: portfolio work keeps a stable forward buffer, while migration work runs waves with runbooks, cutovers, and validation.

Migration Factory Process in the Module Flow

Migration Plan connects Discovery and Design outputs with delivery governance, wave planning, and runbook-driven delivery. The process tightly links portfolio and migration workstreams through governance controls, runbooks, and continuous improvement.

Wave Planning as a Dynamic Timeline

Wave planning is not a static schedule. It is an operational timeline that must remain transparent for stakeholders and adaptable to new findings. Cadence, overlap between workstreams, and buffer logic are the key control variables.

Iterative Planning Loop in Practice

1. Confirm latest Discovery and Design inputs, constraints, and assumptions.
2. Update wave composition, sequencing, and staffing based on current facts.
3. Run the current wave with approved migration and cutover runbooks.
4. Review cutover outcomes, incidents, and timing variances.
5. Improve governance controls and runbooks, then apply updates to upcoming waves.
6. Re-check health status and wave buffer, then continue with the next iteration.

Outputs of This Module

At minimum, Migration Plan should produce:

• Approved wave plan: Sequenced migration waves with dependency-aware grouping.
• Executable runbooks: Versioned runbooks per wave/application with validation and rollback.
• Resource and skill plan: Staffing and capability mapping per wave.
• Governance cadence: Decision, communication, and cutover control framework.
• Continuous improvement backlog: Tracked runbook and process improvements from each wave.