What is the difference between a cutover plan and a runbook?
A cutover plan sets out the approach: what is moving, when, who is involved, the go/no-go criteria and the fallback. A runbook is the executable script for the window itself — numbered steps with a duration, an owner, a dependency and a verification. The plan is approved once; the runbook is rehearsed, versioned and worked through line by line.
Different jobs, different readers
The confusion is understandable, because on a small change the two documents are the same file. They separate as soon as more than one team is executing steps in sequence, because they answer different questions for different people.
The plan answers: are we doing this, on what basis, and what happens if it goes wrong. Its readers are the people deciding whether the change proceeds — sponsors, service owners, the change board, the business leads who have to staff a verification team at six in the morning.
The runbook answers: what happens next, who does it, how long does it take, and how do we know it worked. Its readers are the people awake during the window. They are not making decisions about scope; they are working through a list and reporting status.
Side by side
| Cutover plan | Runbook | |
|---|---|---|
| Purpose | Sets the approach and the conditions | Executes the sequence |
| Granularity | Phases and blocks of activity | Individual steps, often to the minute |
| Written by | Delivery, with input from each workstream | The people who will run each step |
| Read by | Decision-makers and stakeholders | The execution team on shift |
| Lifecycle | Drafted, reviewed, approved, frozen | Drafted, rehearsed, revised after each dry run |
| Format | Document with narrative sections | Table: step number, task, owner, start, duration, dependency, verification, status |
| Used when | Before the window, at go/no-go | During the window, minute by minute |
What is in the plan and not the runbook
Scope and approach. The rationale for big bang versus phased. The freeze rules — which systems stop accepting changes and from when. The communications plan. The roles and the escalation route. The go/no-go criteria and who owns each one. The fallback position in narrative form, including what the business does if the change is reversed. These are all things you need to have agreed before the window, and none of them are useful as a line in a task list.
What is in the runbook and not the plan
Every step, numbered. The clock time each step is expected to start. The duration measured from the last dry run. The person executing it and the person verifying it. The dependency — which step numbers must be complete first. The check that proves the step worked, written specifically enough that two people would agree on the answer. A status column that gets marked as the night progresses, and a comments column that records deviations at the time they happen.
A runbook also carries the operational detail nobody writes down until they need it: connection strings, job names, the order services are stopped and started, the number to ring for the third-party hosting provider at two in the morning. The Cutover Runbook & Hypercare Pack keeps the step table and that reference material in one workbook so the shift is not searching across files.
Where the rollback lives
Both. The plan states the fallback position and the authority to invoke it. The runbook holds the reverse sequence as its own numbered list, with its own timings, so that calling a rollback means turning to a page rather than working out what to do. The triggers sit at the checkpoints in the runbook where they will actually be read. The rollback plan guide and the Rollback Plan Template cover the trigger and point-of-no-return structure.
How they are produced
The plan comes first, because the runbook is a decomposition of it. Once the sequence in the plan is agreed at block level, each workstream writes its own steps underneath. The result is assembled, de-conflicted where two teams want the same environment at the same time, and then rehearsed.
Rehearsal is the point of difference. A plan is reviewed; a runbook is executed. Each dry run produces corrected durations, missing steps that only appear when someone tries to do the work, and verification checks that turn out to be ambiguous. The plan changes rarely after approval; the runbook changes after every rehearsal until the version issued for the window.
When one document is enough
A single-team change with a short window, one system and a simple revert does not need two documents. Forcing the split there produces a plan that repeats the runbook and a runbook that repeats the plan, and the version that gets read on the night is whichever one someone printed. The split earns its place when the window is long enough for a handover, when several teams execute in sequence, or when the decision to proceed is taken by people who will not be present during execution. The longer comparison and the cutover plan guide set out the structures for both.
Questions
Can the runbook be a spreadsheet?
Usually it is. The step table needs sorting, filtering, timing arithmetic and a status column, all of which a spreadsheet handles and a document does not.
Who owns the runbook during the window?
One named coordinator, who is the only person allowed to change the sequence or mark a step complete on behalf of someone else. Everyone else reports status to them.
How detailed should a runbook step be?
Detailed enough that someone who is competent but not the author could execute it. If a step needs tacit knowledge, it needs either more detail or a named person who must be awake.
Does the runbook include business verification?
Yes. The checks the business team run before sign-off are steps like any other, with a start time, an owner and a pass or fail result.