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.
Document control
| 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
1. Scope, objectives and approach
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
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
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.
| 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
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
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
The calendar shows each wave's preparation, replication, cutover and
hypercare windows, with business freeze periods marked so that no
cutover falls inside them.
7. Testing strategy
| 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
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 | [ ] |
9. Rollback criteria and procedure
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
- Announce the rollback decision on the cutover channel and record the
trigger and time.
- Put the target into maintenance mode and stop writes.
- If the target accepted writes, run the reverse synchronisation or
replay procedure for the affected data stores and validate counts.
- Restart the source servers, switch DNS or load balancers back and
run the smoke tests against the source.
- 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
| 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
| 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
| 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
| 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
| 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
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.