The Cutover Plan Standard: Building a Plan That Can Actually Be Run

Two lines from a real cutover plan. Both were marked complete. Only one could be proven, staffed at two in the morning, or used to price a delay.

Most programs do not build a cutover plan. They inherit one. It arrives as a spreadsheet from the implementation partner around the start of test, a few hundred rows, dates in every cell, and it looks like a plan. Nine weeks later, at two in the morning, somebody reads row 214 aloud. It says "support conversion activities." The owner column says "Client."

That is a construction failure, and it happened months before the window opened. Here is how the artifact actually gets built.

1Three documents get called the cutover plan

They serve different readers and they fail differently. Collapsing them is how a program arrives at the window holding a calendar.

Published templates make the difference visible in the 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 strategy to planning to the cutover project plan to the simulation, describing the project plan as the mechanism used during the production cutover to signal when to start and initiate the next activity in sequence [R10].

2Diagnose the plan you were handed

Four failure patterns. Where the plan sits decides whether you edit it or rebuild it.

This is not theoretical. The artifact itself shows up as a named cause in public audit.

The budget increase and the delayed vendor payments come from a state audit office performance audit [R5]. The mispaid employees, and the auditor's conclusion that configuration testing was either not sufficiently scoped or not properly conducted, come from a state single audit [R6]. That same report notes the issue list with identification and resolution dates was not available when auditors asked for it, which it called a lack of organization expected of a project of that size. Validation lines are the audit trail.

3The anatomy of a cutover task

Twelve attributes on the line you just read. Set the schema before the first task is written, because retrofitting across two thousand lines is a project of its own.

Two published vendor column sets agree on the non-obvious two, a backup owner and a verification step per task [R1][R2]. Add a notes field for the bridge call and stop. Every extra column is maintained by somebody at two in the morning.

4Task names are the interface

They get read under pressure, filtered on, sorted, and quoted in status. Write them as instructions, not descriptions.

Ban support, assist, manage and coordinate as the leading verb. If the name contains "and," it is probably two tasks. And keep decisions as tasks: 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 is the most common missing line type in a partner-authored plan, and it is exactly where a window stalls. Not on the load. On the twenty minutes of waiting for somebody to say yes.

5Organization-level ownership is not ownership

This conversion is the highest-value work in a rebuild and the most tedious. Do it with the track lead in the room, line by line, across several sessions.

The last line is the one that gets skipped. A name written into a plan by someone else, on that person's behalf, is a proposal. It becomes ownership when you contact them and they say yes. That takes an afternoon, and it is the difference between a plan that holds and a plan that discovers three unstaffed lines during the rehearsal.

6Dependencies are the plan. Dates are an output.

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

There is a hard, auditable test here, and it comes from federal audit methodology rather than consulting opinion. Every activity should have at least one predecessor and at least one successor, with only two exceptions, the start and finish milestones, and any activity missing that logic must 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, and requires that constraints and lags be minimized and justified [R4]. Run that across your plan. The count of failing lines is your rebuild estimate.

7Anchors, float, and the delta view

Measure float, then defend it. If float cannot be stated as a number, the plan cannot answer the only question executives ask. Report it weekly and treat consumption as a risk event, not as normal variance. And build the delta view before you baseline: 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. Having the view ready makes it a one-hour conversation.

8Decomposition, and the growth nobody plans for

Six hundred lines and two thousand can both be correct. What matters is that the rule is stated on the plan and applied consistently, because an inconsistently decomposed plan cannot be reported on.

Plans do not grow because scope grew. They grow because the first draft was missing whole categories, and the order of discovery is consistent: integrations first, business tasks second, validation third, contingency last. Put that growth in the calendar rather than being surprised by it.

The business-task category is the one worth naming out loud, because partners do not 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]. That second category is what most technical plans leave out entirely.

Published freeze calendars show what those lines look like once dated and owned. One runs from two months before go-live to three months after, and carries entries like purchasing cards switched off for five days with a warning to renegotiate recurring vendor charges, and no new hire start dates permitted inside a two-week window [R7]. Another is structured 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 where change, operations and business sit alongside technical and data [R11].

9Where the plan lives

Decide before the plan passes a few hundred lines. Migrating mid-build costs a fortnight and loses history. The criterion is not features. It 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 car park is a tool you have not tested. And write down maintenance ownership separately from task ownership: the cutover lead owns the schema and cross-track dependencies, track leads own their own lines and durations, the sponsor owns the anchors and the baseline, the PMO owns version control.

10The baseline gate

A commitment, and re-baselining is expensive in credibility. Do not baseline until every box is ticked, and say so publicly rather than baselining a plan you already know is incomplete.

After baseline, adding or removing a task requires the track lead to propose it and the cutover lead to accept it, with a one-line reason recorded. That is what lets you tell the difference between a plan being improved and 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. And freeze the runbook several days before the window: late changes to an execution document are how the wrong version gets printed and carried into the command center.