# Migration Wave Plan: [Programme or data centre name]

> Plan for moving a portfolio of applications to cloud in waves:
> portfolio discovery, dependency mapping, grouping into move groups and
> waves, the disposition of each application using the seven migration
> strategies (retire, retain, rehost, relocate, repurchase, replatform,
> refactor or re-architect) described in AWS Prescriptive Guidance, the
> wave calendar, a cutover runbook template, rollback criteria, testing,
> communication, hypercare, KPIs and the wave retrospective.
> Provider-neutral; sequencing practice is consistent with the migration
> planning guidance in the Microsoft Cloud Adoption Framework and the
> AWS large migration guide. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Keep one plan per migration programme and update it every wave. The
  wave calendar and the per-application table are living sections; the
  method sections change rarely.
- Finish discovery and dependency mapping (sections 2 and 3) before
  fixing wave dates. Waves built from an unvalidated inventory move
  half an application and break the other half.
- Copy section 8 into a separate cutover runbook for each wave and fill
  it with names and times. Rehearse it before the real cutover.
- Related documents: Cloud adoption strategy
  (`architecture/cloud-adoption-strategy`), Modernization assessment
  (`architecture/modernization-assessment`), Landing zone design
  (`architecture/landing-zone-design`), Deployment runbook
  (`ops/deployment-runbook`), Disaster recovery plan
  (`ops/disaster-recovery-plan`), Communication plan
  (`project/communication-plan`), RAID log (`project/raid-log`),
  Lessons learned (`project/lessons-learned`).
-->

## Document control

<!-- Guidance: Identify the programme, the source environments and who approves wave changes. Each approved wave plan is a version. -->

