Migration Wave Planning Vocabulary

Waves decompose a multi-year migration into a series of coordinated, manageable batches.

Typical wave structure:
• Wave 0 — Foundation: Landing zone, shared networking, identity federation, security baseline, logging. No applications migrate. Duration: 6–12 weeks.
• Wave 1 — Pathfinder: 2–5 low-risk applications (internal tools, dev environments, non-critical systems). Goal: validate the migration process, tooling, and runbooks. Learn from mistakes when stakes are low.
• Wave 2–N — Production Waves: Progressively higher-value, higher-complexity applications. Each wave typically runs 4–8 weeks.
• Final Wave: Core business systems — the applications that couldn't move until all their dependencies were already in the cloud.

Wave sequencing principles:
• Dependency order: App A that calls App B must be sequenced after App B migrates (or the two must be in the same wave)
• Risk staging: low-risk applications first; high-criticality apps later when the team is experienced
• Business impact: minimise simultaneous disruption to multiple business domains
• Team capacity: waves are sized to what the migration team can manage in parallel

In planning discussions:
> "We need to move the user-auth service in wave 2 before the billing service in wave 3 — billing has a hard dependency on auth."
> "Wave 1 is our learning wave. If something breaks, it's the internal wiki — not customer-facing. We take the risk there on purpose."

Key vocabulary:
• Migration wave — a time-boxed batch of applications migrated together with coordinated cutovers
• Wave 0 (Foundation) — the pre-migration phase building the cloud environment before any applications move
• Pathfinder wave — the first application migration wave, intentionally low-risk to validate the migration process
• Dependency order — the sequencing constraint that upstream services must migrate before downstream consumers

Cutover and parallel run are distinct phases — both are important for high-criticality migrations.

Cutover:
• The planned moment when the on-premises system is taken offline and all traffic is directed to the cloud
• Typically scheduled in a cutover window — a pre-agreed maintenance window (often a weekend 2am–6am)
• The cutover window must be long enough to: complete final data sync, validate cloud health, execute rollback if needed
• "Calling the cutover" = the Migration Lead formally declares the transition complete

Parallel run (dual-run):
• Running on-premises and cloud environments simultaneously
• Duration: typically 2–4 weeks post-deployment
• Activities during parallel run:
— Compare outputs between old and new system (data consistency checks)
— Validate integrations in production conditions with real traffic
— Train operations team on the new environment
— Build confidence before accepting data divergence from cutover
• Cost: approximately 2× infrastructure cost during the parallel period
• Used for: tier-1 systems, financial systems, any application where silent data corruption would be catastrophic

For which applications?
• Tier-1 (critical): parallel run + phased cutover (canary or blue-green)
• Tier-2 (important): brief parallel run (1–2 weeks) + fallback window
• Tier-3 (non-critical): direct cutover, rollback plan as safety net

In planning meetings:
> "Order management is tier-1 — we run it in parallel for three weeks, reconcile outputs daily, then cut over on a Saturday night with a 4-hour rollback window."

Key vocabulary:
• Cutover — the planned switch from on-premises to cloud; the point of no return
• Cutover window — the scheduled maintenance period for the cutover
• Parallel run — operating both environments simultaneously during a validation period before cutover
• Rollback window — the time after cutover during which the team can revert to on-premises if issues are found

No rollback plan = no cutover approval. This is a standard governance requirement in professional migration programmes.

A complete rollback plan includes:

1. Rollback Decision Point (go/no-go timeout):
• "If we have not declared the migration healthy by 04:00, we initiate rollback"
• The migration lead makes a binary decision — not "let's wait another hour"
• Defined success criteria: smoke tests pass, error rates normal, integration checks clear

2. Rollback procedure:
• Step-by-step: re-point DNS, restore on-premises read/write, notify stakeholders
• Documented and rehearsed — not written during the incident
• Assigned owners for each step (who does what)

3. Data reconciliation:
• Any writes to the cloud system during the cutover window must be captured and replayed on-premises
• Bi-directional sync strategy for the rollback window
• For databases: CDC (Change Data Capture) can facilitate this

