A runbook is the live operating model for a cutover event. It connects teams, systems, activities, evidence, issues and decisions so the command centre can distinguish what was planned from what is actually happening.
Overview
An enterprise cutover runbook is the executable form of the approved plan. It tells every participant what is eligible now, what must happen next, which exceptions need attention and which decisions are approaching.
A strong runbook combines schedule and operating control. It preserves planned, forecast and actual time; prevents dependent work from starting early; records evidence; and keeps issues, escalation and rollback connected to the affected activity.
When this guide is used
Use the runbook during rehearsals, dress rehearsal, Production cutover and early hypercare. Prepare it before the window, then operate from it as the single execution record.
- Rehearsal teams use it to expose unrealistic timing and missing controls.
- Technical leads use it to see eligible work and submit evidence.
- Business leads use it to validate outcomes and record approvals.
- The command centre uses it to manage exceptions and forecast impact.
- Executives use it to understand posture, material risk and pending decisions.
Establish the operating model
Define the command structure before execution. Name the cutover manager, workstream leads, issue manager, business decision authority, rollback authority and communications owner. Clarify who may start, complete, validate, approve, block or override work.
Make eligibility explicit
An activity is ready only when its predecessors are complete, the run is active, the correct environment is selected and the participant has authority to act. “Scheduled now” is not the same as “eligible now.”
If a validator returns work, the activity should move back to an executable state with the reason preserved. If an activity is blocked or placed on hold, require a reason and surface downstream impact.
Operate planned, forecast and actual time
The approved plan supplies baseline start and finish. The current forecast changes as actual execution progresses and dependencies move. Actual timestamps record what happened.
Do not overwrite baseline dates to make the plan look current. That destroys the variance signal leaders need. Instead show baseline, forecast and actual together, then propagate forecast changes through the dependency graph.
Coordinate automated and human work
Automation should be invoked only when the activity is eligible. The runbook must identify the repository, workflow, immutable release reference, target environment and verified provider outcome.
An automated activity should not be manually marked successful by a project resource. A verified external result closes it. If an exceptional override is necessary, restrict it to an authorised cutover manager and preserve the reason, actor and evidence.
Manage exceptions, not status noise
The command centre should focus on work that changes a decision: blocked activities, overdue critical work, forecast threats, failed validation, unresolved high-severity issues and gates awaiting authority.
Record the deviation against the affected activity and environment.
Name an owner, severity, impact and next update time.
Block unsafe successors or activate a workaround.
Continue, conditionally proceed, hold or rollback.
Verify the result and preserve closure evidence.
Carry the lesson into the next rehearsal or stage.
Capture evidence and decisions
Completion evidence should be proportionate to the claim. Confirmation may be enough for a communication activity. Deployment may require a workflow run and commit. Validation may require a test result, log or signed reconciliation.
Gates preserve an immutable decision snapshot: authority, outcome, rationale, conditions, residual risks, time and supporting evidence. Readiness informs that decision; it does not make it.
Make rollback executable
The runbook must be able to switch from forward execution to recovery without inventing a new plan. Recovery activities require predecessors, owners, durations and validation just like forward work.
Best practices
- Keep the active view centred on now, next and exceptions.
- Give each participant a focused personal queue instead of the full administrative product.
- Require reasons for blocked, on-hold and not-applicable outcomes.
- Separate execution, validation and approval when risk warrants it.
- Show the direct downstream impact of a delayed activity.
- Link every issue and decision to the affected activities and environment.
- Preserve provider evidence for automation rather than screenshots alone.
- Use an agreed UTC or programme timezone and display it clearly.
- Close the run only after operational handover and evidence review.
Common mistakes
| Mistake | Better control |
| Command centre reads every task aloud | Focus on exceptions, decisions and forecast impact. |
| People update a copy of the plan | Operate from one governed run record. |
| Completion entered after the event | Capture state, actual time and evidence as work happens. |
| Automated deployment manually closed | Require verified workflow outcome or authorised override. |
| Issue kept in chat | Link it to activity, owner, severity, decision and resolution. |
| Baseline dates edited during execution | Preserve baseline and update forecast separately. |
Runbook checklist
Frequently asked questions
Build an explainable plan—then govern every rehearsal and go-live.
CutoverCenter turns programme scope into an editable draft, preserves accountable approvals and captures operational evidence from SIT to Production.