12 Common ERP Implementation Mistakes (and How to Avoid Them)

ERP projects rarely fail because of software. They fail because of decisions made — or avoided — along the way. These are the mistakes we see most often when asked to review or recover projects, roughly in the order they occur.

1. Starting without measurable goals

“Replace the old system” is not a goal. Without measurable outcomes — faster close, accurate stock, fewer manual steps — there's no basis for prioritising scope or judging success.

Avoid it: write three to six success criteria before selecting a platform.

2. Choosing on demos alone

Vendor demos show strong flows on clean data. Your awkward cases never appear.

Avoid it: write scripted scenarios from your real processes and ask vendors to demonstrate them with your data.

3. Recreating the old system

Teams ask for screens and steps that mirror the legacy system, including workarounds for problems the new ERP doesn't have.

Avoid it: for each requirement, ask what business outcome it serves. Then let the new system achieve it its own way.

4. Over-customising

Every “small change” becomes code to maintain and port at every upgrade. Dozens of them make the system expensive and fragile.

Avoid it: configure first, change the process second, customise last. Keep a register of every customisation and its justification.

5. Under-resourcing key users

Key users are expected to do project work on top of full-time jobs. Workshops get cancelled, testing gets rushed.

Avoid it: allocate time explicitly and backfill where needed.

6. Treating data migration as a task

Migration left until the end reveals duplicates, gaps and inconsistent units two weeks before go-live.

Avoid it: start profiling during discovery, script the loads and rehearse at least twice. See the data migration guide.

7. Ignoring integrations until late

Integrations are scoped vaguely, built late and tested only on happy paths.

Avoid it: list every integration early with direction, volume and ownership. Test failure scenarios. Read our ERP integration guide.

8. Skipping proper testing

User acceptance testing compressed to make up for delays, run by the partner rather than users.

Avoid it: users write and execute test scenarios. Don't trade testing time for schedule.

9. Generic training

Everyone attends the same overview weeks before go-live, on demo data.

Avoid it: role-based training on real transactions, close to go-live, with quick-reference guides.

10. Going live when numbers don't reconcile

Pressure to hit the date overrides the fact that opening stock or balances don't tie out.

Avoid it: agree go/no-go criteria in advance, including reconciliation, and stick to them.

11. Disappearing after go-live

The implementation team leaves on go-live day. The first month-end becomes a crisis.

Avoid it: plan hypercare through the first period close.

12. No ownership after the project

Nobody owns the system internally once the project ends. Configuration drifts, data quality declines, and workarounds return.

Avoid it: name a system owner, keep a change process and a support arrangement.

Recovering a project in trouble

If several of these sound familiar, the project can usually be recovered. Start with an independent audit: configuration, data quality, custom code, integrations and governance. Fix the issues costing money or trust first, then rebuild momentum with a realistic plan. Our ERP audit service covers exactly this.