Cutover Runbook
A cutover runbook is the timed, task-level script executed during a go-live window. Each row is one step with a planned start time, a duration, an owner, the system it touches, the step it depends on, and the evidence that proves it completed. It is used live during the window, with actual times recorded against planned ones.
The runbook is an operational document, not a governance one. It is read at three in the morning by someone who needs to know what happens next, who is doing it and whether the previous step finished. Everything else — approach, rationale, criteria — belongs in the cutover plan.
What it contains
| Column | What it records |
|---|---|
| Step number | Sequential reference, used on the bridge to say where the team is |
| Planned start | Clock time, not an offset, so nobody has to calculate under pressure |
| Duration | The elapsed time measured in rehearsal, not estimated |
| Task | One action, written as an instruction |
| System or environment | What the step touches |
| Owner | The named individual executing it, with a fallback name |
| Depends on | The step numbers that must be complete before this one starts |
| Verification | How completion is confirmed, and what evidence is captured |
| Actual start and finish | Filled in live, which is what makes drift visible |
| Status | Not started, in progress, complete, failed, skipped |
| Notes | What actually happened, for the rehearsal debrief and the next cutover |
Runbooks also mark two kinds of special row: checkpoints, where progress is assessed against contingency and a decision is taken to continue, and the point of no return, after which rollback is no longer available. The Cutover Runbook & Hypercare Pack carries both alongside the contact list and the rota.
How it is used
Before the window, the runbook is the object of the dress rehearsal: it is executed end to end, timings are recorded and the document is corrected. During the window, one person drives it — reading out the step, confirming the owner has started, recording the actual time and confirming verification before the dependent step begins.
Afterwards it is evidence. The recorded times and verification notes support the go-live sign-off, and the notes column feeds the next transition. The plan versus runbook comparison covers which of the two documents each audience actually needs.
Where it goes wrong
Estimated durations are the first failure. A runbook built from guesses will fit the window on paper and overrun in practice, and the overrun is discovered when there is no contingency left to absorb it.
The second is steps written at the wrong grain — "migrate data" is not a step, it is a phase, and it hides an hour of drift. The third is missing verification: without a confirmation column the team moves on before the previous step has been proved, and the failure surfaces several steps later. The fourth is a runbook maintained in a document nobody can update concurrently, so the live version exists only in one person's head.
The fifth is a runbook that carries no contact detail. When a step fails at four in the morning, the question is who to call, and the answer needs to be in the same document as the step — with a second name for when the first does not answer. Runbooks used in anger normally hold the bridge details, the rota and the vendor escalation numbers on the front sheet, because nobody wants to be searching a shared drive at that point in the night.
Related terms
See also cutover plan, dress rehearsal and rollback plan.
Questions
How detailed should a cutover runbook be?
Detailed enough that a step can be started and verified without asking a question. In practice that means one action per row, with a named owner and a stated completion check.
Where do the durations come from?
From a timed dress rehearsal at production volumes. Durations carried over from estimates are the usual reason a window overruns.
Who drives the runbook during the window?
One person, usually the cutover manager, reading and recording against a single shared copy so there is only ever one version of where the team is.
What is a point of no return in a runbook?
The marked step after which rollback is no longer practical within the window. It is agreed in advance and shown explicitly in the sequence.