# Cutover Plan: [Solution or release name]

> Cutover plan and runbook for moving a business from a legacy system,
> environment or platform to a new solution inside a fixed window. It
> covers strategy, the command centre, entry criteria and freezes,
> rehearsals, a T-minus timeline, the step-by-step runbook, go/no-go
> checkpoints, the point of no return, validation, rollback,
> communications, the issue log and sign-off. The gate cadence follows
> the communication gates in the AWS Prescriptive Guidance large
> migration playbooks (T-28, T-14, T-1 go or no-go, T-0 cutover
> meeting, hypercare start and end) and the cutover areas of the
> Microsoft Dynamics 365 implementation guide go-live checklist,
> paraphrased and extended for any technology. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one cutover plan per go-live event. A programme with several
  waves or rollouts keeps one plan per wave and reuses the structure.
- Fill section 1 (strategy) and section 2 (roles) first, then the
  freeze calendar in section 3. The timeline in section 5 and the
  runbook in section 6 are only credible after at least one rehearsal
  in section 4 has measured real durations.
- Every runbook step needs an owner, a start time relative to T-0, a
  duration, a predecessor and a verification. A step without a
  verification is a hope, not a step.
- Agree the point of no return (section 8) and the rollback triggers
  (section 10) with the business owner before the window opens, never
  during it.
- The worked example uses one consistent window: T-0 is Saturday 06:00
  local time, business restarts Monday 06:00 (T+48h), the measured
  rollback takes 9 hours plus a 3-hour buffer, so a rollback must
  start by T+36h. Recompute every derived time if you change one.
- Related documents: Go-Live Readiness Review
  (`project/go-live-readiness-review`), Hypercare Plan
  (`ops/hypercare-plan`), Operations Handover and Knowledge Transfer
  (`ops/operations-handover`), Migration Plan (`dev/migration-plan`),
  Migration Wave Plan (`project/migration-wave-plan`), Data Migration
  Strategy (`architecture/data-migration-strategy`), Data Migration
  Reconciliation (`project/data-migration-reconciliation`), Deployment
  Runbook (`ops/deployment-runbook`), Communication Plan
  (`project/communication-plan`).
-->

## Document control

<!-- Guidance: Identify the go-live event, the window and who owns the plan. A change to T-0, the window length or the point of no return is a new minor version and must be re-communicated to every role in section 2. -->

| Field | Value |
|---|---|
| Document ID | [CUT-PLAN-001] |
| Solution or release | [Solution name] [Release or wave] |
| Cutover approach | [Big bang / Phased by site / Phased by function / Parallel run / Pilot then rollout] |
| T-0 (start of cutover window) | [YYYY-MM-DD HH:MM time zone] |
| Window end (business restart) | [YYYY-MM-DD HH:MM time zone] |
| Point of no return | [T+NNh, YYYY-MM-DD HH:MM] |
| Latest rollback start | [T+NNh, YYYY-MM-DD HH:MM] |
| Version | [0.1] |
| Status | [Draft / Rehearsal / Approved / In execution / Closed] |
| Owner | [@cutover-manager] |
| Approvers/reviewers | [@business-owner], [@programme-director], [@solution-architect], [@service-owner], [@security-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Readiness review], [Hypercare plan], [Data migration plan], [Rollback scripts repository] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Programme director | [@name] | [Decision] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |
| Receiving service owner (operations) | [@name] | [Decision] | YYYY-MM-DD |
| Security and compliance | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from the migration and release plans |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Durations updated from mock cutover 1; data load split into two streams |
| 0.9 | YYYY-MM-DD | [@name] | *Example:* Dress rehearsal results added; rollback duration measured at 9 hours |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at the T-1 go or no-go meeting |

## Contents

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

