What is a cutover plan?

What should a cutover plan contain?

A cutover plan is the detailed, time-sequenced plan used to coordinate the activities required to transition a business, system or service from its current state to a new operational state.

Unlike a high-level project schedule, it describes the operational sequence of the transition itself. Field names differ between organisations, but each activity should be understandable and governable.

• Unique reference and unambiguous activity name
• Workstream, phase and accountable owner
• Planned start, finish and duration
• Predecessors and successor implications
• Completion criteria, evidence and checklist
• Executor, validator or approver where required
• Contingency information and decision deadline

A simple cutover plan example

The example is illustrative, not a prescribed sequence. A real plan must reflect the programme landscape and controls.

How detailed should a cutover plan be?

The plan must be detailed enough for a competent owner to execute without inventing the sequence during go-live, but not so fragmented that status becomes noise. Risk, handoffs, duration and the need for separate evidence should determine granularity.

A task lasting several hours with different owners and decision points is usually too broad. A technical instruction already governed in a specialist procedure may be referenced rather than copied line by line.

Parent activities and executable steps

Hierarchy helps teams organise thousands of activities without pretending every summary row can be executed. Parent activities provide scope and roll-up. Leaf activities carry owners, dependencies, completion criteria and runtime status.

Roll-up rules should be transparent so management progress does not hide an incomplete critical child activity.

Dependencies are the backbone of the plan

Dates show intention; dependencies show the operational logic. A predecessor relationship states what must be complete before another activity may start. Cross-workstream dependencies deserve particular attention because ownership and communication boundaries increase the chance of delay.

Critical chains should be reviewed for unrealistic overlap, hidden waiting time and missing validation.

Milestones and governance fields

Milestones represent significant checkpoints such as legacy freeze, migration complete, business validation complete, go/no-go and production release. They should represent a real state, not merely a reporting date.

Governance fields define how completion is accepted. Confirmation-only work can be completed by its assigned executor. Activities that require independent validation need a validator; approval or approval-rationale activities need an approver. Controls should match the activity rather than being added indiscriminately.

Planning status and runtime truth

The approved plan is a baseline. Live execution records when predecessors actually completed, when work started, what evidence was submitted and when acceptance occurred. Overwriting planned values with actual values destroys the comparison needed for forecasting and learning.

Preserve both baseline and actual execution so teams can understand variance without rewriting history.

Cutover plan quality checklist

Review the plan before it is promoted into rehearsal or live execution.

• Scope and exclusions are explicit
• Every executable activity has one owner
• Critical dependencies are modelled, not described in notes
• Milestones represent verifiable states
• Completion criteria are observable
• Validation and approval match risk
• Contingency and decision points are known
• Workstream plans form one integrated sequence
• Baseline changes are controlled
• Management reporting can be derived from the same plan

Turn the plan into controlled execution

CutoverCenter connects planning, version governance, rehearsals and live execution while retaining governed Excel import and export where teams need it.