The ERP Customisation Trap

No organisation sets out to build an unupgradeable ERP. It happens one reasonable request at a time. A sales director needs a field the standard object does not have. A controller needs an approval step the workflow engine cannot express. Each change is small, each has a sponsor, and each is approved on its own merits.

Where the cost actually lands

The build cost is the part everyone estimates, and it is the smaller half. The rest arrives later:

• Every vendor upgrade must be regression-tested against every customisation.

• Documentation drifts, so the knowledge lives with whoever wrote it.

• Support gets harder — the vendor cannot reproduce your behaviour.

• The next migration has to reverse-engineer intent from code.

The compounding effect is what does the damage. Twenty small customisations do not cost twenty times one; they cost the combinatorial testing surface of twenty, plus the organisational reluctance to touch any of them.

The ladder

Before writing code, walk down the options in order and stop at the first one that works.

• Change the process to match the standard flow.

• Configure — fields, picklists, layouts, native workflow.

• Extend outside the core, in an integration or a side service.

• Modify the core. Last resort, with a named owner and a review date.

The question is never 'can we build this?' It is 'who maintains it through the next three upgrades?'

Make the trade-off visible at approval

Requests get approved because the benefit is stated and the cost is not. Change the form. Every customisation request should carry an owner, the business decision it enables, the upgrade-testing burden it adds, and a date on which someone will ask whether it is still needed. Most requests survive this; a useful minority evaporate on contact with the maintenance question.

Schedule the removal review

Customisations often outlive their reason. The report that justified one was replaced two years ago; the regulation that justified another was superseded. An annual pass that asks 'what breaks if we delete this?' reliably retires a handful, and each retirement makes the next upgrade cheaper.

The goal is not zero customisation. It is a small, documented, deliberately chosen set that the team can name from memory — because that is the set they can still safely change in three years.