ProcessImplementation

How to build a cutover plan that holds up on go-live weekend

A cutover plan is the timed script for moving a business from an old system to a new one, together with the rules for stopping and going back. This page covers how to pick a cutover strategy, build a runbook with owners and dependencies, rehearse until timings are measured rather than guessed, set go/no-go criteria with clear decision rights, and fix a point of no return before the weekend starts.

Reviewed 7 min read

On this page
  1. Big bang, phased, parallel run or pilot site: choosing the cutover strategy
  2. The cutover sequence from freeze to business sign-off
  3. Building the runbook and rehearsing it until the timings are real
  4. Data freeze, final migration and reconciliation checkpoints
  5. Go/no-go criteria and who makes the call
  6. Rollback: the point of no return and the triggers to go back
  7. Cutover communications by audience
  8. Running the cutover command center
  9. Hypothetical example: an ERP cutover over a long weekend
  10. Questions and answers
  11. Sources

Big bang, phased, parallel run or pilot site: choosing the cutover strategy

The strategy decides how long the outage lasts, how many temporary interfaces you build and how far a failure spreads, so settle it before writing the runbook.

CriterionBig bangPhasedParallel runPilot site
How it worksEvery user, site and process moves in one window.Modules, regions or business units move in waves.Old and new systems run side by side while outputs are compared.One site goes live first; the rest follow once it is stable.
Outage neededOne longer outage, often over a holiday weekend.Several shorter windows, one per wave.Little or none, but data is keyed or synchronized twice.A short window per site.
Main riskAn escaped defect hits the whole business at once.Temporary interfaces between old and new become a defect source.Fatigue, and disputes over which system is right.An unrepresentative pilot, so later waves meet new problems.
Fits best whenData is so tightly coupled that temporary interfaces would cost more than the outage.Modules or regions have clear boundaries and different readiness dates.Outputs can be compared mechanically, as with payroll or billing runs.Sites run similar processes and one can absorb early disruption.

Strategies combine: a phased program often runs each wave as a small big bang.

The cutover sequence from freeze to business sign-off

01Change and data freeze02Final extract and load03Reconciliation checkpoint04Technical smoke tests05Go/no-go decision06Open to users
  1. Change and data freeze

    Configuration, code and master data stop changing, so the rehearsed plan still applies.

  2. Final extract and load

    Open transactions and balances move using the rehearsed scripts.

  3. Reconciliation checkpoint

    Counts and control totals are compared before anyone uses the new system.

  4. Technical smoke tests

    Interfaces, batch jobs, printing and user access are checked end to end.

  5. Go/no-go decision

    The decision group compares evidence with criteria agreed in advance.

  6. Open to users

    Work starts under command-center supervision and hypercare begins.

Conceptual cutover flow. Real runbooks break each stage into many timed tasks, and the order of checks varies by system.

Building the runbook and rehearsing it until the timings are real

In ColdAI's implementation approach, cutover belongs to the stabilize and transition phase4, but the runbook is drafted much earlier because it needs several rehearsals.

  1. Inventory every task

    List each technical and business task from the start of the freeze to business sign-off, including stopping interfaces, backups, loads, routing changes, user access and tasks owned by suppliers.

    Output
    Task inventory
    Owner
    Cutover manager

  2. Assign owners, dependencies and durations

    Give every task one named owner, a backup, its predecessors and a duration. Mark the critical path, because that chain sets the length of the window.

    Output
    Draft runbook with critical path
    Owner
    Workstream leads

  3. Run the first mock cutover

    Execute the runbook against a copy of production data in a production-like environment and time each task. Expect missing steps, wrong sequencing and scripts that only worked on small files.

    Output
    Timed rehearsal log and defect list
    Owner
    Technical leads

  4. Fix, re-time and repeat

    Replace estimates with measured durations and rehearse again. The final rehearsal should use the real people, at the real times of day, against the latest production copy.

    Output
    Measured timings that fit the window
    Owner
    Program manager

  5. Add checkpoints and contingency

    Insert a reconciliation checkpoint after each major load and a buffer before the go/no-go call. If the measured plan does not fit the window, change scope or strategy now.

    Output
    Final runbook
    Owner
    Cutover manager

  6. Put the runbook under change control

    After the last rehearsal, every edit needs the cutover manager's approval and a note of the risk it adds. Untested late edits cause many surprises on the night.

    Output
    Approved runbook version
    Owner
    Steering group

