Cutover Plan: Template, Runbook Columns and a Go-Live Weekend Example

9 min read ยท 2026-10-25

A cutover plan is the detailed, time-sequenced set of tasks that moves a business from an old system to a new one: freezing the old system, migrating and checking data, switching integrations and users over, and confirming the business can run, with a rollback path if something fails. It covers the last weeks before go-live, the cutover window itself and the first days after.

The template below covers ten weeks in six phases, from cutover strategy to hypercare. It fits ERP, CRM, finance, data platform and infrastructure go-lives. It is written for the people who run them: the cutover manager, the project manager or PMO lead, workstream leads and the IT operations team. You also get the runbook columns to use, an hour-by-hour weekend example, go/no-go criteria, rollback rules and how to present the plan to the steering committee.

The roadmap at a glance

Goal: The new system is live, business users have completed their first real transactions, data is reconciled and signed off, and the legacy system is read-only, with no rollback needed. Duration: 10 weeks

  1. Cutover strategy (Weeks 1-2)

    Decide how and when you will switch, and what the business can tolerate.

    • Choose the approach: big bang, phased by site or module, or parallel run for a set period.
    • Pick the cutover window with the business, avoiding month-end close, payroll runs and peak sales days.
    • Agree on the maximum downtime the business accepts and the latest point at which rollback is still possible.
    • List every system, interface, data object and team involved.

    Milestone: Cutover strategy document signed off by the business sponsor, with the window, allowed downtime and point of no return agreed.

  2. Build the runbook (Weeks 2-4)

    Write every cutover task in order, with an owner, a duration and a dependency.

    • Collect tasks from each workstream: data migration, integrations, infrastructure, security, configuration, business activities.
    • Sequence tasks with dependencies and planned start and end times.
    • Add check tasks after every major step, such as record counts and reconciliation reports.
    • Write the rollback plan: trigger, steps, owner and time needed.
    • Write the communication plan: who is told what, when and through which channel.

    Milestone: Runbook version 1 reviewed by every workstream lead, with each task assigned to a named person and a backup.

  3. Rehearsals (Weeks 4-8)

    Run the cutover end to end in a test environment until timings and steps are reliable.

    • Run the first mock cutover with production-like data volumes.
    • Time every task and compare actual against planned durations.
    • Log every issue with an owner and fix it before the next rehearsal.
    • Run a second mock cutover, plus a rollback rehearsal if the risk justifies it.
    • Update the runbook after each rehearsal and keep version numbers.

    Milestone: Final rehearsal completed inside the agreed window with all checks passed and no open critical issues.

  4. Readiness and go/no-go (Week 9)

    Confirm that the business, the data and the people are ready.

    • Freeze changes on the old and new systems.
    • Confirm user training, access and roles are complete for go-live users.
    • Run final data cleanup and pre-load static data such as master data.
    • Hold the go/no-go meeting with the steering committee against written criteria.

    Milestone: A recorded go decision from the steering committee, with every criterion marked met or accepted as a known risk.

  5. Cutover window (Week 10 (weekend))

    Execute the runbook and switch the business to the new system.

    • Open the command center with a bridge call and a shared status tracker.
    • Freeze the legacy system and take final backups.
    • Run data migration, reconciliation and integration switchover in runbook order.
    • Hold checkpoint calls at planned times and before the point of no return.
    • Run smoke tests with key users, then confirm go-live.

    Milestone: Business sign-off on smoke tests and data reconciliation, and the go-live announcement sent.

  6. Hypercare (Week 10 onward (2-4 weeks))

    Support users closely until the new system runs as normal operations.

    • Staff a hypercare team with daily triage of incidents.
    • Track first transactions, such as orders, invoices and payments, end to end.
    • Hold a daily stand-up with workstream leads and publish a short status note.
    • Agree exit criteria and hand over to the support team.

    Milestone: Hypercare exit criteria met, open issues handed to support with owners, and the legacy system set to read-only or archived.

Cutover plan vs deployment plan vs migration plan

These terms overlap, and teams mix them up. A deployment plan covers releasing software to an environment. A data migration plan covers extracting, transforming, loading and checking data. A cutover plan sits above both. It sequences everything that must happen to switch the business over, including technical steps, business steps such as stopping order entry, and communications.

Think of the cutover plan as the master schedule for the final stretch. It pulls in tasks from the deployment and migration plans and adds the business side, the decision points and the rollback. One cutover manager owns it, even when ten teams contribute to it.

What goes in the cutover runbook

The runbook is the working document of the cutover plan. During the window, everyone follows it line by line, so it must be precise. Each row is one task that one person can complete and check.

Use the same columns in every rehearsal and in the real cutover, so you can compare timings. A common starting point is the list below.

  • ID and phase: a task number and the stage it belongs to, such as pre-cutover, freeze, migration, validation, go-live.
  • Task: a short action starting with a verb, such as Export open purchase orders from legacy ERP.
  • Owner and backup: named people, not teams, with phone numbers in the contact sheet.
  • Dependency: the task IDs that must finish first.
  • Planned start, duration and planned end: in the local time of the command center.
  • Actual start and actual end: filled in live during rehearsals and the cutover.
  • Status: not started, in progress, done, blocked or skipped.
  • Check and evidence: how completion is confirmed, such as a record count or a screenshot.
  • Rollback step: what to undo if the plan is reversed at this point.

Example: an ERP cutover weekend

Picture a manufacturer moving finance, purchasing and sales orders to a new ERP. The business agreed to stop transactions from Friday evening until Monday morning, and the point of no return is set for Sunday at noon.

