Cutover Plan vs Cutover Runbook: What's the Difference?

The plan is the approach; the runbook is the script. Which document you need, what belongs in each, and why small projects can merge them.

A cutover plan describes the approach to moving from the current state to the target state: scope, strategy, sequence, prerequisites, roles and decision points. A cutover runbook is the executable version of it — every task in the window, in order, with a clock time, a duration, an owner and a predecessor.

The plan is written for people deciding whether the approach is sound. The runbook is written for people executing it at three in the morning. They serve different readers, which is why merging them tends to produce a document that fails both.

Side by side

What belongs in the plan

• Cutover strategy — big bang, phased, parallel run — and why that choice was made
• Scope — which systems, interfaces, data and locations are in the window, and which are not
• The window — when it opens and closes, and why that date was chosen
• Prerequisites and freeze — what must be complete before it opens
• Decision points — go/no-go and the point of no return, described in principle
• Roles and escalation — who is accountable for what
• Fallback strategy — the approach to rollback, not the sequence
• Risk assessment for the cutover itself

What belongs in the runbook

• Every task, in sequence, with a clock time and a duration — never “day 1 morning”
• One named owner per task, plus a backup
• Predecessors, so it is obvious what a delay blocks
• Verification steps — how you know the task worked, not just that it ran
• Checkpoints with the criteria to be met and the person who calls each one
• The rollback sequence alongside it, in the same file
• The point of no return, as a dated row on the timeline
• Contact list with out-of-hours numbers, which differ from the ones on the website
• A running status column, updated live

The runbook belongs in a spreadsheet rather than a document, because during the window people need to filter to their own rows. A 40-page Word file cannot do that.

Do you need both?

For a large migration — ERP, core banking, a platform move affecting several business units — yes. The change board will not approve a spreadsheet, and the cutover team cannot execute a strategy document.

For a single application release over one weekend, one artefact is usually enough: a runbook with a short covering section describing the approach. The mistake to avoid is the opposite — writing only the plan, and then discovering on the night that nobody converted it into timed tasks.

The transition between them

The runbook should be built from the plan, not written independently, and it should be finished early enough to rehearse. A useful discipline: hold a walkthrough two weeks before the window, read the runbook line by line with the owners in the room, and time the rollback sequence. That walkthrough is where you discover the task with no owner, the two tasks that both claim to be first, and the rollback that takes longer than the window allows.

Then leave the plan alone. Once the runbook is live it is the operative document, and changes made to the plan during the window will not reach the people executing it.