Data freeze, final migration and reconciliation checkpoints

Freezes come in layers. Master data such as customers, products and the chart of accounts usually freezes days before the window, with a controlled route for urgent changes keyed into both systems. Transactions freeze when the window opens. Decide what the business does during the outage, because every paper form or queued email order must be keyed into the new system afterwards by a named owner.

The final migration runs the same scripts, in the same order, as the last rehearsal. After each major load a business owner signs a comparison of record counts and control totals before the next load starts, classing any break as explained, tolerable or blocking. The method is set out in data migration validation.

Go/no-go criteria and who makes the call

Write each criterion as a check with named evidence. The decision group is usually the business sponsor, program manager, technical lead and future operations owner, with one person holding the final vote.

  • If

    A blocking reconciliation break appears and nobody can explain it yet.

    Then

    Call no-go, or investigate within the contingency buffer.

    Opening on unexplained data turns a delay into a data-quality incident.

  • If

    Every criterion passes apart from known defects with agreed workarounds.

    Then

    Call go, and brief the workarounds to super-users before anyone logs in.

    Criteria should demand that open defects are understood and owned, not that there are none.

  • If

    The runbook is late but every completed checkpoint has passed.

    Then

    Spend the buffer, and call no-go only if the critical path would reach the point of no return too late.

    Lateness is a scheduling problem; failed checks are a quality problem.

  • If

    A critical-path supplier or infrastructure dependency is unconfirmed.

    Then

    Treat it as no-go until it is confirmed in writing.

    Users cannot work around a missing bank file or carrier interface.

Rollback: the point of no return and the triggers to go back

Cutover communications by audience

0 of 5 checked

Running the cutover command center

The command center is a room or an open call where the cutover is run against the clock. The cutover manager owns the timeline, workstream leads report status in a fixed format, a technical bridge keeps engineers and suppliers on one line, and a scribe keeps the decision log. Any task that overruns its buffer is escalated at once, not at the next scheduled call. Once users are working, the same structure shifts into hypercare.

Hypothetical example: an ERP cutover over a long weekend

Questions and answers

How far ahead should cutover planning start?

Start the runbook once the target architecture and migration approach are known, usually during the foundation phase. Rehearsals need production-like environments, migrated data and people's time, and each one changes the plan. Starting late leaves no room for the repeat rehearsals that turn estimates into measured timings.

How many mock cutovers are enough?

Keep rehearsing until a full run completes inside the window with contingency to spare, using the real team at the real times of day. Significant go-lives usually need at least two complete rehearsals. If the latest one still produced new defects or overran, schedule another rather than going live on hope.

Can a cutover be done without any downtime?

Sometimes. Parallel running, change data capture that keeps the new system in sync, and blue-green releases can shrink the outage to a routing switch. The price is complexity: synchronization logic, reconciling two live systems and harder rollback decisions. For tightly coupled systems such as ERP, a short planned outage is often the safer trade.

What separates a cutover plan from a deployment plan?

A deployment plan releases software into an environment. A cutover plan moves the business: freezing activity, migrating live data, switching interfaces and partners, communicating with users, deciding go or no-go and keeping a way back. A deployment is usually one task inside the cutover runbook.

Sources

  1. Custom Software Development: delivery stages and production release — ColdAI
  2. PS21/3: Building operational resilience — Financial Conduct Authority · checked 10 October 2026
  3. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA) — EUR-Lex · checked 10 October 2026
  4. Implementation: approach and offerings — ColdAI

More in Implementation

Back to Implementation

Next step

Send us your go-live date and the cutover plan as it stands

Share the systems involved, the window you have and your current runbook. We will point out where rehearsal data, go/no-go criteria or rollback look thin, and say whether you need help running the weekend.

Review my cutover plan