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.
Document control
| 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
1. Scope, objectives and strategy
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
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
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
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
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.
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
| 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
| 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
| 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
| 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
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
| 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
| 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
| 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
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
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.