ERP Customisation: How Much Is Advisable Without Breaking Upgrades?
Dylan Coetzee · ERP Solution Architect & Founder · 14 min read · May 2026
Quick answer: ERP customisation is advisable only where standard configuration cannot meet a genuine, durable business requirement. Keep total customisation below 20–30% of project budget. Above that, the platform is the wrong fit, or the business is using development to dodge change management. Heavy customisation creates upgrade fragility — every vendor release becomes a regression-testing project, and the true five-year cost of a custom build is typically 4–6x the initial quote.
Every ERP vendor will tell you their system is highly configurable and can be adapted to your specific requirements. What they are less forthcoming about is the cost of that adaptation, who pays to maintain it, and what happens every time they release an upgrade.
ERP customisation is sometimes necessary. It is also one of the most abused concepts in ERP sales — used to paper over the gap between what a platform actually does and what a prospect needs it to do. Understanding where the line sits between sensible ERP customisation and expensive overengineering is one of the most valuable judgements you can make before committing to a platform — whether you are deploying for a Small Business in Australia, a Mid-Market manufacturer in the UK, or an Upper Mid-Market group running across the EU, GCC and India.
Configuration vs Customisation: Not the Same Thing
The distinction matters before anything else.
| Aspect | Configuration | Customisation |
|---|---|---|
| Method | Settings, parameters, workflows, custom fields, approval rules | Code: extensions, bespoke modules, schema changes, custom integrations |
| Vendor support | Fully supported | Partial or none |
| Upgrade safety | Generally safe | May break on every release |
| Ownership | Standard platform | You own the maintenance burden |
| Documentation needs | Low | High and continuous |
Configuration is almost always safe. Customisation is a long-term commitment that needs to be made with full awareness of the ongoing cost. The line between them is also where vendors love to be vague — particularly during sales cycles. If a "configuration" requires a developer, it is customisation.
The Upgrade-Fragility Cost Nobody Fully Prices
When a business decides to customise an ERP, the cost conversation focuses on the initial build. This is a fraction of the true cost.
The full cost of an ERP customisation includes:
- Initial build — the development time to design, build and test. The number in the proposal.
- Regression testing on every upgrade — cloud SaaS vendors push updates quarterly or twice a year. Every customisation must be re-tested against the new codebase. Each release is a mini-project.
- Rebuilds when the vendor changes the underlying API or data model — and they do, regularly, particularly on aggressive cloud platforms.
- Documentation maintenance — undocumented customisations are unmaintainable. When the original developer leaves, you either freeze the system at its current version or pay to reverse-engineer it.
- Ongoing bug fixes — custom code has custom bugs. Every unhandled edge case becomes a support ticket.
- The eventual rewrite — typically 5–8 years in, the customisation becomes incompatible with the vendor's direction and must be reworked or replaced.
When you add these up, a USD 30,000 customisation build commonly represents USD 150,000–200,000 in total cost of ownership over five years — and that is before counting the productivity cost of upgrade delays caused by customisation regression. The broader cost picture is in How Much Does ERP Actually Cost?.
This is what we mean by upgrade fragility. The more you customise, the more expensive every release becomes — and the more likely you are to stay on an old version, missing security patches, compliance updates (think MTD changes in the UK, e-invoicing rollouts in the EU and India, ZATCA phases in Saudi Arabia, GST rule changes in India and Australia) and new functionality the vendor is shipping to your competitors.
When ERP Customisation Is the Right Answer
There are processes that no standard ERP supports well — because they are genuinely specific to an industry, a regulatory environment, or a business model that exists in a small enough segment of the market that no vendor has invested in native functionality.
Consider a Mid-Market supplier of medical prosthetics and orthotics operating across the UK NHS, EU healthcare systems and private clinics in the GCC. Fulfilment looks nothing like standard product distribution: a clinician assessment triggers a custom fabrication order, a box of fitting tools is dispatched alongside the prosthetic, trial periods are managed, returns are conditional on clinical assessment rather than simple defect criteria, and billing splits across patient, insurance provider, healthcare system and regional reimbursement schemes — all under regulatory documentation requirements that do not map to standard sales order processing.
No ERP ships a prosthetics module. The functionality has to be built.
When you are in this position — when your core business process has no native equivalent in any standard platform — the question is not whether to customise but which platform to customise on. And the answer has significant financial implications.
This is also the moment to revisit whether a niche or industry ERP is the right starting point. For industries with genuinely specific operational requirements, a purpose-built platform often ships with more native functionality than a customised general platform — at a lower total cost. See Major ERP Vendor vs Niche ERP.
The Cheaper Platform Argument
This is an argument that does not get made often enough.
If your business has operational requirements that will demand significant customisation regardless of which platform you choose, the cost of the ERP licence becomes a variable that can fund that development. Choosing an expensive Mid-Market platform and then paying to customise it is not the only option. Choosing a less expensive or open-source platform and directing the licence savings into fit-for-purpose development is frequently more economical — and produces a better long-term outcome because you own the code.
A worked example across a five-year horizon:
| Platform path | 5yr licence + support | Customisation build | Customisation maintenance | 5yr total |
|---|---|---|---|---|
| NetSuite + heavy customisation | USD 400k–600k | USD 150k–250k | USD 100k–180k | USD 650k–1.03M |
| Dynamics 365 BC + customisation | USD 300k–500k | USD 120k–220k | USD 80k–150k | USD 500k–870k |
| Odoo Enterprise + custom modules | USD 80k–160k | USD 100k–180k | USD 50k–100k | USD 230k–440k |
| ERPNext / Odoo Community + dev partner | USD 30k–80k | USD 120k–200k | USD 60k–120k | USD 210k–400k |
(Ranges assume a Mid-Market deployment of 75–250 users with non-trivial custom modules. Regional partner rates vary — EU and ANZ at the higher end; India, LATAM and parts of Eastern Europe at the lower end.)
The Odoo and ERPNext paths leave the business owning the code, running on open-source infrastructure, with the IP staying with the business if the development partner changes. That is a structural advantage worth real money.
This logic applies across any industry with genuinely unique operational requirements: specialist manufacturing, complex field services, industry-specific compliance workflows, non-standard inventory models. When the customisation is inevitable, the platform cost is a direct opportunity cost.
For the cloud-vs-self-hosted dimension of this decision — including how it affects your control over custom code and upgrade timing — see Cloud vs On-Premise ERP.
When ERP Customisation Is the Wrong Answer
The more common scenario — and the more dangerous one — is a business that wants to customise a standard ERP to preserve an existing process the new system would naturally change.
This happens when:
- The finance team does not want to change how they run month-end, so a custom workflow replicates the old system's behaviour
- The sales team wants custom pricing rules that mirror the exact logic of a 15-year-old spreadsheet, instead of adopting the new pricing module
- A manager does not want to learn a new approval process, so a custom form routes around the standard workflow
- A regional office wants to keep doing things "the way we have always done it" because they are nervous about the rollout
These are not business requirements. They are change resistance, dressed up as requirements — and they are expensive to accommodate. Every time the ERP is customised to preserve how things were done in the old system, the business is paying to avoid the change the ERP was bought to deliver.
The correct response is not "yes, we can build that." It is "we need to understand whether the existing process is genuinely better, or whether this is about comfort with what is familiar." This distinction sits at the core of managing change during an ERP implementation — and both the implementation team and the executive sponsor need to hold it clearly.
Customisation Governance: The Rules to Set Before Go-Live
A customisation request log without governance becomes a customisation backlog. Set the rules before development starts.
- Default answer is no. Every customisation request must be justified against the standard process. The bar to clear is "the standard process cannot meet a real business requirement," not "the standard process is unfamiliar."
- One approver, not a committee. A single executive sponsor signs off every customisation above a defined effort threshold. Committees rubber-stamp; individuals interrogate.
- Phase 1 is like-for-like wherever feasible. Save enhancement for Phase 2, once the business has lived with the platform long enough to know what genuinely matters. See Big Bang, Phased, or Module-by-Module.
- Document everything at build time, not later. Untested, undocumented customisation is technical debt with compound interest.
- Cap the budget at 20–30% of project total. Above that, escalate to the steering committee with a formal "is this the right platform?" review.
The Questions to Ask Every Vendor About Customisation
Before you commit to a platform, understand exactly what customisation will cost — to build and to maintain.
- What is your approach to customisation — a sandboxed extensibility framework that survives upgrades, or direct core modification?
- How are customisations handled at upgrade time — who is responsible for testing and rebuilding if the upgrade breaks them?
- Can you show me a customisation built for a client in my industry, and how it has fared across the last two major version upgrades?
- What documentation do you produce for customisations, and who owns it after go-live?
- If we self-host or move to a different partner, do we have full ownership of all custom code and its IP?
- How does your customisation model accommodate regional compliance changes — e-invoicing mandates, tax rule changes, statutory reporting updates?
A vendor who answers with specific methodology and concrete examples has done this before and understands the ongoing cost. A vendor who says "upgrades are smooth, customisations rarely break" has not been honest with their existing clients.
The Rule of Thumb
A reasonable customisation ceiling for a Mid-Market ERP implementation is 20–30% of total project budget. Above that, one of two things is usually true: the platform is a poor fit for the operational requirements, or the business is using development to avoid change management.
If you are heading toward 40–50% of your project budget in customisation, stop and ask the harder question: is this the right platform? A different system — particularly an open-source one — might deliver the required functionality at a fraction of the total cost, with a codebase you own and can evolve without vendor permission.
The most expensive customisation in ERP is the one built on the wrong foundation.
Frequently Asked Questions
How much ERP customisation is too much?
As a working rule, total customisation above 20–30% of project budget on a Mid-Market deployment indicates the platform is a poor fit, or the business is using development to dodge change management. Above 40%, you are funding a custom build wrapped around an off-the-shelf product. At that point you should formally reassess whether a different platform — particularly an open-source one, a niche industry ERP, or a build-on-platform approach — would be cheaper, more flexible and easier to maintain over five years.
Does customisation break ERP upgrades?
Often, yes. Customisations made through a vendor's supported extensibility framework (custom fields, scripted automations within sandboxed APIs, workflow extensions) usually survive upgrades cleanly. Customisations that modify core code, change the data schema, or rely on undocumented internals frequently break — sometimes silently. Every customisation needs regression testing on every release. Cloud SaaS vendors push 2–4 releases per year, which means heavily customised systems become continuous regression projects. This is the core upgrade-fragility cost.
What is the difference between ERP configuration and customisation?
Configuration uses the system's existing capabilities — setting parameters, activating modules, defining workflows, creating custom fields within the standard data model, adjusting approval rules. No code. Vendor fully supports it. Upgrades do not break it. Customisation extends the system beyond its native design — writing code, building bespoke modules, altering the schema, or creating custom integrations. The vendor may not support the result, and upgrades can break it. Configuration is almost always safe; customisation is a long-term commitment.
Can you avoid ERP customisation entirely?
Rarely, and not advisably. Even well-fitting platforms typically need some customisation — region-specific tax handling, an industry-specific document, a non-standard approval flow. The goal is not zero customisation; it is minimum necessary customisation. Choose a platform whose standard functionality covers 80%+ of your core processes, customise only where business value clearly justifies it, and keep the customised footprint small enough that upgrades remain tractable.
How much does ERP customisation cost over five years?
The initial build is typically 25–35% of the five-year customisation cost. The rest is regression testing, rebuilds, documentation, bug fixes and the eventual rewrite. A USD 30,000 build commonly becomes USD 150,000–200,000 over five years. A USD 250,000 enterprise customisation can reach USD 1M+. Cost varies sharply by platform: aggressive cloud SaaS platforms with frequent releases drive higher maintenance cost; stable on-premise and self-hosted platforms drive lower maintenance cost.
Should we customise NetSuite or choose a cheaper platform?
If your customisation requirement is large enough that NetSuite licence savings would meaningfully fund the build elsewhere, seriously evaluate the alternative. NetSuite typically carries USD 400k–600k over five years in licence and support for a Mid-Market deployment. Odoo Enterprise or ERPNext with a capable development partner can deliver comparable functionality for USD 200k–400k all-in — leaving budget for genuinely useful custom modules and the business owning the code. The right answer depends on industry fit, regional partner availability and integration footprint.
Who owns ERP customisation code?
Read the contract carefully. With proprietary SaaS platforms, customisation often lives inside the vendor's tenant; you have a licence to use it but may not be able to take it elsewhere. With open-source platforms (Odoo, ERPNext) and self-hosted deployments, you own the code outright and can move it between partners or environments. This matters most at partner-switch time. If you are anticipating significant custom development, ownership terms are a structural negotiation point — not a footnote.
How do we govern ERP customisation requests during a rollout?
Set the rules before development starts. Default answer is no. Single executive sponsor signs off every customisation above a defined effort threshold. Phase 1 is like-for-like wherever feasible — enhancement waits for Phase 2. Document at build time. Cap total customisation at 20–30% of project budget; above that, the steering committee reviews whether the platform is right. Governance is the difference between a project that ships and a project that customises itself into a five-year delay.
How ERPLenz Helps You Avoid Customisation You Should Not Be Paying For
Customisation need is a direct consequence of platform fit. The closer the match between a platform's native capability and your operational requirements, the less custom development the project demands — and the lower the long-term maintenance burden.
ERPLenz's assessment flags where functional gaps between your requirements and each platform's native capability will likely require development, and surfaces this risk before you commit. Budget is applied as a hard filter: the total cost of ownership — including realistic customisation cost for each platform given your requirements profile — is used to eliminate options that exceed your budget before they reach your shortlist.
The vendor intel in your report identifies known customisation patterns on specific platforms: where other businesses have had to build custom solutions, what those solutions cost to maintain, and which platforms offer lower-cost paths to the same outcome through open-source or modular development.
Know the real cost of the fit before the contract is signed.
Written by ERP consultants who have spent more time than they would like un-customising poorly governed implementations across NetSuite, Dynamics 365, SAP, Odoo and ERPNext. The right platform asks less of you in the first place.
On selection and fit
On cost and implementation