Each block has an owner and a checkpoint. If a checkpoint fails and cannot be fixed in the planned buffer, the cutover manager calls the steering committee to decide on rollback.

  • Friday 18:00, freeze: order entry stops, legacy ERP set to read-only, final backups taken. Owner: IT operations lead. Check: backup confirmation and no new transactions logged.
  • Friday 20:00 to Saturday 14:00, data migration: open orders, open invoices, stock balances and customer and supplier data loaded. Owner: data migration lead. Check: record counts match the extraction reports.
  • Saturday 14:00 to 22:00, reconciliation: finance reconciles trial balance, open AP and AR; supply chain checks stock by warehouse. Owners: finance controller and supply chain lead. Check: signed reconciliation sheets.
  • Sunday 08:00 to 12:00, integrations and smoke tests: bank, EDI and warehouse interfaces switched; key users enter test orders and post a test invoice. Owner: integration lead. Check: test transactions flow end to end.
  • Sunday 12:00, point of no return checkpoint: steering committee confirms go. Owner: cutover manager.
  • Monday 07:00, go-live: users log in, hypercare desk opens, first status note goes out at 10:00. Owner: hypercare lead.

Who owns what

The cutover window is not the moment to discover who makes decisions. Write the roles down in the runbook header and brief everyone at the last rehearsal.

Plan shifts if the window runs past 12 hours. Tired people make mistakes, and the backup owner column only helps if backups are awake and briefed.

  • Cutover manager: owns the runbook, runs the command center and the checkpoint calls.
  • Business sponsor: makes the go/no-go and rollback decisions with the steering committee.
  • Workstream leads (data, integration, infrastructure, security): run their tasks and report status at each checkpoint.
  • Business process owners: run business checks and sign off reconciliation and smoke tests.
  • Key users: test real transactions during the window and support colleagues on day one.
  • Communications lead: sends freeze notices, go-live news and status updates.
  • Hypercare lead: runs incident triage after go-live and decides when to exit hypercare.

Go/no-go criteria and rollback

Write the go/no-go criteria before the last rehearsal, not on the day. Each criterion should be a yes or no question someone can answer with evidence. If a criterion is not met, the steering committee either delays or accepts the risk on record.

For rollback, define the trigger, the latest time it can start and how long it takes. Rehearse it if the system is critical. After the point of no return, the plan shifts from rollback to fix forward, so the business must know where that line is.

  • Final rehearsal completed inside the window with all checks passed.
  • No open critical defects, and high defects have workarounds that users know.
  • Data reconciliation rules agreed and signed by finance and process owners.
  • Go-live users trained, with access and roles tested.
  • Support, hypercare rota and contact sheet confirmed.
  • Rollback plan written, owned and timed.

How to build the runbook in Excel or Smartsheet

In Excel, put the columns above in row 1, select the range and use Home, then Format as Table, so filters and banded rows come for free. Add a dropdown for the Status column with Data, then Data Validation, using a list of the allowed values. Use Home, then Conditional Formatting, to color blocked tasks red and done tasks green. Freeze the header row with View, then Freeze Panes, so the columns stay visible while you scroll.

Add a second sheet for contacts with names, roles, shifts and phone numbers, and a third for the issue log. In Smartsheet, use a project sheet so dependencies and the Gantt view are built in, and share it with workstream leads so they update status live. In either tool, save a copy per rehearsal so you can compare planned and actual times.

How to present it to the steering committee

Use one slide with a timeline of the cutover window, the checkpoints marked, the point of no return in bold and the downtime the business will see. Below it, list the go/no-go criteria with their current status and the top three risks with owners.

Leave the runbook rows out of the slide. The committee needs to know when the business stops, when it restarts, what decisions they must make and when, and what happens if things go wrong. After each rehearsal, update the slide with actual timings so the committee sees whether the window is realistic.

Common mistakes to avoid

  • Writing the runbook at team level means nobody acts when a task stalls, so assign every task to a named person with a backup.
  • Skipping rehearsals hides timing problems until the real weekend, so run at least two full mock cutovers with production-like data volumes.
  • Choosing a window during month-end or a peak sales week adds business pressure, so agree the window with finance and operations first.
  • Defining go/no-go criteria on the day turns the meeting into a debate, so write and agree them before the final rehearsal.
  • Leaving rollback vague makes it impossible to use, so set its trigger, its latest start time and its owner, and rehearse it for critical systems.
  • Ending support at go-live leaves users stranded, so plan hypercare with a staffed desk, daily triage and clear exit criteria.

Frequently asked questions

What is a cutover plan?

It is the detailed schedule of tasks that switches a business from an old system to a new one. It covers the freeze, data migration, checks, integration switchover, go-live and the first days of support. It also defines decision points and a rollback path.

What should a cutover plan include?

It should include the cutover strategy, a runbook with owners, timings and dependencies, rehearsal results, go/no-go criteria, a rollback plan, a communication plan, a contact sheet and a hypercare plan. Each task should have a way to confirm it is done.

How many mock cutovers should you run?

Many teams run at least two full rehearsals, and more for complex ERP or finance go-lives. Keep rehearsing until the run fits inside the agreed window and all checks pass. Use production-like data volumes so the timings are realistic.

What is the point of no return in a cutover?

It is the latest moment at which you can still roll back to the old system within the allowed downtime. After it, you fix problems forward in the new system. Set it in the strategy phase and hold a checkpoint call just before it.

What is hypercare after go-live?

Hypercare is a period of extra support right after go-live, often a few weeks. A dedicated team triages incidents daily and tracks the first real transactions. It ends when agreed exit criteria are met and normal support takes over.

Generate this roadmap with AI