How to create an ERP cutover plan
How to create an ERP cutover plan for SAP, Oracle, Dynamics 365 or NetSuite go-lives: rehearsals, the legacy freeze, data load and reconciliation, go/no-go criteria, rollback and hypercare exit.
An ERP cutover plan is the runbook for the weekend the business moves from the old system to the new one: what stops, what is loaded, who signs, and what happens if it goes wrong.
The short version
- Rehearse the cutover at least once with production-like data and time it.
- Freeze the legacy system before final extraction, and say what is frozen.
- Load master data before open transactions, then reconcile both.
- Agree go/no-go criteria and the rollback plan in advance.
- End hypercare on exit criteria, not on a date.
Plan the gates, not just the tasks
A cutover plan usually starts as a task list, and the detailed list matters: several hundred tasks with owners, durations and dependencies. But a go-live rarely fails because a task was missing. It fails because a gate was unclear: nobody agreed what 'reconciled' meant, the go/no-go criteria were decided on the night, or the rollback plan existed only as a sentence in a slide.
So plan the gates first. Draw the cutover as a process flow with the decision points in it: rehearsal targets met, reconciliation signed, go or no-go, hypercare exit. Agree the criteria for each with the steering committee weeks before go-live. Then build the detailed task list underneath each phase.
The example below is a generic ERP cutover that works for SAP S/4HANA, Oracle Fusion, Dynamics 365 or NetSuite. It shows the gates and the paths that run when a gate fails.
ERP cutover with its gates
From a baselined runbook to handover. Watch the four decisions: rehearsal, reconciliation, go/no-go and hypercare exit.
Rehearse until it fits the window
The mock cutover runs the real runbook against a copy of production and is timed. If it misses the timing or defect targets, the runbook is fixed and the rehearsal runs again. Two or three rehearsals are normal for a large go-live.
Freeze, extract and load
Business transactions and master data changes stop in the legacy system, final balances and open items are extracted, master data is loaded before transactions, and the technical team switches interfaces, batch jobs and authorizations.
Reconcile and sign
The business, not the data team, reconciles record counts and balances against legacy and signs. Breaks go back to the data team for correction and reload. This signature is the most important gate in the plan.
Go or no-go
The steering committee decides against criteria agreed in advance. No-go triggers the rollback plan and a new date, which is a planned outcome, not a failure of the project.
Open the system and run hypercare
Users start work, the support team triages tickets daily, and hypercare ends when the exit criteria are met, usually including the first month-end close in the new system.
How it works
Draw the gates first
Start with a process flow of the cutover phases and the decisions between them: rehearsal targets, reconciliation sign-off, go/no-go and hypercare exit. Agree it with the steering committee before writing tasks.
Write the detailed runbook
Under each phase, list every task with an owner, predecessor, planned start, duration and the person who confirms it is complete. Include business tasks such as stock counts and final invoicing, not only technical ones.
Define what is frozen and when
Write down which transactions and master data stop in the legacy system, from what time, and what the business does in the meantime, such as manual orders or shipping on paper.
Plan the data load and reconciliation
Sequence the load (master data, then open items and balances), define the reconciliation reports for each object, and name the business owner who signs each one.
Agree go/no-go criteria and the rollback plan
Write measurable criteria and the latest point at which rollback is still possible. Rehearse the rollback steps as well as the cutover.
Rehearse and refine
Run at least one full mock cutover with production-like data, time every task, and update the plan. Repeat until the cutover fits the window with margin.
Mistakes to avoid
Criteria decided on the night
If go/no-go criteria are not agreed in advance, the decision becomes a negotiation under pressure. Agree them weeks before.
Technical-only plan
Cutover plans written by IT miss business tasks such as final stock counts, open purchase orders and customer communication. Each business area needs its own tasks in the runbook.
No rehearsal
A cutover that has never been timed will not fit the window. The first rehearsal almost always runs long.
Rollback as an afterthought
A rollback plan that has never been tested is not a plan. Know the point of no return and rehearse the steps before it.
Open the ERP cutover flow
Open the cutover flow as your own chart, write your go/no-go criteria on the decision, and send it to the steering committee for approval.
Related guides
Frequently asked questions
What is included in an ERP cutover plan?
The timed list of tasks to move from the legacy system to the new ERP, with owners and dependencies; the legacy freeze; data extraction, load and reconciliation; technical switch-over of interfaces and jobs; business tasks such as stock counts; go/no-go criteria; the rollback plan; communication; and hypercare arrangements.
How long does an ERP cutover take?
The cutover window itself is usually a weekend to a week, depending on data volumes and how many sites go live at once. Planning and rehearsing it takes several months, starting during the build phase.
What are typical go/no-go criteria?
Data reconciliation signed off by the business, no open severity-1 defects, an agreed list of known lower-severity issues, users trained, support and hypercare staffed, interfaces tested end to end, and confirmation that rollback is still possible.
What is hypercare after go-live?
A period of intensive support right after go-live, usually four to eight weeks, with daily ticket triage, the project team on hand, and fast fixes. It ends when agreed exit criteria are met and support moves to the normal business-as-usual team.