ERP configuration means using the settings, rules and tools the vendor provides, such as tax codes, approval limits and custom fields. ERP customization means adding or changing code. Configuration usually survives upgrades; extensions built on supported interfaces usually survive with retesting; changes to the vendor's core code are what break upgrades and lock you onto old versions.
The distinction matters most after go-live. Every change made during implementation has to be carried through every future upgrade, by someone, at a cost. This guide sets out four levels of change, how each behaves at upgrade time and how to govern change requests so the system stays maintainable.
If you are implementing a packaged ERP, our ERP implementation services cover configuration, extensions and governance. If the required customizations are piling up, it may be time to compare with custom ERP software.
What is the difference between ERP configuration and customization?
Configuration changes how the product behaves using options the vendor supports; customization changes what the product is by adding code. In practice there are four levels, not two.
| Level | What it is | Examples | Upgrade risk |
|---|---|---|---|
| 1. Configuration | Settings and master data the vendor supports | Tax codes, payment terms, approval limits, numbering, user roles | Low: carried forward by the vendor |
| 2. Low-code personalisation | In-product tools for fields, layouts and simple rules | Extra fields, page layouts, report designers, workflow builders | Low to medium: usually retained, sometimes needs review |
| 3. Extension | New code using the vendor's supported extension model | New modules, integrations, event-driven logic, custom reports | Medium: must be retested and sometimes updated each upgrade |
| 4. Core modification | Changing the vendor's own source code or database directly | Editing standard posting logic, altering standard tables | High: conflicts on every upgrade; can block upgrading entirely |
How do vendors handle extensions?
Most modern ERP vendors push customization into a supported extension model and discourage core changes. Two examples, checked on the vendors' own documentation in October 2026:
- Microsoft Dynamics 365 Business Central. Microsoft's developer documentation describes extensions written in the AL language as the programming model for adding functionality: you create new objects and extend existing ones, such as adding fields to the item table with a table extension, rather than editing the base objects. Extensions are compiled into app packages and deployed to the environment. Our comparison of Business Central vs custom ERP covers when this model is enough.
- Odoo. Odoo customization is commonly done through custom modules. Odoo's upgrade documentation states that a database containing custom modules cannot be upgraded until a version of those modules is available for the target version, and it treats upgrading custom code as the customer's job. Our guide on when Odoo customization should become a rebuild explores the tipping point.
The lesson holds across vendors: extensions keep upgrades possible, but they still have to be maintained against every new release. They are not free after go-live.
Which changes break upgrades?
Core modifications break upgrades most often; extensions break them when they depend on behaviour the vendor changes. Common causes:
- Editing standard code or tables. Every vendor update to the same object conflicts with your change.
- Extensions that depend on undocumented behaviour. If an extension relies on a field or process the vendor did not commit to, a release can quietly change it.
- Direct database writes. Integrations that write straight into tables bypass validation and break when the schema changes.
- Copies of standard reports or pages. A modified copy does not receive the vendor's fixes to the original.
- Customizations nobody documented. If no one knows a change exists, no one retests it.
Should you customize or change your process?
Change the process when the package's way is reasonable and your way is habit; customize when your way is how you win or how you stay compliant. A simple rule helps.
| Question | If yes | If no |
|---|---|---|
| Does this process differentiate us with customers? | Consider extension | Adopt the standard process |
| Is it required by a regulator, contract or auditor? | Configure or extend to meet it | Adopt the standard process |
| Can configuration or low-code tools achieve it? | Use them first | Go to the next question |
| Can a supported extension achieve it? | Extend, with tests and documentation | Do not modify core; reconsider the package |
| Will we need this in five years? | Build it properly | Use a workaround or report |
When many requirements fall to the bottom rows, the package may not fit. That is the point where a bespoke or hybrid approach becomes worth costing.
How should change requests be governed?
Govern every change request through one route, with a business owner, a level classification and an upgrade impact note. Without this, customization accumulates one reasonable request at a time.
Change request checklist
- Business owner named and problem stated in business terms
- Standard process and configuration options checked first
- Level classified (configuration, personalisation, extension, core modification)
- Core modifications refused unless the steering group signs off the upgrade cost
- Upgrade impact noted: which objects are touched, what must be retested
- Automated or scripted tests added for extensions
- Documentation updated in a register of all customizations
- Approval recorded, with priority and target release
Approval chains for change requests work like any other business approval; our approval workflow design guide covers thresholds and delegation.
Keep a customization register
A register lists every configuration choice that matters, every extension and every integration, with an owner and test notes. Before each upgrade, the team works through the register. It is also the first document a new implementation partner should ask for. Include it as a deliverable when you write your ERP RFP.
Illustrative scenario
A distributor asks for a change so warehouse staff cannot ship orders for customers over their credit limit. The team checks configuration first and finds a standard credit hold setting that covers most of the need. The remaining requirement, an override with manager approval logged against the order, is built as a small extension using supported events, documented in the register and given test scripts. No standard code is touched, and the next upgrade needs only a retest.
How do you test customizations before an upgrade?
Test every extension and integration in a copy of production running the new version, before the upgrade reaches live users. A repeatable routine:
- Read the release notes and mark any area that touches objects listed in your customization register.
- Refresh a sandbox from production data and apply the new version there first.
- Recompile or reinstall extensions and fix any errors the platform reports.
- Run automated tests for each extension, then the scripted business scenarios: order to cash, purchase to pay, period close.
- Test integrations end to end, including banks, e-commerce and payroll, with real file formats.
- Have key users sign off the scenarios they own.
- Schedule the live upgrade with a rollback plan and a short hypercare period.
The effort of this routine is the real cost of customization. A system with a few well-documented extensions can be retested in days; one with many undocumented changes can take far longer and tends to fall behind on versions.
What should the implementation contract say about customization?
The contract should make customization visible and owned. Points worth writing in:
| Clause | Why it matters |
|---|---|
| Deliverable: customization register kept up to date | You can upgrade or change partner without archaeology |
| Ownership of extension source code and documentation | You are not locked to one partner |
| Standard-first rule: configuration before code | Limits unnecessary custom work |
| Upgrade support: who retests and fixes extensions, on what terms | Avoids surprises at the first major release |
| Out-of-scope requests reviewed and agreed before work starts | Cost and delivery changes are transparent |
| Test scripts handed over with each extension | Retesting does not depend on memory |
What about custom ERP: is there still a difference?
In a custom ERP the same discipline applies, but you own the upgrade cycle. There is no vendor release to break your changes; instead, you decide when frameworks, libraries and modules are updated. Configuration still matters: approval limits, tax codes and roles should be settings that administrators change, not code that developers change. A well-built custom system is designed so routine business changes are configuration, and only genuinely new capability is development.
When is heavy customization the wrong path?
Heavy customization is the wrong path when it recreates a bespoke system inside a package. Signs:
- Most of your core workflow lives in extensions rather than standard features
- Upgrades are postponed because retesting customizations is too costly
- Only one consultant understands the changes
- Licence fees are paid for features you have replaced with custom code
At that point, compare the cost of continued customization with a cleaner route: re-implementing closer to standard, or moving the distinctive workflow to purpose-built modules integrated with the package.
How to start
List every customization you have or plan, classify each by the four levels, and note who owns it. If you are selecting a new ERP, write the classification into your requirements so vendors must say which needs are configuration and which need code. Our software requirements brief template helps structure this. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, which is a practical way to test whether your distinctive workflow belongs in an extension or a purpose-built module. Discuss the project with us.