What belongs in a cutover runbook?
A cutover runbook is the operational sequence of activities used by teams to execute a cutover. It translates the approved transition plan into steps operators can follow during the live event.
A good runbook answers what happens next, who is responsible, what must be true before starting and how successful completion is known.
- Ordered activity reference and instruction
- Named executor and supporting team
- Entry conditions and dependencies
- Expected duration and decision deadline
- Completion criteria, checklist and evidence
- Validation or approval where required
- Escalation and contingency guidance
Cutover plan vs runbook
The cutover plan is the governed model of scope, timing, ownership and dependency. The runbook is the execution-oriented view of that model. Some organisations use the terms interchangeably; what matters is that operators receive actionable detail without creating a disconnected copy.
One governed source can provide a detailed operator view and a concise management view.
| Concern | Cutover plan | Runbook |
|---|---|---|
| Primary use | Design and govern transition | Execute the approved sequence |
| Timing | Planned baseline | Planned and actual runtime |
| Detail | Integrated programme logic | Actionable operator instruction |
| Control | Version and approval | Submission, evidence and acceptance |
What operators need during execution
Operators need a focused queue of their work, clear dependency state, instructions, evidence requirements and a safe way to report a blocker. They should not have to search a programme-wide spreadsheet or wait for a conference call to learn whether a predecessor has completed.
The interface should distinguish ready, running, blocked, submitted and accepted work.
What managers need from the same runbook
Managers need progress, overdue work, blockers, critical-path threats, outstanding validation, workstream health and forecast. These views should be derived from the same runtime events that operators record, not from a parallel reporting process.
Role-oriented views reduce noise without creating competing truths.
Static runbooks and live runbooks
Static documents remain useful for approved procedures, offline contingency and rehearsal packs. Their limitations appear when many teams update status concurrently, dependencies become executable controls and management requires current exception information.
A live runbook should not discard the approved baseline. It should add controlled runtime events, permissions and evidence around it.
Runbook governance
Governance should be proportional. An assigned executor may confirm ordinary completion. Where a result requires independent checking, a validator accepts or rejects it. Where business or risk authority is required, an approver records the decision and rationale.
The audit trail should show who acted, when, against which version and with what evidence.
Runbook checklist
Before live use, verify the runbook as an operating tool.
- The baseline is approved and identifiable
- Every activity has an actionable owner
- Dependencies prevent unsafe starts
- Time zones and timestamps are clear
- Evidence can be attached or referenced
- Blocked work has an escalation path
- Validators and approvers are assigned only where required
- Management views use the same runtime data
- Offline contingency is understood
- Changes are governed during execution
Give every team the right execution view
CutoverCenter turns an approved plan into role-aware execution views for operators, validators, approvers and management.