What to get right before an ERP go-live

ERP projects rarely fail because the software could not do the job. They fail at go-live, when the data does not match, the warehouse cannot find a workflow it recognises, and finance quietly keeps using the old spreadsheet. Here is what we insist on before switching a business over.

Map the process as it really is

Every company has an official process and a real one. The real one includes the credit exception that one customer has had since 2019, the stock adjustment the warehouse manager makes on Friday, and the invoice that is always raised manually.

Configure for the official process and those exceptions do not disappear; they move into spreadsheets alongside your new system. We sit with the people doing the work first, write the process down, and decide explicitly which exceptions get supported, which get fixed, and which get dropped.

Data migration is most of the risk

Migration is where timelines go. Treat it as its own workstream with its own checklist:

• Decide what actually moves. Open balances, active customers, live stock and current orders usually do. Ten years of closed transactions usually do not: archive them somewhere readable instead.
• Clean before you load. Duplicate customers and dead product codes are cheaper to fix in a spreadsheet than in a live ERP.
• Reconcile every load. Trial balance, stock valuation and open receivables must agree with the old system to the currency unit, and someone in finance has to sign that off.
• Rehearse it. Run the full migration at least twice against a copy. The second run should be boring.

Run in parallel for one full cycle

One complete business cycle, usually a month, with both systems live is the cheapest insurance available. It is duplicated effort for a few weeks, and it is the only way to find that the new system rounds tax differently or posts a shipment a day earlier than the old one.

If finance cannot close a month in the new system while the old one is still running, it is not ready to be the only system.

Phase the rollout, department by department

A single big-bang cutover across finance, warehouse, production and retail on the same Monday means every problem arrives at once, with no one left who can fall back. Phasing by department (or by site) keeps the blast radius small and gives each group trained colleagues to ask.

Integrations deserve the same treatment. Point of sale, e-commerce, payroll and logistics should go live one at a time, each with its own reconciliation.

Train on your data, not on a demo

Training on a vendor demo dataset teaches people where the buttons are. Training on your own products, customers and workflows teaches them their job in the new system. We build role-based sessions around the tasks each group performs daily, then leave short written runbooks behind for the tasks performed monthly.

Agree the go-live checklist in advance

1. Reconciliation signed off by finance.
2. Stock counted and matched, with the count date agreed.
3. Every integration tested end to end, including failure cases.
4. Permissions reviewed per role, not copied from one admin account.
5. Backups running and a restore actually performed.
6. A named person per department for the first two weeks, and a daily stand-up.
7. A written rollback decision: what would make you stop, and who decides.

None of this is exciting, and all of it is the difference between an ERP that becomes the single source of truth and one that becomes an expensive second place people copy numbers from.