ERP Implementation Best Practices: Avoiding Common Pitfalls

Green to red in one week

The pattern is consistent enough to be diagnostic. Status is reported against build tasks (modules configured, scripts written, workshops held), which measure effort. The three things that decide whether you can go live are data quality, working integrations and the organisation’s ability to handle exceptions, and all three become measurable only near the end.

Change what is tracked from the first month. Count records failing validation against the target model, week over week. Count interfaces that have passed an end-to-end test with production-like volumes, not interfaces that have been written. Count test scripts executed by an actual business user rather than by a consultant.

Design decisions are cheap to argue and expensive to defer

Deferring a design decision feels neutral. It is not. The build continues on an implicit assumption, downstream work accretes around it, and the cost of reversal compounds with every week of silence. Decision debt behaves like technical debt with a shorter fuse.

A handful of choices carry the longest reversal path and should be forced early: legal entity structure, chart of accounts design, costing method, item master granularity, and the warehouse location model. Each is embedded in thousands of transactions within weeks of go-live, and close to unchangeable afterwards without a second migration.

Data migration is a business workstream that IT can only support

Only the business can decide whether two customer records are the same customer, whether an obsolete part should be migrated, or which of three prices is right. Treating migration as a technical task hands those judgements to people without the standing to make them, and they get made anyway, by default, near the deadline.

Measure migration by reconciliation rather than by load success. A load can complete cleanly and be wrong: correct row counts, plausible values, and a trial balance that does not agree with the source. Reconcile balances, counts and control totals back to a signed-off extract, and have a named person from the business sign each domain.

The counter-argument to “stay vanilla”

The standard advice is to avoid customisation entirely. It is good advice for the accounting core, where the package’s process is well-tested and your version creates no advantage. Applied universally it forces the business to abandon processes that are commercially valuable, and the result is not a clean implementation but shadow processes in spreadsheets the ERP never sees.

The honest position is that customisation is not the failure mode. Undocumented customisation, with no named owner and no regression test, is the failure mode. A well-scoped extension built on documented extension points, with a test pack maintained alongside it, survives upgrades at a predictable cost.

So the rule is not don’t customise. It is: customise deliberately, in a few places where the business case is explicit, and fund the tests alongside the build. If nobody will fund the test pack, that is the signal the customisation is not worth having. Where the platform is NetSuite, ERP and NetSuite work should make that boundary explicit before the first sprint.

Integrate for reconciliation, not just for transport

Most interface designs answer how a message travels. The design question that matters more in operation is how you know everything arrived. An integration without a reconciliation mechanism will drift, and the drift will be discovered by a customer.

Four properties are worth insisting on for every interface: idempotency, so a retry cannot duplicate a transaction; an error queue a named person reviews daily; a periodic count-and-value reconciliation against the source; and alerting that fires on the absence of expected traffic. The last is usually missing and matters most. A total outage is noisy and fixed within the hour; a silent partial success (the interface running happily but skipping a record type) can run for weeks.

Cutover is a rehearsal problem with a decision in the middle

The cutover runbook should be a timed script, rehearsed end to end, with durations recorded from the rehearsal rather than estimated. It needs an explicit go or no-go point, a named decider, and rollback criteria written before anyone is tired.

Agree in advance what defect level you will accept, because it will never be zero and the alternative is deciding at two in the morning with a warehouse waiting. Categorise open defects as blocking, workaround-available or accepted, and staff each workaround. An accepted defect with no named workaround owner is a blocking defect that has been renamed.

Hypercare is where the benefit is won or lost

Within days of go-live users will invent workarounds. That is not a failure of training; it is people meeting today’s commitments with whatever works. The problem is that a workaround invented in week one becomes permanent process by week six, and it is usually invisible because it happens outside the system.

Actively hunt for them during hypercare. Ask what people keep in spreadsheets, which steps they skip, and where they re-key. Each answer is a defect, a training gap or a design decision that was wrong, all cheap to correct in the first month and expensive later.

Retire the old reports on a published date. If legacy reporting stays available indefinitely the organisation runs two versions of the truth and the benefits case is never realised. Getting one trusted set of numbers out of the new platform is a data and commercial intelligence task in its own right, not a by-product of go-live.

What the programme should leave behind

Judge the end state by capability, not by a signed acceptance certificate. Is there an internal administrator who can make routine changes without a partner? Is there a documented configuration decision record with rationale? Is there a maintained test pack? Is there a change process that will still be followed in six months?

Programmes that skip this hand over a system that works on day one and calcifies by month twelve, because every change needs an external firm to rediscover why things were built as they were. The cost appears not in the implementation budget but in the run rate, permanently.