Cutover Plan Template: What Goes In It (And What People Forget)

A cutover plan template covering timeline, rollback triggers, comms and go/no-go criteria — plus the five things teams leave out until it's too late.

A cutover plan is the hour-by-hour script for moving from the old system to the new one. It is not the project plan and it is not the test plan. It covers a window that usually runs from Friday evening to Monday morning, and during that window nobody has time to work out who is supposed to do what.

If you are writing one for the first time, here is what the document actually needs to contain.

The seven sections of a cutover plan

1. Cutover timeline. Every task in the window, in order, with a start time, a duration, an owner and a predecessor. Use clock times, not "day 1 morning". At 03:40 on a Saturday nobody wants to interpret relative timings.

2. Go/no-go criteria and decision points. Name the specific conditions that must be true before you proceed past each checkpoint, and name the person who makes the call. "Data migration reconciliation within 0.1% variance" is a criterion. "Migration looks OK" is not.

3. Rollback plan. The reverse sequence, with its own timeline and its own owner. Critically: the point of no return — the moment after which rollback is no longer possible — must be marked explicitly on the timeline, with the time by which you need to have decided.

4. Roles and contact list. Names, phone numbers, and backup names. Include vendor escalation numbers and the out-of-hours numbers, which are different from the ones on the website.

5. Communications plan. Who is told what, when, through which channel. Separate lines for end users, the business, the steering committee, and external parties. Pre-write the messages — including the message you send if it goes wrong. Writing that one under pressure produces bad wording.

6. Freeze and prerequisites. Change freeze start and end, what must be completed before the window opens, and the sign-offs you need in hand.

7. Post-cutover verification. The checks that confirm the new system is genuinely working — smoke tests, first batch run, first transaction, reconciliation — with owners and expected results. Plus hypercare arrangements for the days after.

Five things teams leave out

The point of no return. Almost every first-time cutover plan has a rollback section and no explicit deadline for deciding to use it. The result is a 4am debate about whether there is still time. Put a time on the timeline.

Who is allowed to say stop. Escalation paths are usually documented upward. The person watching the reconciliation numbers at 2am needs explicit authority to halt, or they will wait for someone senior to wake up.

Rest and shift handover. A 36-hour window means people are making decisions after being awake for twenty hours. Plan shifts, and plan a handover format so the incoming shift knows what has already been tried.

The dependency on someone else's window. If another system is also releasing that weekend, or if a batch job runs at 01:00 regardless of what you are doing, that belongs on your timeline.

The failed-cutover comms. Teams write the success announcement and not the other one.

Building it yourself

A workable cutover plan is a spreadsheet, not a document. The timeline needs to be sortable and filterable by owner, because during the window people want to see only their own rows. The rollback sequence needs to sit alongside it in the same file so nobody is hunting through email at 3am.

Expect to spend a day or two building the structure the first time, then adapting it per release. The structure barely changes between releases; the content changes completely.