An ERP cutover plan should identify when each system stops accepting work, how final data is reconciled, who authorises the switch and what happens if acceptance fails. Rollback needs a business reconciliation plan as well as a technical restore. Once users or external systems act on new transactions, restoring a database alone may leave real commitments unexplained.
Let’s plan your ERP cutover.
Bring your workflow and the decisions you need to make. We’ll help you define the requirements, examine the trade-offs and plan a practical next step.
Define the authority change
List each workflow's authoritative system before, during and after cutover. A single switch or staged transition both need explicit treatment of open orders, pending receipts, unallocated payments and transactions in transit.
Name a coordinator and decision owners for operations, finance, data and technical recovery. “The project team will decide” is insufficient when a deadline arrives and several checks disagree.
Build a runbook with evidence gates
| Step | Responsible owner | Evidence before continuing |
|---|---|---|
| Restrict legacy changes | Operations lead | Agreed workflows stopped |
| Capture final boundary | Data owner | Snapshot and included population |
| Load final changes | Migration lead | Counts, rejects and mapping report |
| Reconcile opening position | Operations and finance | Approved differences and totals |
| Verify interfaces | Integration owner | Accepted records and recovery test |
| Authorise live work | Business sponsor | Recorded go/no-go decision |
| Observe initial transactions | Support lead | Complete outcomes and exception ownership |
Your runbook also needs system-specific commands, timing, contacts and business checks prepared by the responsible team.
Specify rollback triggers before the window
Examples include unresolved opening-balance differences, failed critical authorisation or inability to complete a required transaction. Agree consequences and decision authority for each trigger.
Avoid promising rollback until any point without defining treatment of work already performed. Set the decision point around transaction boundaries. Later recovery may require forward corrections, controlled re-entry or reconciliation rather than returning a database to its earlier state.
A backup proves a copy exists. A recovery rehearsal tests whether the team can restore the required state and explain the resulting business position. Record what the rehearsal did and did not test.
Walk through an illustrative failure
Suppose the ERP creates a dispatch and sends a delivery instruction, but accounting rejects its invoice request. Restoring yesterday's database does not recall the vehicle or erase the customer's order.
Identify the dispatch, rejected request and external acknowledgements. Decide whether to pause dispatch, repair posting or follow another approved recovery route. Preserve evidence to prevent duplicate work after recovery. This illustrates a boundary problem; it is not a customer incident or a prescribed financial correction.
Organise the first operating period
Provide a visible exception queue and staffed support matching live workflows. Set review points for stock, posting, integrations and access. Tell users what to do with a pending transaction rather than repeatedly resubmitting it.
Track deviations from the runbook and investigate causes before reusing the approach at another site.
Questions implementation teams ask
Can the old system stay editable for safety?
Only with controlled authority and reconciliation. Unrestricted editing in both systems can make recovery harder because neither holds the complete authoritative history.
Does a test migration prove cutover readiness?
No. Final transaction timing, interfaces, access, staffing and open-work handling need evidence too.
Prepare the readiness meeting
Bring the runbook, triggers, rehearsal result and unresolved exceptions. Use the ERP data migration checklist and review ERP migration services against the complete operating transition.
