The cutover plan standard Building a plan that can actually be run

They serve different readers and they fail in different ways. Collapse them into one and the program arrives at the window holding a calendar.

Published templates make the difference visible in their columns. A runbook carries planned start and end times and actual start and end times, which is what turns a plan into an execution record R3. Vendor methodology draws the same line. One guide separates a cutover strategy from a cutover plan and defines the plan as the detailed task list with an owner and a backup owner per task, verification and sign-off steps, and a rollback plan R1. Another runs from strategy to planning to the cutover project plan to the simulation, and describes the project plan as the mechanism used during the production cutover to signal when to start the next activity in sequence R10.

Inherited plans fail in four recognizable ways. Where yours sits decides whether you edit it or rebuild it.

Every line carries twelve attributes. Set the schema before anyone writes the first task, because retrofitting it across two thousand lines is a project of its own.

Two published vendor column sets agree on the two that aren't obvious: a backup owner and a verification step for every task R1 R2. Add a notes field for the bridge call and stop there. Somebody has to maintain every extra column at two in the morning.

Names get read under pressure, filtered, sorted and quoted in status reports. Write each one as an instruction somebody can carry out.

Ban support, assist, manage and coordinate as the leading verb. If a name contains "and," it's probably two tasks.

Keep decisions as tasks too. Where the partner takes work to a point and the organization has to decide, that decision is a named line with an owner and a duration. It's the most common missing line type in a partner-authored plan, and it's exactly where a window stalls: in the twenty minutes spent waiting for somebody to say yes.

A plan built from dates gets rewritten every time one of them moves. That's how a plan gets rolled forward three times and stops being trusted. A plan built from dependencies recalculates.

There's a hard, auditable test for this in federal audit methodology. Every activity should have at least one predecessor and at least one successor. The only exceptions are the start and finish milestones, and any activity missing that logic has to be justified in the schedule documentation R4. The same guidance flags dangling logic, where a start-to-start or finish-to-finish link leaves a date undriven, so an activity can run indefinitely without visibly affecting anything downstream. It also requires constraints and lags to be minimized and justified R4.

Run that test across your plan. The count of failing lines is your rebuild estimate.

Measure float, then defend it. If float can't be stated as a number, the plan can't answer the only question executives ask. Report it weekly and treat consumption as a risk event instead of normal variance.

Build the delta view before you baseline, too. It's the filtered view that answers "what happens if go-live moves two weeks." Programs get asked that under pressure and answer it with a two-week analysis. With the view ready, it's a one-hour conversation.

Six hundred lines and two thousand can both be correct. What matters is that the rule is written on the plan and applied the same way everywhere, because you can't report on a plan that's decomposed inconsistently.

The business-task category is worth naming out loud, because partners don't write it. One published guide lists the work types a cutover plan must cover and includes business tasks such as reconciliation, posting and opening of periods alongside the technical work R2. One university split its whole cutover into two categories: system cutovers, meaning turning one system off to turn another on, and process changes, meaning the interim procedures and catch-up tracking that let the business keep running R9. Most technical plans leave that second category out entirely.

Published freeze calendars show what those lines look like once they're dated and owned. One runs from two months before go-live to three months after. It carries entries like purchasing cards switched off for five days, with a warning to renegotiate recurring vendor charges, and no new hire start dates allowed inside a two-week window R7. Another is laid out system by system across sixteen legacy systems, with the conversion snapshot taken twelve days before go-live, one system read-only for a full two weeks, and a documented manual approval route through an expense system blackout R8.

None of that is technical work. All of it belongs in the plan with a name against it, which is why one large public program scores go-live readiness across six named dimensions, with change, operations and business sitting alongside technical and data R11.

Decide before the plan passes a few hundred lines. Migrating mid-build costs two weeks and loses history. The deciding question is who has to update a line at three in the morning, and on what device.

Whichever you choose, prove it in a rehearsal, with the actual people updating actual lines on their actual devices. A tool that works in a demo and fails on a phone in a parking lot hasn't been tested.

Write down maintenance ownership separately from task ownership. The cutover lead owns the schema and the cross-track dependencies. Track leads own their own lines and durations. The sponsor owns the anchors and the baseline, and the PMO owns version control.

A baseline is a commitment, and every re-baseline costs credibility. Don't baseline until every box on the gate is ticked. If the plan isn't there yet, say so publicly instead of baselining a plan you already know is incomplete.

After baseline, adding or removing a task takes a proposal from the track lead and acceptance from the cutover lead, with a one-line reason recorded. That record is how you tell a plan being improved from a plan being quietly re-scoped.

Re-baseline only when an anchor moves. Tasks moving inside existing float is normal. Programs that re-baseline for ordinary variance lose the ability to signal that something serious happened. Freeze the runbook several days before the window, too. Late changes to an execution document are how the wrong version gets printed and carried into the command center.