The software is rarely the reason an ERP project goes badly. Across implementations the same three causes recur: nobody owned the process decisions, the data was worse than anyone admitted, and scope kept moving. This is the sequence we run to avoid each of them.

1. Assign a decision owner before anything else

An ERP forces a company to state how it works. If two departments answer a question differently and neither has authority to settle it, configuration stalls in workshops. Name one person per domain โ€” finance, supply chain, sales, HR โ€” who can make a binding decision. This costs nothing and prevents the most common form of drift.

2. Audit the data before you promise a date

Open a sample of your item master, customer ledger and open purchase orders and actually read them. Duplicate customers under slightly different names, items with no unit of measure, opening balances that do not tie โ€” this is normal, and it is the single most reliable predictor of a delayed go-live.

Cleaning is a business task. Only the people who know why two records look identical can decide which one is right.

3. Configure to the agreed process, not to every request

Every implementation generates requests that are really personal preference. The test we apply: does this change a business outcome, or does it reproduce how the old system looked? Reproducing the old system is how you pay for new software and keep the old constraints.

Genuine divergence does exist, and that is what customisation is for. The point is to spend it deliberately.

4. Migrate in rehearsals, not once

Run the migration at least twice before cutover, against a full copy of the data, and reconcile the results each time โ€” trial balance, stock valuation, open AR and AP. The first rehearsal always finds problems. The purpose of the second is to prove the first ones are fixed.

5. Run a parallel period

For at least one full cycle โ€” usually a month โ€” record transactions in both systems and compare the closing numbers. It is genuinely tedious and it is the only thing that reliably surfaces the difference between "configured" and "correct".

6. Freeze scope through stabilisation

The weeks after go-live are for defects, not enhancements. Keep a list, and be visibly willing to build from it afterwards โ€” that is usually enough for people to accept the freeze.

What "done" looks like

  • Month-end closes in the new system without a spreadsheet reconciliation.
  • Every department reads the same number for stock, revenue and receivables.
  • The enhancement backlog is being worked, not ignored.