1. [Scope, objectives and strategy](#1-scope-objectives-and-strategy)
2. [Roles and command centre](#2-roles-and-command-centre)
3. [Entry criteria and freezes](#3-entry-criteria-and-freezes)
4. [Rehearsal plan and results](#4-rehearsal-plan-and-results)
5. [T-minus timeline](#5-t-minus-timeline)
6. [Detailed runbook](#6-detailed-runbook)
7. [Go/no-go checkpoints](#7-gono-go-checkpoints)
8. [Point of no return](#8-point-of-no-return)
9. [Validation and reconciliation](#9-validation-and-reconciliation)
10. [Rollback plan](#10-rollback-plan)
11. [Communications](#11-communications)
12. [Issue and decision log](#12-issue-and-decision-log)
13. [Post-cutover checks and transfer to hypercare](#13-post-cutover-checks-and-transfer-to-hypercare)
14. [Sign-off](#14-sign-off)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope, objectives and strategy

<!-- Guidance: State exactly what moves in this window and what does not, and why this cutover strategy was chosen over the alternatives. Questions: which users, sites, legal entities, interfaces and data objects change system at T-0? What business outage can the organisation tolerate? Pitfall: a scope that silently includes "a few reports" or "one more interface" added after the last rehearsal. -->

### 1.1 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Order-to-cash and procure-to-pay processes for legal entities DE01 and FR01 | Legal entity UK01 (wave 2) |
| *Example:* 14 outbound and 9 inbound interfaces listed in the interface catalogue | Data warehouse re-platforming (separate release) |
| *Example:* Open orders, open invoices, balances at period end, master data | Closed transactions older than 2 years (archived, read-only access kept) |
| [Item] | [Item] |

### 1.2 Objectives and success criteria

| ID | Objective | Measure of success |
|---|---|---|
| CUT-OBJ-001 *(Example)* | Business restarts on the new solution at window end | Users process the first orders by Monday 07:00 |
| CUT-OBJ-002 *(Example)* | No loss or duplication of financial data | Trial balance in target equals legacy closing balance per entity and account |
| CUT-OBJ-003 *(Example)* | Outage stays inside the agreed window | Legacy read-only no earlier than T-0; target open no later than T+48h |
| CUT-OBJ-004 *(Example)* | Interfaces run without manual intervention | First scheduled run of every interface completes inside its normal duration |
| [CUT-OBJ-NNN] | [Objective] | [Measure] |

### 1.3 Cutover strategy

Choose the strategy deliberately and record the reasons. The strategy
drives the window length, the rollback design and the support load.

| Strategy | When it fits | Main cost or risk |
|---|---|---|
| Big bang (all users and data at once) | Tightly coupled processes, a single ledger, short tolerable dual running | Large blast radius; rollback is all or nothing |
| Phased by site, entity or function | Separable organisational units, low cross-unit transaction volume | Temporary interfaces between old and new; longer programme |
| Parallel run (both systems live) | Regulated calculations that must be proved equal over a cycle | Double data entry, reconciliation effort, user fatigue |
| Pilot then rollout | New ways of working that need proof with a small group | Pilot group may not represent volume or edge cases |
| Trickle or continuous sync | Large data volumes with replication tooling and a short final switch | Replication monitoring and conflict handling during sync |

| Decision field | Value |
|---|---|
| Selected strategy | *Example:* Big bang for two entities, with a weekend window |
| Reasons | *Example:* Shared order and inventory processes across both entities; temporary interfaces would cost more than a 48-hour outage |
| Alternatives rejected | *Example:* Parallel run rejected: double entry for warehouse staff is not feasible at peak |
| Tolerable business outage | *Example:* Saturday 06:00 to Monday 06:00, agreed with the business owner on YYYY-MM-DD |
| Decision reference | [ADR or steering committee minute ID] |

### 1.4 Assumptions and constraints

| ID | Type | Statement | Owner | Validated by |
|---|---|---|---|---|
| CUT-ASM-001 *(Example)* | Assumption | Legacy vendor support is available on call during the window | [@vendor-manager] | Signed support order |
| CUT-ASM-002 *(Example)* | Constraint | Bank file transmission cannot be paused for more than 24 hours | [@treasury-lead] | Bank agreement |
| CUT-ASM-003 *(Example)* | Constraint | No cutover in the last 5 working days of a financial quarter | [@finance-controller] | Finance calendar |
| [CUT-ASM-NNN] | [Type] | [Statement] | [@owner] | [Evidence] |

## 2. Roles and command centre

<!-- Guidance: Name a person and a backup for every role, with contact details that work at 03:00. Decide who can stop the cutover and who can authorise rollback. Pitfall: a single cutover manager on shift for 48 hours; plan handovers between shifts. -->

### 2.1 Roles

| Role | Responsibility during the window | Primary | Backup | Shift |
|---|---|---|---|---|
| Cutover manager | Runs the runbook, calls checkpoints, owns the clock | [@name] | [@name] | [Day / Night] |
| Business owner | Takes go/no-go and rollback decisions with the cutover manager | [@name] | [@name] | On call |
| Solution architect | Technical authority for deviations from the runbook | [@name] | [@name] | [Shift] |
| Data migration lead | Extraction, load and reconciliation streams | [@name] | [@name] | [Shift] |
| Integration lead | Interface shutdown, endpoint switch, first runs | [@name] | [@name] | [Shift] |
| Infrastructure and platform lead | Environments, network, DNS, certificates, backups | [@name] | [@name] | [Shift] |
| Security lead | Access changes, privileged sessions, logging | [@name] | [@name] | On call |
| Business validation lead | Key-user tests and acceptance | [@name] | [@name] | Day |
| Service desk lead | User messages, incident intake from T+48h | [@name] | [@name] | Day |
| Communications lead | Status updates in section 11 | [@name] | [@name] | Day |
| Scribe | Timestamps every step, decision and issue | [@name] | [@name] | Both |

### 2.2 RACI for key decisions

| Decision or activity | Cutover manager | Business owner | Solution architect | Data lead | Service owner |
|---|---|---|---|---|---|
| Start the cutover (GNG-2) | R | A | C | C | C |
| Accept data reconciliation (GNG-3) | R | A | C | R | I |
| Go live and pass the point of no return (GNG-4) | R | A | C | C | C |
| Deviate from a runbook step | A | I | R | C | I |
| Invoke rollback | R | A | C | C | I |
| Hand over to hypercare | R | I | C | I | A |

### 2.3 Command centre

| Item | Arrangement |
|---|---|
| Location | *Example:* Room 4.12 plus a permanent video bridge for remote staff |
| Bridge | [Conference link], open from T-1h to T+50h |
| Chat channel | [#cutover-release-name], one thread per phase |
| Status board | [Link to the live runbook tracker] |
| Checkpoint calls | *Example:* Every 2 hours on the hour, 15 minutes maximum, plus each go/no-go checkpoint |
| Shift changes | *Example:* 06:00 and 18:00 with a written handover in the chat thread (use Shift Handoff, `ops/shift-handoff`) |
| Escalation | Cutover manager, then business owner, then programme director |

## 3. Entry criteria and freezes

<!-- Guidance: List what must be true before T-0, with evidence, and the freezes that protect the window. Questions: which changes stop when, and who can grant an exception? Pitfall: a code freeze with no configuration or master data freeze, so the target drifts from what was rehearsed. -->

### 3.1 Entry criteria

| ID | Criterion | Evidence | Owner | Status |
|---|---|---|---|---|
| CUT-EC-001 *(Example)* | Go-live readiness review rated Ready or Ready with conditions | Readiness review decision record | [@programme-director] | [Met / Not met] |
| CUT-EC-002 *(Example)* | Dress rehearsal completed inside the window with all reconciliations passed | Section 4.2 results | [@cutover-manager] | [Status] |
| CUT-EC-003 *(Example)* | Rollback rehearsed and measured | Section 4.2, rollback row | [@solution-architect] | [Status] |
| CUT-EC-004 *(Example)* | Production environment built from the release baseline and verified | Deployment record, configuration checksum | [@platform-lead] | [Status] |
| CUT-EC-005 *(Example)* | Users trained and production roles assigned | Training completion report, role assignment export | [@change-lead] | [Status] |
| CUT-EC-006 *(Example)* | Hypercare roster staffed and published | Hypercare plan section 2 | [@service-owner] | [Status] |
| CUT-EC-007 *(Example)* | External parties confirmed their actions and contacts | Signed confirmations | [@integration-lead] | [Status] |
| [CUT-EC-NNN] | [Criterion] | [Evidence] | [@owner] | [Status] |

### 3.2 Freeze calendar

| Freeze | Starts | Ends | Scope | Exception approver |
|---|---|---|---|---|
| Code freeze *(Example)* | T-14d | T+4 business days | No code changes to the release baseline | Solution architect |
| Configuration freeze *(Example)* | T-7d | T+4 business days | No setup changes in target production | Solution architect |
| Master data freeze in legacy *(Example)* | T-3d 18:00 | Cutover complete | New customers and products created by a controlled request list only | Data migration lead |
| Infrastructure change freeze *(Example)* | T-3d | T+4 business days | No network, firewall, DNS or certificate changes except runbook steps | Platform lead |
| Transaction freeze in legacy *(Example)* | T-0 | Permanent | Legacy set read-only | Cutover manager |
| [Freeze] | [Start] | [End] | [Scope] | [@approver] |

Record every exception in the decision log (section 12) with the reason
and the re-test performed.

## 4. Rehearsal plan and results

<!-- Guidance: Rehearse until the plan fits the window with margin and the rollback has been proved. Each rehearsal uses production-like data volumes and the real runbook. Pitfall: treating a rehearsal as a test of the tools rather than of the timings, people and hand-offs. -->

### 4.1 Rehearsal plan

| ID | Rehearsal | Purpose | Environment and data | Planned date |
|---|---|---|---|---|
| REH-01 *(Example)* | Mock cutover 1 | Prove the sequence end to end and find missing steps | Pre-production, full copy of legacy taken at T-8 weeks | YYYY-MM-DD |
| REH-02 *(Example)* | Mock cutover 2 | Measure durations, tune parallel streams, rehearse reconciliation | Pre-production, fresh copy at T-5 weeks | YYYY-MM-DD |
| REH-03 *(Example)* | Dress rehearsal | Run the final runbook on the real clock with shift changes and checkpoints | Pre-production sized like production, copy at T-3 weeks | YYYY-MM-DD |
| REH-04 *(Example)* | Rollback rehearsal | Prove the rollback procedure in section 10 and measure it | Same as REH-03, run after it | YYYY-MM-DD |

Exit rule for rehearsals: a rehearsal counts as passed when every
step ran from the runbook without unrecorded workarounds, the total
duration plus contingency fits inside the window, and every
reconciliation in section 9 passed.

### 4.2 Rehearsal results

| Rehearsal | Planned duration | Actual duration | Longest step | Reconciliations | Defects raised | Result |
|---|---|---|---|---|---|---|
| REH-01 *(Example)* | 30 h | 41 h | Open item load, 14 h | 3 of 8 failed | 27 | Failed: sequence redesigned |
| REH-02 *(Example)* | 30 h | 33 h | Open item load, 9 h | 7 of 8 passed | 11 | Passed with actions |
| REH-03 *(Example)* | 30 h | 29.5 h | Open item load, 8.5 h | 8 of 8 passed | 2 | Passed |
| REH-04 rollback *(Example)* | 9 h | 9 h | Legacy database restore and log replay, 5 h | Legacy restored to T-0 state | 1 | Passed |
| [REH-NN] | [Duration] | [Duration] | [Step] | [Result] | [Number] | [Result] |

### 4.3 Lessons carried into the runbook

| ID | Finding | Change made | Runbook step |
|---|---|---|---|
| REH-L-001 *(Example)* | Load of open items dominated the window | Split into two parallel streams by entity | CUT-B03, CUT-B04 |
| REH-L-002 *(Example)* | Key users waited 2 hours for test data | Pre-built validation scripts with expected values | CUT-D01 |
| [REH-L-NNN] | [Finding] | [Change] | [Step ID] |

## 5. T-minus timeline

<!-- Guidance: Show the whole event from the first commit meeting to the end of hypercare on one page. Times are relative to T-0 and also given as clock times. Pitfall: phases that add up to more than the window, or a rollback deadline that sits after the window end. -->

### 5.1 Governance and communication gates before T-0

| Gate | Timing | Purpose | Owner |
|---|---|---|---|
| Timeline published | Before the wave or release plan is final | Set dates for every gate below | Cutover manager |
| T-28 commit meeting | 4 weeks before T-0 | Confirm scope, owners and the window with application and business owners | Programme manager |
| T-21 notice | 3 weeks before T-0 | Remind stakeholders and external parties of the date | Communications lead |
| T-14 checkpoint (GNG-1) | 2 weeks before T-0 | Review readiness actions; confirm the readiness review outcome | Cutover manager and solution architect |
| T-7 notice | 1 week before T-0 | Final reminder to users and the operations team; publish the outage message | Communications lead |
| T-1 go or no-go (GNG-2) | 24 to 48 hours before T-0 (*Example:* Thursday 14:00, T-40h) | Decide to start the cutover | Business owner |
| T-0 cutover meeting | Start of the window | Open the bridge and begin phase A | Cutover manager |

### 5.2 The cutover window

*Example:* T-0 is Saturday 06:00. Business restarts Monday 06:00, which
is T+48h. The rollback rehearsal measured 9 hours and the plan adds a
3-hour buffer, so a rollback must start no later than T+36h (Sunday
18:00) to finish by the window end.

| Phase | From | To | Duration | Clock time | Content |
|---|---|---|---|---|---|
| A. Legacy shutdown | T-0 | T+2h | 2 h | Sat 06:00 to 08:00 | Stop users, stop interfaces, drain queues, final legacy backup |
| B. Extract, load, reconcile | T+2h | T+18h | 16 h | Sat 08:00 to Sun 00:00 | Data extraction, transformation, loads, technical reconciliation |
| GNG-3 | T+18h | T+18h30m | 30 min | Sun 00:00 to 00:30 | Accept data reconciliation |
| C. Technical switch | T+18h30m | T+24h | 5.5 h | Sun 00:30 to 06:00 | Interface endpoints, jobs paused, roles, DNS and certificates |
| D. Business validation | T+24h | T+30h | 6 h | Sun 06:00 to 12:00 | Key-user tests, balance checks, print and output checks |
| GNG-4 | T+30h | T+31h | 1 h | Sun 12:00 to 13:00 | Go-live decision |
| Prepare go-live | T+31h | T+32h | 1 h | Sun 13:00 to 14:00 | Release jobs and interfaces from pause in controlled order |
| Point of no return | T+32h | | | Sun 14:00 | First interface opens and transactions post in the target |
| E. Controlled start | T+32h | T+48h | 16 h | Sun 14:00 to Mon 06:00 | First batch and interface runs, monitoring, user access opened |
| Hypercare starts | T+48h | | | Mon 06:00 | See Hypercare Plan (`ops/hypercare-plan`) |

Two deadlines bound the plan. The rollback deadline (T+36h) is the
last moment a rollback still fits inside the window; the point of no
return (T+32h) is the moment rollback stops being practical. Because
the point of no return comes first, the effective last rollback
decision is GNG-4. Planned work ends at T+30h, so phase D can overrun
by up to 5 hours: the one-hour GNG-4 meeting can start as late as
T+35h and still end by T+36h, when a rollback would have to start.
Phase E has no float, so any slip of GNG-4 also delays business restart
by the same amount: if GNG-4 starts at T+35h, the point of no return
moves to T+37h and user access opens about T+51h (Monday 09:00), which
breaks CUT-OBJ-003. Before the window, agree with the business owner the
latest restart time they accept (for example Monday 09:00) and which
phase E steps can be compressed or deferred to protect it (for example,
running the post-cutover checks in CUT-E04 in parallel with the end of
the batch cycle). If GNG-4 slips, the cutover manager re-issues the
timeline and informs the business owner of the new restart time.

```mermaid
flowchart LR
  G2[GNG-2 T-1 go or no-go] --> A[Phase A shutdown T-0 to T+2h]
  A --> B[Phase B extract and load T+2h to T+18h]
  B --> G3{GNG-3 data accepted}
  G3 -- no --> RB[Rollback section 10]
  G3 -- yes --> C[Phase C technical switch to T+24h]
  C --> D[Phase D business validation to T+30h]
  D --> G4{GNG-4 go live}
  G4 -- no --> RB
  G4 -- yes --> PNR[Point of no return T+32h]
  PNR --> E[Phase E controlled start to T+48h]
  E --> H[Hypercare from T+48h]
```

### 5.3 After the window

| Gate | Timing | Purpose | Owner |
|---|---|---|---|
| Hypercare start notice | 1 business day after cutover | Tell owners that cutover is complete and hypercare has started | Communications lead |
| Daily hypercare checkpoint | Each business day | Review incidents, KPIs and exit criteria | Hypercare lead |
| Hypercare end notice | When exit criteria are met (*Example:* planned at T+4 business days for a migration wave, longer for an enterprise application) | Confirm transfer to operations | Service owner |

## 6. Detailed runbook

<!-- Guidance: One row per step, in execution order. Use the start times from section 5.2 so that the runbook and the timeline cannot disagree. Keep detailed command-level instructions in linked work instructions; this table is the control sheet. Pitfall: steps owned by a team rather than a named person. -->

| Step | Phase | Start | Duration | Task | Owner | Predecessor | Verification | Status |
|---|---|---|---|---|---|---|---|---|
| CUT-A01 *(Example)* | A | T-0 | 15 min | Open bridge, roll call of all roles, confirm GNG-2 decision | Cutover manager | GNG-2 | All roles present | [ ] |
| CUT-A02 *(Example)* | A | T+15m | 15 min | Display outage banner; disable user logins to legacy | Platform lead | CUT-A01 | Test login refused | [ ] |
| CUT-A03 *(Example)* | A | T+30m | 30 min | Stop inbound interfaces; drain message queues to zero | Integration lead | CUT-A02 | Queue depth 0 on every channel | [ ] |
| CUT-A04 *(Example)* | A | T+1h | 15 min | Set legacy to read-only; record last document numbers | Data lead | CUT-A03 | Last numbers in the log | [ ] |
| CUT-A05 *(Example)* | A | T+1h15m | 45 min | Full legacy backup and copy to the rollback store | Platform lead | CUT-A04 | Backup verified by checksum | [ ] |
| CUT-B01 *(Example)* | B | T+2h | 3 h | Extract master data and open items | Data lead | CUT-A05 | Extract counts logged | [ ] |
| CUT-B02 *(Example)* | B | T+5h | 2 h | Load master data | Data lead | CUT-B01 | Load error rate within tolerance | [ ] |
| CUT-B03 *(Example)* | B | T+7h | 8 h | Load open items, entity DE01 (stream 1) | Data engineer 1 | CUT-B02 | Counts and totals match extract | [ ] |
| CUT-B04 *(Example)* | B | T+7h | 8 h | Load open items, entity FR01 (stream 2) | Data engineer 2 | CUT-B02 | Counts and totals match extract | [ ] |
| CUT-B05 *(Example)* | B | T+15h | 3 h | Load balances; run technical reconciliation reports | Data lead | CUT-B03, CUT-B04 | Reconciliation pack REC-01 to REC-08 produced | [ ] |
| CUT-G3 *(Example)* | Gate | T+18h | 30 min | GNG-3 data acceptance | Business owner | CUT-B05 | Decision logged | [ ] |
| CUT-C01 *(Example)* | C | T+18h30m | 2 h | Switch interface endpoints and credentials to target | Integration lead | CUT-G3 | Connectivity test per interface | [ ] |
| CUT-C02 *(Example)* | C | T+20h30m | 1.5 h | Import batch schedule in paused state | Platform lead | CUT-G3 | Job list matches the approved schedule | [ ] |
| CUT-C03 *(Example)* | C | T+22h | 1 h | Assign production roles; remove project super-user access | Security lead | CUT-G3 | Access report reviewed | [ ] |
| CUT-C04 *(Example)* | C | T+23h | 1 h | Update DNS and certificates for user and partner endpoints | Platform lead | CUT-C01 | Resolution and TLS check from outside | [ ] |
| CUT-D01 *(Example)* | D | T+24h | 5 h | Key users run validation scripts on migrated data | Business validation lead | CUT-C04 | Scripts VAL-001 to VAL-040 passed | [ ] |
| CUT-D02 *(Example)* | D | T+29h | 1 h | Finance balance sign-off per entity | Finance controller | CUT-D01 | Signed balance confirmation | [ ] |
| CUT-G4 *(Example)* | Gate | T+30h | 1 h | GNG-4 go-live decision | Business owner | CUT-D02 | Decision logged | [ ] |
| CUT-E01 *(Example)* | Prepare | T+31h | 1 h | Arm jobs and interfaces in the agreed order, held at the first-run gate | Integration lead | CUT-G4 | All armed, none released; order checked | [ ] |
| CUT-E02 *(Example)* | E | T+32h | 4 h | First interface runs; monitor error queues | Integration lead | CUT-E01 | Every interface ran once without error | [ ] |
| CUT-E03 *(Example)* | E | T+36h | 8 h | First overnight batch cycle | Platform lead | CUT-E02 | All jobs completed in normal duration | [ ] |
| CUT-E04 *(Example)* | E | T+44h | 2 h | Post-cutover checks in section 13 | Cutover manager | CUT-E03 | Checklist complete | [ ] |
| CUT-E05 *(Example)* | E | T+46h | 2 h | Open user access; send go-live message; transfer to hypercare | Service desk lead | CUT-E04 | Message sent; first users logged in | [ ] |
| [CUT-XNN] | [Phase] | [T+NN] | [Duration] | [Task] | [@owner] | [Step] | [Check] | [ ] |

Status values: not started, in progress, done, done with deviation
(record in section 12), blocked.

## 7. Go/no-go checkpoints

<!-- Guidance: Each checkpoint has explicit criteria, the evidence shown, the people who decide and what happens on a no-go. Questions: what is a hard stop and what can proceed with conditions? Pitfall: a "go" by silence, where nobody objects because nobody was asked. -->

| ID | When | Decision | Criteria | Decision makers | On no-go |
|---|---|---|---|---|---|
| GNG-1 | T-14d | Continue preparation for the planned date | Readiness review outcome known; no unresolved blocker without a dated plan; dress rehearsal scheduled | Programme director, business owner | Move the date; re-run the gate cadence |
| GNG-2 | T-1 (24 to 48 h before T-0) | Start the cutover | All CUT-EC criteria met or waived in writing; staff and external parties confirmed; no conflicting change in the change calendar | Business owner, cutover manager, service owner | Postpone; send the cancellation message in section 11 |
| GNG-3 | T+18h | Accept migrated data | Every reconciliation in section 9 within tolerance or explained and accepted | Business owner, data lead, finance controller | Fix and re-run within float, or roll back |
| GNG-4 | T+30h (latest T+35h) | Go live and pass the point of no return | Validation scripts passed; balances signed; no open severity 1 issue; float before the rollback deadline is positive | Business owner, cutover manager, solution architect | Start rollback no later than T+36h |

Ask each decision maker for an explicit go or no-go and record the
answer and time. The cutover manager states the remaining float before
each decision.

## 8. Point of no return

<!-- Guidance: Define the exact event after which rollback is no longer practical, and agree that after it the team fixes forward. Pitfall: a point of no return reached silently, for example when an interface releases payments before the go-live decision. -->

| Field | Value |
|---|---|
| Event | *Example:* Release of the first outbound interface run (start of CUT-E02, after CUT-E01 has armed every job and interface without releasing any), after which partner systems and banks hold data created in the target |
| Planned time | *Example:* T+32h, Sunday 14:00 |
| Why rollback becomes impractical | *Example:* Payment files and partner orders cannot be recalled; reversing them in the legacy system would need manual re-entry |
| Guard | No interface or job is released before GNG-4 is recorded as go |
| After the point of no return | Fix forward through the hypercare defect process; severity 1 issues use the emergency change path |
| Owner | [@business-owner] |

Before the point of no return, list the actions that are still
reversible and the ones already irreversible, so that the GNG-4
decision makers see the true cost of rolling back.

| Action | Reversible before PNR? | How |
|---|---|---|
| Legacy set to read-only *(Example)* | Yes | Re-enable write access |
| Data loaded into target *(Example)* | Yes | Target is discarded; no business transaction posted yet |
| DNS changed *(Example)* | Yes | Revert records; TTL lowered to 5 minutes at T-3d |
| Partner endpoints switched *(Example)* | Yes, with partner action | Partners revert to legacy endpoint using the agreed fallback list |
| [Action] | [Yes / No] | [How] |

## 9. Validation and reconciliation

<!-- Guidance: Define the checks, their tolerance and who signs. Tolerances are agreed before the window. Questions: which totals prove the data is complete and correct? Who can accept an explained difference? Pitfall: counting records but never checking amounts, so duplicated lines with offsetting values go unnoticed. -->

| ID | Check | Method | Tolerance | Signed by |
|---|---|---|---|---|
| REC-01 *(Example)* | Customer and supplier master record counts | Extract count versus load count versus target count | Zero unexplained difference | Data lead |
| REC-02 *(Example)* | Open receivables by entity and currency | Sum of open amounts legacy versus target | Zero difference | Finance controller |
| REC-03 *(Example)* | Open payables by entity and currency | Sum of open amounts | Zero difference | Finance controller |
| REC-04 *(Example)* | General ledger balances by account | Trial balance comparison | Zero difference | Finance controller |
| REC-05 *(Example)* | Inventory quantity and value by site | Quantity and valuation comparison | Quantity exact; value within rounding agreed in writing | Supply chain lead |
| REC-06 *(Example)* | Open sales and purchase orders | Count and line value | Zero difference | Business validation lead |
| REC-07 *(Example)* | Field-level sample | 200 random records per object compared field by field | No mismatch on mandatory fields | Data lead |
| REC-08 *(Example)* | Document numbering continuity | Next numbers in target follow the last numbers recorded at CUT-A04 | Exact | Data lead |
| [REC-NN] | [Check] | [Method] | [Tolerance] | [@owner] |

Store the reconciliation evidence with the Data Migration
Reconciliation record (`project/data-migration-reconciliation`).
Business validation scripts (VAL-NNN) list the transaction, the input
data, the expected result and the tester.

## 10. Rollback plan

<!-- Guidance: Rollback is a plan with triggers, an owner, a procedure and a measured duration, not a sentence. Questions: how is the legacy system restored to its T-0 state? What happens to anything already done in the target? Pitfall: a rollback never rehearsed, or one whose duration was guessed. -->

### 10.1 Triggers

| ID | Trigger | Detected by | Decision deadline |
|---|---|---|---|
| RBK-001 *(Example)* | Reconciliation failure that cannot be fixed and re-run within the float | REC checks at GNG-3 | GNG-3, or GNG-4 at the latest |
| RBK-002 *(Example)* | A critical business process fails validation with no workaround | VAL scripts at GNG-4 | GNG-4 |
| RBK-003 *(Example)* | Cumulative delay means GNG-4 cannot be held by T+35h | Cutover manager clock | Immediately when float reaches zero |
| RBK-004 *(Example)* | Security control missing in production (logging, encryption, access) | Security lead check at CUT-C03 | GNG-4 |
| [RBK-NNN] | [Trigger] | [Source] | [Deadline] |

### 10.2 Procedure

| Step | Action | Owner | Duration (measured in REH-04) |
|---|---|---|---|
| RB-01 | Announce rollback on the bridge; record trigger, time and decision maker | Cutover manager | 15 min |
| RB-02 | Stop all target jobs and interfaces; block user access to the target | Platform lead | 15 min |
| RB-03 | Revert interface endpoints, credentials and DNS to legacy | Integration lead | 1.5 h |
| RB-04 | Restore legacy from the CUT-A05 backup if any legacy write occurred; otherwise re-enable write access | Platform lead | 5 h (restore and log replay) |
| RB-05 | Smoke test legacy with key users | Business validation lead | 1.5 h |
| RB-06 | Send rollback communication; reopen legacy to users | Communications lead | 30 min |
| | Total | | 9 h |

Keep the target environment intact after a rollback for root-cause
analysis. Hold a review within 2 business days and record findings with
Lessons Learned (`project/lessons-learned`).

## 11. Communications

<!-- Guidance: Plan every message in advance with its audience, channel and sender, including messages for a delay, a no-go and a rollback. Pitfall: users learn about the outage from a login error. -->

| ID | When | Audience | Message | Channel | Sender |
|---|---|---|---|---|---|
| COM-01 *(Example)* | T-28 | Application and business owners | Date, window, scope, what they must do | Meeting and email | Programme manager |
| COM-02 *(Example)* | T-21 | All stakeholders and external partners | Reminder of the date and partner actions | Email | Communications lead |
| COM-03 *(Example)* | T-14 | Owners and leads | Readiness status and open actions | Checkpoint meeting | Cutover manager |
| COM-04 *(Example)* | T-7 | All users, operations team | Outage window, what to finish before Friday | Email, intranet | Communications lead |
| COM-05 *(Example)* | T-1 after GNG-2 | All users, partners | Cutover confirmed or postponed | Email, partner portal | Business owner |
| COM-06 *(Example)* | Every 2 h during the window | Leadership and owners | Progress, float, issues | Status page and chat | Cutover manager |
| COM-07 *(Example)* | T+46h | All users | System live, how to get help | Email, intranet, banner | Service desk lead |
| COM-08 *(Example)* | On rollback | All users, partners | Legacy back in service, next steps | Email, phone tree for partners | Business owner |
| COM-09 *(Example)* | Hypercare start and end | Owners, operations | Hypercare started; later, hypercare complete and support route | Email | Service owner |
| [COM-NN] | [When] | [Audience] | [Message] | [Channel] | [@sender] |

Use the Communication Plan (`project/communication-plan`) for message
templates and the Maintenance Notice (`ops/maintenance-notice`) for the
user outage notice.

## 12. Issue and decision log

<!-- Guidance: Log every issue, deviation and decision during the window with a timestamp. Triage quickly: is it on the critical path, does it threaten a reconciliation, does it need a decision? Pitfall: issues fixed in chat with no record, so hypercare inherits unknown changes. -->

| ID | Time | Type | Description | Severity | Critical path? | Owner | Action and outcome | Closed |
|---|---|---|---|---|---|---|---|---|
| CI-001 *(Example)* | T+9h20m | Issue | Stream 2 load rejected 312 records for missing tax codes | 2 | No | Data lead | Tax codes added by approved data fix; records reloaded | T+11h |
| CI-002 *(Example)* | T+22h40m | Deviation | DNS change done 20 minutes early to recover time | 3 | Yes | Platform lead | Approved by solution architect; verified | T+23h |
| CD-001 *(Example)* | T+30h55m | Decision | GNG-4 go, with condition that report R-17 is fixed in hypercare | n/a | n/a | Business owner | Condition passed to hypercare known issues | T+31h |
| [CI-NNN] | [Time] | [Type] | [Description] | [1 to 4] | [Yes / No] | [@owner] | [Action] | [Time] |

Severity during the window: 1 stops the cutover or threatens a
reconciliation; 2 delays the critical path or needs a workaround at
go-live; 3 has no effect on the critical path; 4 is cosmetic.

## 13. Post-cutover checks and transfer to hypercare

<!-- Guidance: Before users arrive, confirm that the system, interfaces, jobs, monitoring and support are in the state the hypercare team expects. Pitfall: monitoring alerts still routed to the project team's chat rather than to the on-call rota. -->

| ID | Check | Owner | Result |
|---|---|---|---|
| PCC-01 *(Example)* | All interfaces completed one run; error queues empty or triaged | Integration lead | [Pass / Fail] |
| PCC-02 *(Example)* | First batch cycle completed; durations within rehearsal values | Platform lead | [Result] |
| PCC-03 *(Example)* | Monitoring dashboards and alerts live and routed to the hypercare rota | Service owner | [Result] |
| PCC-04 *(Example)* | Backups of the target scheduled and the first one successful | Platform lead | [Result] |
| PCC-05 *(Example)* | Project and cutover accounts disabled or time-limited | Security lead | [Result] |
| PCC-06 *(Example)* | Known issues and conditions transferred to the hypercare log | Cutover manager | [Result] |
| PCC-07 *(Example)* | Legacy kept read-only with access for look-up; decommissioning date set | Data lead | [Result] |
| [PCC-NN] | [Check] | [@owner] | [Result] |

Transfer to hypercare follows the Hypercare Plan (`ops/hypercare-plan`);
the later transfer of ownership to operations follows Operations
Handover and Knowledge Transfer (`ops/operations-handover`).

## 14. Sign-off

<!-- Guidance: Close the cutover formally once phase E is complete. Pitfall: no record that the business accepted the result, which later turns a data dispute into a blame dispute. -->

Completion criteria: all runbook steps done or closed as deviations;
reconciliations signed; post-cutover checks passed; issues either closed
or transferred to the hypercare log with an owner.

| Role | Name | Statement | Date and time |
|---|---|---|---|
| Cutover manager | [@name] | Runbook complete; log archived | YYYY-MM-DD HH:MM |
| Business owner | [@name] | Business accepts the cutover result | YYYY-MM-DD HH:MM |
| Finance controller | [@name] | Balances confirmed | YYYY-MM-DD HH:MM |
| Service owner | [@name] | Hypercare accepted | YYYY-MM-DD HH:MM |

Actual versus plan summary:

| Measure | Plan | Actual |
|---|---|---|
| Window used | 48 h | [Hours] |
| Point of no return | T+32h | [T+NNh] |
| Issues logged (severity 1 / 2 / 3 / 4) | n/a | [N / N / N / N] |
| Deviations | 0 | [Number] |

## 15. Glossary and references

<!-- Guidance: Define terms that the business and technical teams use differently. -->

### 15.1 Glossary

| Term | Meaning in this plan |
|---|---|
| T-0 | Start of the cutover window; all times are relative to it |
| T-minus schedule | Sequence of gates and notices counted in days before T-0 |
| Go/no-go checkpoint | Recorded decision with criteria and named decision makers |
| Point of no return (PNR) | Event after which rollback is no longer practical and the team fixes forward |
| Float | Time between planned completion and the latest rollback decision |
| Mock cutover | Rehearsal of the runbook in a non-production environment |
| Dress rehearsal | Final rehearsal on the real clock with the real team |
| Rollback | Return of the business to the legacy system at its T-0 state |
| Hypercare | Period of elevated support after go-live |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| AWS Prescriptive Guidance, Project governance playbook for AWS large migrations (communication gates T-28 to hypercare end), docs.aws.amazon.com | Initial publication 2022-02-28; PDF checked 2026-10-23 | Gate cadence in sections 5 and 11 |
| AWS Prescriptive Guidance, Migration playbook for AWS large migrations, task 3 cutover tasks, docs.aws.amazon.com | Web edition checked 2026-10-23 | Cutover task tracking |
| AWS Prescriptive Guidance, Introduction to governance for large migrations, preparing the organization (hypercare, cutover call), docs.aws.amazon.com | Web edition checked 2026-10-23 | Command centre and hypercare transfer |
| Microsoft Dynamics 365 implementation guide, go-live checklist (cutover area), learn.microsoft.com | Page updated 2026-07-15 | Cutover go/no-go and exit criteria themes, paraphrased |
| Microsoft Dynamics 365 implementation guide, prepare your production environment to go live, learn.microsoft.com | Page updated 2026-10-15 | Cutover plan contents |
| [Internal change management policy] | [Version] | [Emergency change path] |

## Standard and licence note

Structure aligned with the communication gates and cutover tasks in the
AWS Prescriptive Guidance large migration playbooks and with the
cutover and go-live readiness areas of the Microsoft Dynamics 365
implementation guide. Gate names and timings are cited for mapping;
checklist items are paraphrased in original wording and no vendor text
or template is reproduced. Amazon Web Services, AWS, Microsoft and
Dynamics 365 are trademarks of their owners; this template is not
affiliated with or endorsed by them. This template is original text
written for this collection. Check the current official guidance before
use. Template licence: MIT.