An ERP go-live is the controlled switch from the old system to the new one. It runs in four stages: confirm readiness against agreed criteria and make a go or no-go decision; freeze the old system and execute a rehearsed cut-over plan; support users through a hypercare period; and complete the first month-end close in the new ERP. Go-live is finished only when that close is done.
Many teams treat go-live as a date. In practice it is a short project of its own, with a run book, named owners and a fallback. This checklist is vendor-agnostic and applies to packaged suites and to custom ERP software. It assumes user acceptance testing is complete; if not, start with our ERP UAT testing plan.
When is an ERP ready to go live?
An ERP is ready when agreed criteria are met, not when the calendar says so. Set the criteria early in the project, so the go or no-go meeting is a check against a list rather than a debate.
Readiness criteria
| Area | Criterion | Evidence |
|---|---|---|
| Testing | UAT signed off by each process owner; no open critical defects | Sign-off record, defect log |
| Data | Final trial migration reconciled; cut-over timings measured | Reconciliation pack, rehearsal log |
| People | Role-based training complete; champions in place | Training records, champion list |
| Access | User accounts and roles created and checked; segregation of duties reviewed | Access matrix sign-off |
| Integrations | Connections to banks, e-commerce, payroll or other systems tested and switched over in the plan | Integration test results |
| Support | Hypercare team, hours and issue route confirmed | Support rota |
| Business | Key dates avoided: peak trading, payroll run, audit fieldwork, statutory filing deadlines | Calendar check |
| Fallback | Rollback plan written and understood | Rollback section of run book |
How do you plan the ERP cut-over?
Cut-over is the timed sequence of steps that moves the business from the old system to the new one. Write it as a run book: every task, its order, owner, planned start, duration, and the check that proves it is done. Rehearse it at least once in full.
Choosing the cut-over date
Go live at the start of an accounting period, ideally a month start, so opening balances equal the closing balances of the last period in the old system. Avoid periods with peak trading or a financial year-end close in the old system that depends on the same people. Our ERP data migration plan explains why a mid-period cut-over makes reporting much harder.
The data freeze
A freeze stops changes in the old system so the final extract is stable. There are usually two:
- Master data freeze, a few days before cut-over: no new customers, suppliers or items in the old system without a controlled process to add them to both.
- Transaction freeze, for the cut-over window itself: no orders, receipts, invoices or payments in the old system after a set time.
Agree how urgent business is handled during the freeze, for example manual order forms entered into the new ERP after go-live, and who approves exceptions.
Sample cut-over run book
| Step | Task | Owner | Check |
|---|---|---|---|
| 1 | Announce freeze; stop transaction entry in the old system | Project lead | Old system access set to read-only |
| 2 | Final stock count or cycle count of high-value items | Warehouse lead | Count sheets signed |
| 3 | Close the period in the old system; run final reports | Finance controller | Trial balance, ageing, stock valuation saved |
| 4 | Extract final data | Delivery team | Record counts logged |
| 5 | Load master data, then open transactions, then opening balances | Delivery team | Load logs without errors |
| 6 | Reconcile trial balance, receivables, payables and stock against the old system | Data owners | Tie-outs signed |
| 7 | Switch integrations to the new ERP | Delivery team | Test transaction in and out |
| 8 | Smoke test: one transaction per key process | Champions | Results logged |
| 9 | Go or no-go confirmation | Sponsor and process owners | Decision recorded |
| 10 | Open the new system to all users | Project lead | Users notified |
If you are moving from servers you run yourself to a hosted system, add the infrastructure steps (network access, single sign-on, printing and device set-up) to the run book and rehearse them too.
What should the go or no-go decision include?
A short meeting, at a fixed time, where the sponsor and process owners review the readiness criteria and the final reconciliation, then decide. Record the decision and any accepted risks.
- Every readiness criterion marked met, or met with an accepted exception
- Final reconciliation tie-outs signed by data owners
- Open defects reviewed, with workarounds confirmed
- Hypercare team confirmed and available
- Rollback trigger points agreed: what would make the team stop, and by when
If a criterion is not met, delaying is often cheaper than going live and fixing in production. A delay is a decision, not a failure.
What is the rollback plan?
A rollback plan states how the business returns to the old system if cut-over fails, and the point after which rollback is no longer practical. It is rarely used, but writing it forces clarity about risk.
- Rollback trigger: for example, reconciliation cannot be completed by a set time, or a critical process cannot run in the new system
- Point of no return: usually once real transactions have been posted in the new ERP and shared externally, such as invoices sent or payments made
- Steps: reopen the old system, re-enable integrations, communicate to staff, record any transactions made in the meantime
- Decision owner: normally the sponsor, on advice from the project lead and finance
If you need help planning the switch for a packaged system, our ERP implementation services cover readiness, cut-over and hypercare.
What happens during hypercare?
Hypercare is a period of intensive support straight after go-live, when the delivery team, champions and process owners are on hand to fix issues and answer questions quickly. It ends on agreed exit criteria, not on a fixed date alone.
Hypercare checklist
- Support desk hours published, with a single place to log issues
- Champions on the floor or online in each team, especially in the first days
- Daily stand-up: new issues, priorities, fixes released, messages to users
- Issues classified as defect, data issue, training need or change request
- A watch list of first-time events: first payment run, first supplier statement reconciliation, first inter-company transaction, first payroll if in scope
- Integration monitoring: failed or duplicated messages checked daily
- Adoption measures reviewed weekly (see ERP change management)
Hypercare exit criteria
| Criterion | Example measure |
|---|---|
| Issue volume | New issues per day low and falling, no open critical issues |
| First close | First month-end completed and reviewed |
| Stability | Integrations running without manual correction |
| Ownership | Process owners handling routine questions with champions |
| Handover | Support moved to the agreed ongoing support model |
After hypercare, ongoing support should be clear: who fixes defects, who handles small changes, and how requests are prioritised. Agree this support model in writing before go-live, so the end of hypercare is not also the end of help.
How do you close the first month-end in a new ERP?
Plan the first close as a rehearsed event with extra time, a detailed task list and the delivery team on hand. It is the real test of whether sub-ledgers, integrations and reports work together.
First month-end close checklist
- Confirm all receipts, invoices and payments for the period are posted in the new ERP
- Reconcile bank accounts
- Reconcile receivables and payables sub-ledgers to their control accounts
- Reconcile stock: quantity and value by location against the inventory account
- Post accruals, prepayments, depreciation and any currency revaluation
- Clear any migration clearing or suspense accounts to zero
- Review inter-company balances so both sides agree, if you run more than one entity
- Run management reports and compare them with the trend from the old system; explain differences
- Lock the period
- Hold a short review: what took longest, what was manual, what to fix before the next close
Our guide to the ERP reports finance teams need helps you check that the close pack is complete.
Illustrative scenario: a phased go-live
This is an illustrative example, not a client case. A group with three trading companies chooses to go live entity by entity rather than all at once. The first, smallest entity goes live at a month start and completes its first close. Lessons from that close, such as a missing accrual report and a slow bank reconciliation, are fixed before the second entity's cut-over. The trade-off is a period in which inter-company transactions cross between old and new systems, which needs a documented manual process.
When is a big-bang go-live the wrong choice?
A single go-live for everything is simpler to plan and avoids running two systems side by side. It is riskier when entities, sites or modules are very different, or when the team cannot support everyone at once during hypercare. A phased approach, by entity, site or module, lowers the risk per step but adds temporary interfaces and a longer overall timeline. Our ERP implementation roadmap discusses module order in more depth.
Full parallel running, entering every transaction in both systems, is rarely worth it. It doubles the workload and produces small timing differences that are hard to explain. A short parallel run for one high-risk calculation, such as payroll, can still make sense.
How to start
Write your readiness criteria and your go-live calendar constraints now, even if go-live is months away. If you are still selecting a system or a partner, our ERP RFP template includes questions to ask about cut-over and hypercare.
Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so you can see how the team handles a smaller go-live before the main one. Discuss your project with us.