Cutover Plan Example: A Timed Sequence for an ERP Go-Live Weekend
A cutover plan sets out the timed sequence that takes a system from frozen to live. The example below covers a fictional ERP go-live weekend in twenty steps, each with a start time, duration, owner, the step it depends on, the check that proves it worked, and whether rollback is still available.
The example
This is the cutover sequence for a fictional ERP go-live at a three-site manufacturer: legacy system frozen on Friday evening, data migrated overnight, verification through Saturday and Sunday, users in on Monday morning. Twenty steps is the summary level - the plan you present and the one the command centre works from. The full runbook underneath it runs to several hundred lines, which is the difference described in cutover plan versus cutover runbook.
| Step | Start | Duration | Task | Owner | Depends on | Verification / exit check | Rollback still available |
|---|---|---|---|---|---|---|---|
| 1 | Fri 17:00 | 30 min | Go/no-go decision confirmed and minuted; cutover formally authorised | Programme director | - | Decision recorded and circulated to all cutover staff | Yes - nothing has changed |
| 2 | Fri 17:30 | 15 min | Business freeze begins: order entry, goods receipt and invoicing closed in the legacy system | Comms lead | 1 | Freeze notice sent; site managers acknowledge by return | Yes |
| 3 | Fri 18:00 | 45 min | Final legacy batch run - invoicing, stock movements, GL posting | Legacy application owner | 2 | Batch log shows zero failed jobs; period totals printed and retained | Yes |
| 4 | Fri 18:45 | 30 min | Legacy system set to read-only; user accounts disabled except the migration service account | Infrastructure lead | 3 | Two named users confirm they cannot post | Yes |
| 5 | Fri 19:15 | 60 min | Full backup of the legacy database and document store; restore verified in the standby environment | Infrastructure lead | 4 | Restore test completes and the standby instance opens | Yes - this is the rollback anchor |
| 6 | Fri 20:15 | 15 min | Checkpoint call 1: proceed to extract? | Cutover manager | 5 | Named attendees present; decision logged | Yes |
| 7 | Fri 20:30 | 3 hr | Master data extract and load: customers, suppliers, materials, BOMs, pricing | Data lead | 6 | Row counts match the extract manifest to the record | Yes |
| 8 | Fri 23:30 | 4 hr 30 | Transactional load: GL balances, open purchase orders, open sales orders, stock on hand | Data lead | 7 | Load log shows zero rejected records; rejects file is empty | Yes |
| 9 | Sat 04:00 | 2 hr | Reconciliation pack: trial balance, stock valuation, open order count and value, AR and AP ageing | Finance data analyst | 8 | Trial balance exact; stock valuation within 0.1%; open order counts exact | Yes |
| 10 | Sat 06:00 | 45 min | Checkpoint call 2: reconciliation reviewed and signed by the finance and supply chain data owners | Cutover manager | 9 | Signed reconciliation sheet; go/no-go on enabling interfaces | Last point at which rollback is straightforward |
| 11 | Sat 06:45 | 2 hr | Interfaces enabled in sequence: banking, payroll, warehouse, EDI to the logistics provider | Integration lead | 10 | Each interface reports a successful handshake before the next is enabled | No - point of no return once the banking interface posts |
| 12 | Sat 08:45 | 3 hr | Interface smoke tests: two transactions end to end per interface, including one deliberate failure | Integration lead | 11 | Both success and failure paths produce the expected result and alert | No |
| 13 | Sat 12:00 | 4 hr | Business verification part 1 - finance: post a journal, run a payment proposal, check period-end controls | Finance workstream lead | 12 | 28 of 28 scripted steps pass or are logged as defects with a severity | No |
| 14 | Sat 16:00 | 4 hr | Business verification part 2 - supply chain: receive a PO, pick, despatch, invoice, credit | Supply chain lead | 12 | 31 of 31 scripted steps pass or are logged | No |
| 15 | Sun 08:00 | 2 hr | Business verification part 3 - HR and payroll: parallel payslip comparison for 25 employees across all pay types | HR workstream lead | 12 | Gross and net match the legacy parallel run for every employee tested | No |
| 16 | Sun 10:00 | 1 hr | Defect triage: severity assigned, fix or waive decided, waivers recorded with an owner and a date | Cutover manager and workstream leads | 13, 14, 15 | No severity 1 open; every severity 2 has a fix or a signed waiver | No |
| 17 | Sun 12:00 | 30 min | Checkpoint call 3: go/no-go on opening the system to users | Programme director | 16 | Decision minuted with the names of those present | No |
| 18 | Sun 13:00 | 2 hr | User access enabled site by site; super users run a five-step smoke check at each site | Service transition lead | 17 | All three sites report a completed smoke check | No |
| 19 | Sun 15:00 | 1 hr | Go-live confirmed to all staff; hypercare desk and command centre open | Comms lead | 18 | Message sent; hypercare number tested by a call from each site | No |
| 20 | Mon 06:00 | - | First business day: floorwalkers on site, command centre call at 08:00, 12:00 and 16:00 | Hypercare lead | 19 | Command centre log opened; first order of the day processed and confirmed | No |
Reading the example
- Step - a sequential number used on the call. During the weekend nobody says "the transactional load"; they say "we are on step 8, running twenty minutes behind". Numbering that survives the weekend matters more than numbering that is elegant.
- Start - a clock time with a day, in one stated timezone. Cutovers with teams in more than one country either state the timezone in every row or lose an hour somewhere around step 8.
- Duration - the expected elapsed time, taken from the last dry run rather than from an estimate. A duration nobody has ever measured is the most common reason a cutover overruns its window.
- Task - what happens, in enough detail that the person doing it recognises their job, and no more. Detail below that level belongs in the technical runbook the step points to.
- Owner - one named role per step. Two owners means the step stalls while each waits for the other. The rota behind this column matters too: step 8 finishes at 04:00 and step 13 starts at 12:00, and they should not be the same person.
- Depends on - the step that must finish first. This is what turns a list into a plan: when step 7 runs late, the dependency column shows immediately what moves and what does not.
- Verification / exit check - the evidence that the step actually worked. "Load completed" is not a check; "zero rejected records and an empty rejects file" is. Steps without a verification are the ones that get declared done at three in the morning and unpicked on Tuesday.
- Rollback still available - whether the weekend can still be abandoned at this point. It changes at step 11 here, when the banking interface starts posting outward. Marking that line in the plan is more useful than any amount of prose about contingency; see the rollback plan guide for what sits behind it.
Why the checkpoints sit where they do
The three checkpoint calls are not spaced evenly. Each one sits immediately before something expensive or irreversible: before the data load starts, before the interfaces are enabled, and before users are let in. That is the only defensible reason to hold a call at four in the morning - a decision is being made. Checkpoints scheduled every two hours "to keep everyone informed" get skipped by Saturday lunchtime.
Checkpoint 2 carries the most weight in this plan. It is where the reconciliation is signed by named business owners rather than reviewed by the project team, and it is the last point at which stopping is a matter of restoring a backup rather than unwinding transactions that have already left the organisation. The criteria applied at that call are the same ones written down before the weekend on the go/no-go checklist.
What the timings assume
Every duration here comes from dry run 3, which ran the same sequence against a full-volume copy. That is why the load steps carry uneven numbers - three hours for master data, four and a half for transactions - rather than tidy round ones. Rounded durations usually mean nobody has timed the step.
The plan also holds slack that is not shown as a row. Between the end of verification on Sunday morning and the go/no-go at 12:00 there is deliberate space; between opening the system and Monday morning there is a night. Slack placed at the end of a cutover is worth little, because by then the decision has been made. Slack placed before an irreversible step is what gives you the option to fix something and continue.
What this example leaves out
A cutover plan that fits on one page is a summary of a much larger document. What is missing here:
- The task-level runbook. Step 8 is one row here and roughly ninety lines in the real runbook, each with a script name, a server, a command and an expected output. The summary is for the call; the detail is for the person executing.
- Contacts and escalation. A real plan carries a contact sheet with mobile numbers, the vendor's out-of-hours line, the escalation path at each hour of the weekend, and who is authorised to wake whom.
- The rollback sequence itself. This table records where rollback stops being available; it does not contain the reverse steps, their timings, or the person who can call it. That is a separate document, tested before the weekend rather than written during it.
- Comms. Draft messages for go, no-go and delay - to staff, to customers, to the logistics provider - written and approved in advance, because nobody writes a good customer message at 05:00.
- The freeze detail. One row here covers a change freeze that in practice starts days earlier and has its own list of what is frozen, what is exempt and who approves an exception.
- What happens after Monday. Hypercare is one line at step 20. The period it opens has its own rota, triage rules and exit criteria, a separate matter from the cutover itself.
The working version of this plan, with the dependency logic, timeline view and the hypercare tabs attached, is the cutover runbook and hypercare pack. The narrative sections that sit around the sequence - approach, freeze, comms, verification - are set out in the cutover plan guide.
Questions
How detailed should a cutover plan be?
Detailed enough that the command centre can run the weekend from it, which usually means a summary sequence of twenty to forty steps pointing at a task-level runbook underneath. One document trying to do both jobs is either unreadable on the call or too thin to execute.
Where do the durations come from?
From a dry run at full volume, not from estimates. Durations nobody has measured are the usual reason a cutover overruns its window, because the data load is the step that behaves differently at production volumes.
What is the point of no return?
The step after which abandoning the cutover costs more than continuing - normally when data or transactions leave the organisation, such as the first outbound banking or EDI message. Marking it in the plan tells everyone when a stop decision is still cheap.
Who signs off during the weekend?
Named business owners, not the project team. In the example the reconciliation is signed by the finance and supply chain data owners, and the decision to open the system to users is taken by the programme director and minuted.