What is a cutover plan and when do you write one?

What the document is

A cutover plan describes how an organisation gets from the system it runs today to the system it will run tomorrow. It covers the period from the last ordinary working day before the change through to the point where the new system is in normal operation and the old one is frozen or retired. It is a delivery document rather than a design document. It says nothing about why the solution looks the way it does and everything about the order things happen in, who does them, and what has to be true before the next step starts.

Most of what a cutover plan settles is dull in advance and expensive at three in the morning: whether the data load runs before or after the interface switch, who may approve a deviation out of hours, what happens to transactions raised during the freeze, and the point at which reversing stops being practical.

The sections it usually contains

• Scope and approach — what is moving, what is not, and whether the transition is big bang, phased or run in parallel.
• Timeline and sequence — ordered activities with start and end times, dependencies and named owners.
• Go/no-go criteria — the conditions checked before the window opens and at defined checkpoints inside it.
• Rollback and fallback — the reverse sequence, the triggers that start it, and the point of no return.
• Roles and contacts — who is on shift, for which hours, and the escalation route when they cannot be reached.
• Communications — who is told what, when, and through which channel, including the outage notice business users see.
• Freeze and post-cutover verification — what stops changing before the window, and the checks that confirm behaviour afterwards.

The cutover plan guide works through those sections in more detail, including the ones that tend to be missing on a first draft.

When you write it

Three inputs make the plan worth writing. Scope has to be stable enough that the list of systems, interfaces and data objects will not change again. A target date has to be agreed with the business, because the date drives the freeze, the notice period and the shift pattern. And the technical steps have to be understood well enough to be sequenced — not estimated to the minute, but known in order.

Written earlier than that, the plan is a placeholder that gets rebuilt from scratch. Written later, there is no time to rehearse it. The usual sequence is a first draft once the migration approach and the environment strategy are settled, a working version rehearsed in the first dry run, and a frozen version issued before the go/no-go meeting with changes only through a controlled route.

The dry runs are what turn the draft into something reliable. A step that reads as one line — "load master data" — becomes four steps with a duration and a verification once someone has actually run it against production volumes. Each rehearsal should produce a revised plan, not just a defect list.

Who writes it and who approves it

The plan is normally assembled by whoever is accountable for delivery, with each section written by the person who will execute it. Infrastructure writes the infrastructure steps. The data lead writes the load sequence. Support writes the verification checks they will run. Assembling it centrally and asking for review afterwards produces a document nobody feels responsible for on the night.

Approval sits with the group that will also make the go/no-go decision, so the criteria in the plan and the criteria in the meeting are the same criteria. The Go/No-Go Checklist records each of those criteria with an owner, an answer and an explicit note of whether it can be waived.

How it relates to the runbook

The plan sets the approach; the runbook is the timed, numbered task list executed inside the window. On a small change the two can be one document. On a programme with several teams working through the night they separate, because the audiences differ: the plan is read by people deciding whether to proceed, the runbook by people executing steps in order. The difference between the two matters most when the window is long enough for shifts to hand over.

The Cutover Runbook & Hypercare Pack holds both layers in one workbook, along with the hypercare period that follows the window.

What the plan does not cover

A cutover plan is not the project plan. The project plan runs for months and tracks delivery; the cutover plan runs for hours or days and tracks execution. It is also not the test strategy, and it is not by itself a rollback plan — the rollback needs its own sequence, its own timings and its own trigger conditions, because it will be read under pressure by people who have just had bad news.

On the night

The plan is only useful if the version being executed is the version everyone has. That means one issued copy, a version number on every page, a single place where progress is marked, and a named person who is the only one allowed to change the sequence. Deviations are recorded as they happen, not reconstructed afterwards, because the record is what the post-implementation review and the closure report will be built from.

Questions · All 36 templates