4. Communication plan:
• Who receives the rollback notification (operations, business stakeholders, customer support)
• Internal status page update vs external customer communication

Rollback rehearsal:
The rollback plan should be tested in a staging environment before the production cutover. "If we haven't done it before, we won't do it well at 3am."

Post-rollback:
• Rollback is not failure — it's the plan working as designed
• Conduct a blameless post-mortem: why did the cutover fail, what must change for the next attempt
• Reschedule the cutover with fixes applied

Key vocabulary:
• Rollback plan — the documented procedure to revert to the on-premises system after a failed cutover
• Rollback decision point — the pre-agreed time by which a migration health decision must be made
• Go/no-go criteria — the measurable conditions that determine whether to proceed or roll back
• Change Data Capture (CDC) — a technique for capturing database changes in real time, used for rollback data reconciliation

Hypercare is the transition buffer that prevents post-cutover incidents from becoming crises.

What happens during hypercare:
• Extended on-call: Migration engineers are on-call for cloud-specific issues operations hasn't encountered before
• Accelerated incident SLA: P1 response time reduced (e.g., 15 min instead of 30 min) during hypercare period
• Daily health reviews: Morning stand-up reviewing cloud metrics, logs, cost, and any overnight incidents
• Knowledge transfer: Migration team actively hands off tribal knowledge to the operations team
• Runbook validation: Operations runbooks tested against real issues that emerge post-cutover

Hypercare exit criteria (examples):
• Zero P1 incidents in the last 7 days
• Operations team has handled at least 3 production issues independently
• All P&I (procedures and instructions) documents updated
• Error rate, latency, and cost metrics within agreed baselines

Hypercare duration by tier:
• Tier-1 (critical business systems): 4–6 weeks
• Tier-2 (important): 2–3 weeks
• Tier-3 (non-critical): 1 week or skip

In project discussions:
> "We're in hypercare for the payment platform until the end of the month. The migration team is on-call until ops has three incident-free weeks and sign off on the runbooks."
> "Hypercare ended yesterday for the CRM. Smooth handoff — no P1s, ops team is confident. We're officially off-hook."

Key vocabulary:
• Hypercare period — intensive post-cutover support phase before formal handoff to steady-state operations
• Hypercare exit criteria — measurable conditions that define when the hypercare period ends
• Steady-state operations — normal cloud operations after the migration team withdraws
• Knowledge transfer — the process of moving tribal cloud knowledge from the migration team to the operations team

A migration factory transforms ad-hoc migrations into a production line — optimised for throughput and consistency.

Migration factory components:

1. Standardised pipeline stages:

Assess → Mobilise → Migrate → Validate → Operate
(portfolio)  (ready app)   (move)    (test)     (hand-off)

Each stage has defined entry/exit criteria, owners, and tooling.

2. Dedicated factory team roles:
• Factory Lead — overall throughput and programme management
• Migration Engineer — executes server/application migrations
• Database Migration Specialist — handles schema conversion and data migration
• Network Engineer — connectivity, security groups, DNS
• Automation Engineer — builds and maintains migration tooling and scripts
• QA / Validation Engineer — post-migration functional and performance testing

3. Reusable automation:
• Migration runbooks templated and parameterised (not written fresh for each app)
• Testing scripts execute against every migrated application
• Reporting dashboards: migration status, wave progress, issues by category

Economics:
• Migration factory investment: significant upfront (team, tooling, process design)
• Per-migration cost: decreases dramatically as volume increases
• Break-even typically at 30–50 applications

In programme discussions:
> "With 280 apps, we can't treat each one as a bespoke project. We'll invest 8 weeks building the factory, then run at a cadence of 15 applications per wave."

Key vocabulary:
• Migration factory — an industrialised process for high-volume application migrations with standardised stages and dedicated teams
• Pipeline stage — a defined phase in the migration factory process with entry/exit criteria
• Throughput — the number of applications the factory can migrate per time period
• Runbook — a documented, step-by-step procedure for a migration activity, templated for reuse