| Field | Value |
|---|---|
| Document ID | [MWP-001] |
| Programme | [Programme name] |
| Source environments | [Data centre A, data centre B, other cloud] |
| Target environment | [Provider, landing zone name, regions] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Active / Closed] |
| Owner | [@migration-lead] |
| Approvers/reviewers | [@programme-sponsor], [@platform-lead], [@head-of-operations], [@security-lead] |
| Hard deadline | [YYYY-MM-DD, reason such as lease or contract end] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Programme sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Platform owner | [@name] | [Decision] | YYYY-MM-DD |
| Operations | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Business representative | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Discovery results and draft move groups |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Waves 0 to 3 approved |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* MG-07 moved from wave 3 to wave 4 after dependency found |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, objectives and approach](#1-scope-objectives-and-approach)
2. [Portfolio discovery](#2-portfolio-discovery)
3. [Dependency mapping](#3-dependency-mapping)
4. [Application dispositions](#4-application-dispositions)
5. [Move groups and waves](#5-move-groups-and-waves)
6. [Wave calendar](#6-wave-calendar)
7. [Testing strategy](#7-testing-strategy)
8. [Cutover runbook template](#8-cutover-runbook-template)
9. [Rollback criteria and procedure](#9-rollback-criteria-and-procedure)
10. [Communication plan](#10-communication-plan)
11. [Hypercare and decommissioning](#11-hypercare-and-decommissioning)
12. [KPIs and reporting](#12-kpis-and-reporting)
13. [Wave retrospective](#13-wave-retrospective)
14. [Risks, issues and traceability](#14-risks-issues-and-traceability)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope, objectives and approach

<!-- Guidance: State what moves, by when and how the programme is organised. Questions: is the deadline fixed? Which applications are out of scope and why? Pitfall: mixing modernisation goals into a time-boxed exit without extra time. -->

### 1.1 Scope and objectives

| Item | Value |
|---|---|
| Applications in scope | *Example:* 310 applications, 2,100 virtual machines, 180 physical servers |
| Out of scope | *Example:* Mainframe (retained until YYYY-MM-DD), plant floor systems |
| Primary objective | *Example:* Empty data centre A before YYYY-MM-DD |
| Secondary objectives | *Example:* Replace end-of-support operating systems during replatform |
| Downtime principle | *Example:* Business-critical applications use near-zero downtime methods; others accept a planned window |

### 1.2 Approach

Organise the work as a repeatable migration factory: a small number of
standard runbooks, applied to batches of applications called waves, with
measurement and improvement after every wave. Use the phase vocabulary
of the AWS large migration guide (assess, mobilize, migrate and
modernize) or the Microsoft migration steps (plan migration, prepare
workloads, execute migration, optimise in cloud, decommission source)
if the organisation already uses one of them.

| Workstream | Responsibility | Lead |
|---|---|---|
| Portfolio *(Example)* | Discovery, dependency mapping, dispositions, wave planning | @portfolio-lead |
| Migration *(Example)* | Replication, cutover, rollback, handover | @migration-lead |
| Foundation *(Example)* | Landing zone readiness, network capacity, tooling | @platform-lead |
| Governance *(Example)* | Schedule, budget, risk, communication | @pmo-lead |
| Testing *(Example)* | Test plans, test data, sign-off coordination | @test-lead |

## 2. Portfolio discovery

<!-- Guidance: Build a validated inventory before planning. Questions: which data sources are combined? Who confirmed ownership? How current is utilisation data? Pitfall: trusting a CMDB without network flow evidence. -->

### 2.1 Discovery sources

| Source | Data collected | Coverage | Collected on |
|---|---|---|---|
| Agent-based discovery tool *(Example)* | Servers, processes, utilisation, network connections | 92 % of servers | YYYY-MM-DD to YYYY-MM-DD |
| Network flow logs *(Example)* | Connections between subnets and external endpoints | Core switches | 30 days |
| CMDB *(Example)* | Application to server mapping, owners | All, accuracy unknown | YYYY-MM-DD |
| Owner interviews *(Example)* | Business criticality, change windows, constraints | 74 critical applications | YYYY-MM-DD |
| Licence register *(Example)* | Licence terms and mobility | All commercial software | YYYY-MM-DD |

Collect utilisation data over at least one full business cycle (for
example a month-end close) so that sizing and dependency maps reflect
peaks.

### 2.2 Application record

Capture these fields for every application. Missing fields block the
application from being assigned to a wave.

| Field | Example |
|---|---|
| Application ID and name | *Example:* APP-0142 Payments gateway |
| Business owner and technical owner | *Example:* @payments-owner, @payments-tech |
| Criticality tier | *Example:* Tier 1 |
| Servers and data stores | *Example:* 6 VMs, 1 relational database (2 TB) |
| Recovery objectives | *Example:* RTO 1 hour, RPO 5 minutes |
| Change windows and blackout periods | *Example:* Sunday 01:00 to 05:00; no changes in the last 5 days of a month |
| Compliance constraints | *Example:* Card data in scope; data residency EU |
| Licence constraints | *Example:* Database licence tied to physical cores |
| Known dependencies | *Example:* APP-0007 identity, APP-0099 fraud scoring |

## 3. Dependency mapping

<!-- Guidance: Map dependencies from evidence, then classify them. Questions: which dependencies need low latency? Which can tolerate a hybrid period? Pitfall: forgetting shared infrastructure such as DNS, file shares, batch schedulers and licence servers. -->

Map dependencies from discovery data, then confirm them with technical
owners. Classify each dependency so that the grouping rules in section 5
can be applied consistently.

```mermaid
flowchart LR
  subgraph MG03[Move group MG-03 Payments]
    PAY[APP-0142 Payments gateway] --> PDB[(Payments DB)]
    PAY --> FRD[APP-0099 Fraud scoring]
  end
  subgraph SHARED[Shared services, migrate early]
    IDP[APP-0007 Identity]
    DNS[DNS and time]
  end
  subgraph MG05[Move group MG-05 Orders]
    ORD[APP-0210 Order service] --> ODB[(Orders DB)]
  end
  PAY --> IDP
  ORD --> IDP
  ORD -->|batch, latency tolerant| PAY
  PAY --> DNS
  ORD --> DNS
  EXT[External card network] --> PAY
```

| Dep ID | From | To | Type | Latency sensitive | Hybrid tolerated | Treatment |
|---|---|---|---|---|---|---|
| DEP-001 *(Example)* | APP-0142 | Payments DB | Direct, synchronous | Yes | No | Same move group |
| DEP-002 *(Example)* | APP-0142 | APP-0099 | Direct, synchronous | Yes | No | Same move group |
| DEP-003 *(Example)* | APP-0210 | APP-0142 | Indirect, nightly batch | No | Yes | Separate waves allowed |
| DEP-004 *(Example)* | APP-0142 | APP-0007 | Shared service | Medium | Yes over private link | Shared service moves in wave 1 |
| DEP-005 *(Example)* | External card network | APP-0142 | External, allow-listed IPs | No | n/a | Partner change request 6 weeks before cutover |
| [DEP-NNN] | [From] | [To] | [Type] | [Yes / No] | [Yes / No] | [Treatment] |

## 4. Application dispositions

<!-- Guidance: Record the chosen migration strategy for every application with a reason. Questions: does the strategy fit the deadline? Is modernisation better done after the move? Pitfall: assigning refactor in a large time-boxed migration. -->

### 4.1 Migration strategies

The seven strategies below follow AWS Prescriptive Guidance. For large,
time-boxed migrations that guidance favours rehost, relocate, replatform
and retire, and modernisation after the move.

| Strategy | Meaning | Typical method |
|---|---|---|
| Retire | Decommission or archive the application | Archive data, shut down servers |
| Retain | Keep in the source environment for now | Review at a set date |
| Rehost | Move without changing the application (lift and shift) | Block-level server replication |
| Relocate | Move servers at hypervisor or platform level to a cloud version of the same platform | Platform-level migration tooling |
| Repurchase | Replace with a different product, often SaaS (drop and shop) | Data migration to the new product |
| Replatform | Move with targeted optimisation (lift and reshape) | Managed database, container runtime |
| Refactor or re-architect | Redesign using cloud-native features | New build plus data migration |

### 4.2 Per-application dispositions

| App ID | Application | Tier | Strategy | Reason | Target | Move group | Wave |
|---|---|---|---|---|---|---|---|
| APP-0007 *(Example)* | Identity services | 1 | Rehost | Shared dependency, must move early | Shared services container | MG-01 | 1 |
| APP-0099 *(Example)* | Fraud scoring | 1 | Rehost | Tight coupling with payments | payments-prod | MG-03 | 3 |
| APP-0142 *(Example)* | Payments gateway | 1 | Replatform | Database moves to managed service; OS end of support | payments-prod | MG-03 | 3 |
| APP-0210 *(Example)* | Order service | 1 | Rehost | Modernise after migration | orders-prod | MG-05 | 4 |
| APP-0301 *(Example)* | Legacy reporting | 3 | Retire | Replaced by data platform | n/a | n/a | 2 |
| APP-0312 *(Example)* | HR system | 2 | Repurchase | SaaS contract signed | SaaS | MG-04 | 3 |
| APP-0400 *(Example)* | Plant control | 1 | Retain | Specialised hardware | Source | n/a | n/a |
| [APP-NNNN] | [Name] | [Tier] | [Strategy] | [Reason] | [Target] | [MG-NN] | [Wave] |

Detailed scoring and target-state design for modernisation candidates
belong in the Modernization assessment
(`architecture/modernization-assessment`).

## 5. Move groups and waves

<!-- Guidance: Group applications that must move together, then bundle groups into waves sized to the factory's proven capacity. Pitfall: a first wave full of tier 1 systems. -->

### 5.1 Grouping rules

- Applications with direct, latency-sensitive dependencies move in the
  same move group.
- Shared services (identity, DNS, file services, schedulers) move in an
  early wave or are reachable over private links during the hybrid
  period.
- Non-production environments move before production of the same
  application.
- Early waves contain low-risk applications plus one representative
  complex application to expose problems early.
- When dependency criticality is uncertain, keep components together.

### 5.2 Move groups

| Move group | Applications | Servers | Data volume | Strategy mix | Constraint | Owner |
|---|---|---|---|---|---|---|
| MG-01 *(Example)* | APP-0007, DNS, time | 12 | 0.5 TB | Rehost | Must precede all production waves | @platform-lead |
| MG-03 *(Example)* | APP-0142, APP-0099, Payments DB | 9 | 2.4 TB | Replatform, rehost | Not in month-end freeze | @payments-tech |
| MG-04 *(Example)* | APP-0312 | 3 | 0.2 TB | Repurchase | Vendor onboarding date | @hr-tech |
| MG-05 *(Example)* | APP-0210, Orders DB | 11 | 3.1 TB | Rehost | After MG-03 for batch interface | @orders-tech |
| [MG-NN] | [Applications] | [Number] | [Volume] | [Strategies] | [Constraint] | [@owner] |

### 5.3 Waves

| Wave | Move groups | Applications | Servers | Cutover window | Readiness gate date | Wave lead |
|---|---|---|---|---|---|---|
| 0 Pilot *(Example)* | MG-00 | 3 | 8 | YYYY-MM-DD | YYYY-MM-DD | @migration-lead |
| 1 *(Example)* | MG-01, MG-02 | 14 | 60 | YYYY-MM-DD | YYYY-MM-DD | @wave-lead-1 |
| 2 *(Example)* | MG-06 to MG-09, retirements | 38 | 140 | YYYY-MM-DD | YYYY-MM-DD | @wave-lead-2 |
| 3 *(Example)* | MG-03, MG-04 | 21 | 95 | YYYY-MM-DD | YYYY-MM-DD | @wave-lead-1 |
| [N] | [MG-NN] | [Number] | [Number] | YYYY-MM-DD | YYYY-MM-DD | [@owner] |

Readiness gate for each wave: landing zone containers vended, network
routes and firewall rules in place, replication healthy, test plan
approved, rollback rehearsed, communication sent, business sign-off
recorded.

## 6. Wave calendar

<!-- Guidance: Show waves against business blackout periods. Recompute the calendar after every retrospective. Pitfall: no buffer between waves for fixes. -->

The calendar shows each wave's preparation, replication, cutover and
hypercare windows, with business freeze periods marked so that no
cutover falls inside them.

```mermaid
gantt
  title Wave calendar (Example)
  dateFormat YYYY-MM-DD
  section Freeze periods
  Quarter-end freeze        :crit, f1, 2026-12-20, 14d
  section Wave 0 pilot
  Prepare and replicate     :w0a, 2026-09-07, 20d
  Cutover                   :milestone, w0c, 2026-09-27, 0d
  Hypercare                 :w0h, after w0c, 14d
  section Wave 1
  Prepare and replicate     :w1a, 2026-10-05, 27d
  Cutover                   :milestone, w1c, 2026-11-01, 0d
  Hypercare                 :w1h, after w1c, 14d
  section Wave 2
  Prepare and replicate     :w2a, 2026-11-09, 27d
  Cutover                   :milestone, w2c, 2026-12-06, 0d
  Hypercare                 :w2h, after w2c, 14d
  section Wave 3
  Prepare and replicate     :w3a, 2027-01-04, 27d
  Cutover                   :milestone, w3c, 2027-01-31, 0d
  Hypercare                 :w3h, after w3c, 14d
```

## 7. Testing strategy

<!-- Guidance: Define what is tested, by whom, before and after cutover. Pitfall: functional tests only, with no performance or failover tests in the target environment. -->

| Test type | When | Scope | Responsible | Pass criteria |
|---|---|---|---|---|
| Replication health *(Example)* | Daily before cutover | All servers in the wave | Migration team | Lag below [5 minutes], no errors |
| Non-disruptive test launch *(Example)* | One week before cutover | Every server, isolated network | Migration team | Boots, services start, agents report |
| Functional smoke test *(Example)* | During rehearsal and cutover | Critical user journeys | Application team | All scripted journeys pass |
| Integration test *(Example)* | During rehearsal | Interfaces in section 3 | Integration team | Every DEP row verified |
| Performance test *(Example)* | Rehearsal for tier 1 | Peak load profile | Test team | Within [10 %] of source baseline |
| User acceptance *(Example)* | Cutover window | Business key users | Business owner | Signed acceptance |
| Backup and restore *(Example)* | During hypercare | Each data store | Operations | Restore succeeds within RTO |

## 8. Cutover runbook template

<!-- Guidance: Copy this section per wave and fill exact times and names. Every step has an owner, a duration and a check. A go or no-go decision precedes the point of no return. -->

### 8.1 Roles and contacts

| Role | Name | Contact | Backup |
|---|---|---|---|
| Cutover lead | [@name] | [Phone, chat channel] | [@name] |
| Application technical owner | [@name] | [Contact] | [@name] |
| Database lead | [@name] | [Contact] | [@name] |
| Network lead | [@name] | [Contact] | [@name] |
| Business approver | [@name] | [Contact] | [@name] |
| Service desk lead | [@name] | [Contact] | [@name] |

### 8.2 Steps

| Step | Time (T relative) | Action | Owner | Duration | Check | Status |
|---|---|---|---|---|---|---|
| CUT-01 | T-7d | Confirm readiness gate passed and send cutover notice | Cutover lead | 1 h | Gate checklist signed | [ ] |
| CUT-02 | T-1d | Freeze application changes; verify replication lag | Application owner | 30 min | Lag below threshold | [ ] |
| CUT-03 | T-2h | Go or no-go call 1 | Cutover lead | 15 min | All leads say go | [ ] |
| CUT-04 | T0 | Put application into maintenance mode; stop writes | Application owner | 15 min | No new transactions | [ ] |
| CUT-05 | T+15m | Final replication sync and data validation (row counts, checksums) | Database lead | 45 min | Counts match | [ ] |
| CUT-06 | T+1h | Launch target servers or switch to managed services | Migration team | 30 min | Health checks green | [ ] |
| CUT-07 | T+1h30m | Run smoke tests in the target environment | Application owner | 30 min | Scripted journeys pass | [ ] |
| CUT-08 | T+2h | Go or no-go call 2 (point of no return) | Cutover lead | 15 min | Business approver says go | [ ] |
| CUT-09 | T+2h15m | Switch DNS or load balancer to the target | Network lead | 15 min | Traffic observed on target | [ ] |
| CUT-10 | T+2h30m | User acceptance by key users | Business approver | 1 h | Acceptance recorded | [ ] |
| CUT-11 | T+3h30m | Remove maintenance mode, announce completion | Cutover lead | 15 min | Announcement sent | [ ] |
| CUT-12 | T+4h | Start hypercare; keep source servers stopped but intact | Operations | n/a | Hypercare roster active | [ ] |

```mermaid
stateDiagram-v2
  [*] --> Ready
  Ready --> Frozen: CUT-02
  Frozen --> Synced: CUT-04, CUT-05
  Synced --> Validated: CUT-06, CUT-07
  Validated --> Live: CUT-08 go, CUT-09
  Validated --> RolledBack: CUT-08 no-go
  Synced --> RolledBack: validation fails
  Live --> Hypercare: CUT-11, CUT-12
  Live --> RolledBack: rollback trigger in section 9
  RolledBack --> [*]
  Hypercare --> [*]
```

## 9. Rollback criteria and procedure

<!-- Guidance: Agree rollback triggers with the business before cutover, not during it. Pitfall: no rollback after data has been written in the target, because reverse sync was never planned. -->

### 9.1 Rollback triggers

| ID | Trigger | Measured by | Decision owner | Deadline to decide |
|---|---|---|---|---|
| RBK-001 *(Example)* | Data validation mismatch that cannot be explained within 30 minutes | CUT-05 checks | Database lead with cutover lead | Before CUT-08 |
| RBK-002 *(Example)* | Any critical user journey fails smoke test | CUT-07 | Application owner | Before CUT-08 |
| RBK-003 *(Example)* | Error rate above [2 %] or latency above [2x baseline] for 15 minutes after switch | Monitoring dashboard | Cutover lead | Up to T+24h |
| RBK-004 *(Example)* | Security control missing (logging, encryption, guardrail failure) | Post-provision checks | Security lead | Before CUT-09 |
| [RBK-NNN] | [Trigger] | [Measure] | [@owner] | [Deadline] |

### 9.2 Rollback procedure

1. Announce the rollback decision on the cutover channel and record the
   trigger and time.
2. Put the target into maintenance mode and stop writes.
3. If the target accepted writes, run the reverse synchronisation or
   replay procedure for the affected data stores and validate counts.
4. Restart the source servers, switch DNS or load balancers back and
   run the smoke tests against the source.
5. Confirm with the business approver, send the rollback communication
   and open a problem record for the retrospective.

Rehearse rollback at least once per wave, in the rehearsal window, and
record the measured rollback duration.

## 10. Communication plan

<!-- Guidance: Tell each audience what changes for them, when and whom to contact. Use the Communication plan (`project/communication-plan`) for the programme-wide plan. -->

| Audience | Message | Channel | When | Sender |
|---|---|---|---|---|
| Business users of the wave *(Example)* | Downtime window, what to expect, support contacts | Email and intranet | T-14d, T-2d, T0, completion | Business owner |
| Service desk *(Example)* | Applications moving, known issues, escalation path | Briefing and knowledge article | T-7d | Cutover lead |
| External partners *(Example)* | IP address and endpoint changes | Formal notice | T-42d, T-7d | Integration lead |
| Steering committee *(Example)* | Wave status and decisions needed | Status report | Weekly, plus completion | Migration lead |
| All staff *(Example)* | Programme progress | Newsletter | Monthly | PMO |

## 11. Hypercare and decommissioning

<!-- Guidance: Define the support period after cutover and the exit criteria. Then decommission the source deliberately. Pitfall: deleting source servers before backups and data retention are confirmed. -->

| Item | Design |
|---|---|
| Duration | *Example:* 14 days for tier 1, 7 days for others |
| Support model | *Example:* Daily stand-up, dedicated chat channel, migration engineers on call |
| Exit criteria | *Example:* No open priority 1 or 2 incidents, KPIs within targets, backup restore tested, operations handover signed |
| Handover to operations | *Example:* Runbooks, monitoring, alert routing and on-call updated |

| Decommission step | Condition | Owner | Date |
|---|---|---|---|
| Source servers stopped, not deleted *(Example)* | At cutover | Migration team | YYYY-MM-DD |
| Final backup of source and retention confirmed *(Example)* | Hypercare exit | Operations | YYYY-MM-DD |
| Servers deleted, licences released, CMDB updated *(Example)* | [30 days] after hypercare exit | Operations | YYYY-MM-DD |
| Hardware and contracts released *(Example)* | All servers on a host or rack removed | Facilities | YYYY-MM-DD |

## 12. KPIs and reporting

<!-- Guidance: Measure the factory, not only the applications. Targets are examples; set your own from the pilot wave. -->

| KPI | Definition | Target | Wave 0 | Wave 1 | Wave 2 |
|---|---|---|---|---|---|
| Servers migrated per wave *(Example)* | Servers cut over and accepted | [Rising per wave] | [Value] | [Value] | [Value] |
| Cutover within window *(Example)* | Share of applications finished inside the approved window | [95 %] | [Value] | [Value] | [Value] |
| Rollbacks *(Example)* | Applications rolled back | [0 to 1 per wave] | [Value] | [Value] | [Value] |
| Hypercare incidents *(Example)* | Priority 1 and 2 incidents during hypercare | [Falling per wave] | [Value] | [Value] | [Value] |
| Cost against forecast *(Example)* | Actual cloud cost of migrated apps versus forecast | [Within 10 %] | [Value] | [Value] | [Value] |
| Source decommissioned *(Example)* | Share of migrated source servers deleted | [100 % within 45 days] | [Value] | [Value] | [Value] |

## 13. Wave retrospective

<!-- Guidance: Hold a retrospective within one week of each hypercare exit and feed changes into the runbooks before the next wave. Record durable lessons in Lessons learned (`project/lessons-learned`). -->

| Item | Wave [N] |
|---|---|
| Date and participants | YYYY-MM-DD, [names] |
| What went well | *Example:* Rehearsal caught two firewall rules missing |
| What did not go well | *Example:* Data validation took 90 minutes instead of 45 |
| Root causes | *Example:* Checksum script ran single-threaded on large tables |
| Runbook changes | *Example:* Parallel validation added to CUT-05 |
| Plan changes | *Example:* Wave 4 reduced by 10 servers to keep window |
| KPI trend | [Summary of section 12] |
| Actions | RET-[N]-001 to RET-[N]-NNN, with owners and dates |

## 14. Risks, issues and traceability

<!-- Guidance: Keep wave-specific risks here and programme risks in the RAID log (`project/raid-log`). The traceability table proves that every application in scope has a disposition, a wave and a test. -->

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Undiscovered dependency breaks an application after cutover | Medium | High | Flow-log review, integration test of every DEP row | @portfolio-lead |
| RSK-002 *(Example)* | Network bandwidth insufficient for replication of large waves | Medium | Medium | Bandwidth test, stagger replication starts | @network-lead |
| RSK-003 *(Example)* | Business blackout period moved at short notice | Low | Medium | Monthly calendar check with business owners | @pmo-lead |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

| App ID | Strategy | Move group | Wave | Dependencies | Tests | Cutover runbook | Hypercare exit |
|---|---|---|---|---|---|---|---|
| APP-0142 *(Example)* | Replatform | MG-03 | 3 | DEP-001, DEP-002, DEP-004, DEP-005 | Smoke, integration, performance, UAT | Wave 3 runbook | YYYY-MM-DD |
| APP-0210 *(Example)* | Rehost | MG-05 | 4 | DEP-003, DEP-004 | Smoke, integration, UAT | Wave 4 runbook | YYYY-MM-DD |
| [APP-NNNN] | [Strategy] | [MG-NN] | [N] | [DEP-NNN] | [Tests] | [Runbook] | YYYY-MM-DD |

## 15. Glossary and references

<!-- Guidance: Define the migration terms used in this plan for business readers. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Move group | Set of applications and components that must migrate together |
| Wave | Batch of move groups cut over in the same period |
| Cutover | Switch of production traffic from source to target |
| Point of no return | Step after which rollback requires reverse data synchronisation |
| Hypercare | Period of heightened support after cutover |
| Migration factory | Repeatable process, team and tooling for migrating at scale |
| 7 Rs | Retire, retain, rehost, relocate, repurchase, replatform, refactor or re-architect |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| AWS Prescriptive Guidance, Guide for AWS large migrations: About the migration strategies, docs.aws.amazon.com | Current web edition | Section 4 strategy names |
| AWS Prescriptive Guidance, Guide for AWS large migrations: Phases of a large migration | Current web edition | Section 1.2 phases and workstreams |
| Microsoft Cloud Adoption Framework, Plan your migration, learn.microsoft.com | Page dated August 2025 | Dependency types, sequencing, rollback planning |
| [Discovery tool documentation] | [Version] | [Use] |

## Standard and licence note

Structure aligned with migration planning practice published by Amazon
Web Services (AWS Prescriptive Guidance, including the seven migration
strategies and the phases of a large migration) and by Microsoft (Cloud
Adoption Framework migration planning). Strategy and phase names belong
to their publishers and are used for reference only. This template is
original text written for this collection and reproduces no text from
those sources. Check the current official guidance before use; all
numbers in example rows are illustrative. Template licence: MIT.