ERP Customisation vs Configuration: Where to Draw the Line

Configuration means adjusting an ERP system's built-in settings, fields, and workflows within what the platform natively supports; customisation means writing custom code to make the system do something it wasn't designed to do. The line matters because configuration survives upgrades and stays supportable, while customisation compounds cost and risk with every version change - so the right approach is to configure by default and customise only where a process is a genuine source of competitive advantage.

Why This Distinction Gets Blurred in Practice

On paper, the difference is clean: configuration uses what the platform already supports - custom fields, workflow rules, approval hierarchies, report layouts - while customisation means writing code that changes core functionality or extends it into territory the vendor never built for. In practice, the line blurs constantly, because configuration options can be stacked in increasingly elaborate combinations that function like custom logic without technically being custom code, and the maintenance burden creeps up long before anyone notices it crossed a line.

The pressure to customise usually comes from a reasonable place: a department has a process that genuinely works well for them, and the standard workflow feels like a step backward. The mistake is treating every one of those requests as equally deserving of custom development, rather than asking whether the process in question is actually a source of competitive advantage or just a habit nobody has questioned in years.

A useful illustration: a business insists its discount approval workflow is unique and needs custom code, but on closer inspection the actual requirement is a three-tier approval hierarchy the platform already supports natively through standard configuration - the team had simply never explored the configuration options because the first person to raise the requirement assumed it would need custom development. A short discovery conversation with someone who actually knows the platform's configuration depth resolves a surprising number of 'we need customisation' requests before a single line of code is written.

The Real Cost of Customisation Nobody Budgets For

The build cost of a customisation is the visible part of the bill. The invisible part shows up at every future upgrade, when the vendor changes the core platform and every custom module has to be re-tested, sometimes rewritten, to keep working - turning what should be a routine upgrade into a mini-project. Heavily customised ERP implementations we've reviewed routinely fall multiple major versions behind because upgrading has become too expensive and risky to schedule, which eventually leaves the organisation on an unsupported version with security and compliance exposure nobody planned for when the first customisation was approved.

There's a compounding effect too: each additional customisation increases the surface area that needs re-testing at the next upgrade, and customisations often interact with each other in ways that make isolating a post-upgrade bug considerably harder than testing a single change in isolation. Organisations that customise heavily in year one frequently find that by year three, the combined weight of accumulated customisations makes even a routine security patch a multi-week testing exercise rather than a same-week update.

A Simple Test for Deciding Which Processes Deserve Customisation

• Does this process directly create a customer-facing or competitive advantage, or is it purely internal administrative convenience?
• Has anyone actually validated that the standard workflow can't achieve the same outcome with different steps, or was it dismissed on first look?
• What is the cost of re-testing and maintaining this customisation across every future upgrade, not just building it once?
• Could this be achieved through configuration, a third-party add-on, or a lightweight integration instead of core code changes?
• If this process changed to match the vendor's standard tomorrow, what would actually break for the business, versus what would just feel unfamiliar?

Configuration-First Doesn't Mean Configuration-Only

The point isn't to refuse every customisation request - some processes genuinely are the reason a business wins deals or serves customers better than competitors, and forcing those onto a generic workflow erodes the advantage the ERP was meant to support. The point is making the decision deliberately, process by process, with the upgrade-cost trade-off made visible to whoever approves it, instead of accumulating customisations by default because saying yes to each individual request feels easier than saying no.

The organisations that navigate this well tend to have a lightweight governance forum, not a heavyweight committee, just a short recurring review, where customisation requests are weighed against this framework before development starts, rather than after a developer has already built it and stakeholders feel invested in defending the decision. Reviewing before the build, not after, is what keeps the conversation about the business case rather than sunk cost.

Making the Call Without Endless Debate

Maintaining a simple customisation register - what was built, why, who approved it, and what it will cost to re-test at the next upgrade - turns an invisible, accumulating liability into a visible one that gets reviewed periodically rather than discovered as a crisis during the next major upgrade cycle. Organisations that keep this register consistently customise less over time, not because they've become more conservative, but because the true cost is finally visible at the point of decision.

The practical fix that ends most customisation debates quickly: require every customisation request to state, in writing, which specific competitive or regulatory reason justifies deviating from standard configuration, reviewed by someone senior enough to say no. Requests that can't articulate that reason clearly are almost always better served by configuration, and making the bar explicit turns what used to be a political negotiation into a straightforward, defensible decision.