Every ERP demo ends the same way: someone asks, "can it do this the way we do it?" The answer is almost always yes, with enough customisation. That yes is where the trouble starts. The more you bend an ERP to match exactly how you work today, the more expensive, fragile, and un-upgradeable it becomes. The customisations that feel essential during the project are the ones that haunt you for years after it.
Configuration is not customisation
There is a line between configuring an ERP and customising it, and it matters enormously. Configuration means using the settings the system already provides: turning features on, defining workflows, setting rules, mapping your chart of accounts. Customisation means changing the code, adding bespoke modules, or altering how the system fundamentally behaves. Configuration is supported, upgrade-safe, and cheap. Customisation is bespoke software bolted onto a product, and it carries all the cost of bespoke software forever.
Most "we need it to work our way" requests can be met by configuration. The temptation is to reach for customisation because it matches the current process exactly, without asking whether the current process is even worth preserving.
Why heavy customisation hurts
The costs of over-customising show up long after go-live, and they compound.
It breaks your upgrade path. Every customisation is code the vendor did not write and does not test against. When the ERP releases a new version, each customisation has to be re-checked, re-fixed, and re-tested. Enough of them, and upgrading becomes so painful that you simply stop, freezing on an aging version that slowly falls behind on features and security.
It multiplies cost, forever. A customisation is not a one-time build. It is a permanent liability that has to be maintained, documented, debugged, and migrated at every upgrade. The build quote is the smallest number you will ever pay for it.
It hides a process problem. Customising the ERP to match exactly how you work today assumes that how you work today is right. Often the implementation is the best chance in a decade to fix a clumsy process, and heavy customisation throws that chance away by cementing the old way in code.
It ties you to whoever built it. Bespoke customisations are understood by the people who wrote them. When they leave, or the partner changes, that knowledge walks out with them, and the system becomes a black box nobody dares touch.
When customisation is worth it
This is not an argument for never customising. It is an argument for customising only where it earns its keep. The test is simple: does this customisation support something that genuinely differentiates the business, something customers value that competitors cannot easily copy? If yes, it may be worth the lifetime cost. If it just preserves an internal habit that happens to be how things were always done, configure instead, or change the habit.
The best implementations customise narrowly and deliberately: a handful of changes where the business truly is different, and standard configuration everywhere else.
A worked example
A manufacturer implementing ERPNext arrived with a list of forty customisations, each described as essential. Worked through one at a time, most were not. Thirty were how-we-do-it-today habits that the standard system could handle with configuration, sometimes better than the old way. Seven were genuine needs that could be met with light, upgrade-safe extensions. Three were real differentiators worth building properly. The project shipped with three customisations instead of forty. Two years and two version upgrades later, the upgrades were routine, and the system still fit the business, because the business had adopted the standard wherever the standard was fine.
Standard where you can, bespoke where you must
An ERP is a product, not a blank canvas, and its value comes from the enormous amount of thinking already baked into the standard version. Every customisation trades away a slice of that value and takes on a permanent cost, in exchange for matching how you happen to work today. Sometimes that trade is worth it. Usually it is not. The discipline that keeps an ERP healthy for years is the willingness to adopt the standard wherever it is good enough, and to spend your customisation budget only where the business is genuinely, defensibly different.
If you are planning an ERP implementation and want the customise-versus-configure line drawn deliberately rather than by whoever argues hardest in the room, that is part of how we run it. Our team delivers ERP and CRM implementation that keeps you on the upgrade path. Book a discovery call and we will separate the customisations you need from the ones you only think you do.
Frequently asked questions
What is the difference between ERP configuration and customisation?
Configuration uses the settings the ERP already provides (features, workflows, rules, account structures) to fit your business, and it is upgrade-safe and low-cost. Customisation changes the underlying code or adds bespoke modules to alter how the system behaves, which carries the full lifetime cost of bespoke software. Most requirements can be met by configuration; customisation should be reserved for genuine differentiators.
Why is heavy ERP customisation risky?
Because every customisation is code the vendor does not maintain or test against. It has to be re-checked and re-fixed at every upgrade, which can make upgrading so painful that businesses freeze on an old version. It also multiplies ongoing cost, ties you to whoever built it, and can cement a poor process in code instead of improving it.
Should we ever customise our ERP?
Yes, where it genuinely differentiates the business, something customers value that competitors cannot easily copy. Those cases can justify the lifetime cost. What to avoid is customising simply to preserve how you happen to work today when standard configuration would do, often better. Customise narrowly and deliberately, and configure everywhere else.
How does customisation affect ERP upgrades?
Each customisation must be re-validated and often re-worked every time the ERP releases a new version, because it sits outside what the vendor tests. The more customisations you carry, the more expensive and risky each upgrade becomes, until many organisations stop upgrading altogether and fall behind on features and security. Keeping customisation minimal keeps upgrades routine.