Customisation is Odoo's most-cited strength and its most-cited difficulty, and both are accurate. The framework is well documented, the developer market is deep and comparatively affordable, and almost any requirement can be met. What is less visible during selection is that each custom module joins a portfolio you must carry through every future version upgrade.
The customisation layers
Ways to change Odoo behaviour, from cheapest to most binding
| Layer | What it does | Upgrade obligation |
|---|---|---|
| Configuration | Settings, pricelists, approval settings, user groups | None — configuration carries forward |
| Studio (Enterprise) | Add fields, adjust forms and views, simple automation without code | Low — generally survives upgrades |
| Automated / server actions | Rule-based automation defined in the interface | Low to moderate — verify after each upgrade |
| Custom Python modules | New models, business logic, integrations | Permanent — must be re-tested and often reworked at each version |
| Core modification | Changing base Odoo behaviour directly | Severe — avoid entirely |
When customisation is justified
The useful test is competitive difference. If a process is how you compete — a pricing model your customers value, a service commitment nobody else offers, a production method that is genuinely yours — then customising the system to support it is a sound investment. If a process is simply how you have always done it, adopting the standard is almost always cheaper across five years.
- Justified: a requirement that differentiates you commercially and cannot be met by configuration
- Justified: a regulatory or contractual obligation with no standard equivalent
- Justified: an integration to a system you must keep
- Rarely justified: replicating a screen layout from the system you are replacing
- Rarely justified: preserving an approval path that exists because of historical staffing
- Rarely justified: a report that could be produced from a pivot view with a little training
Third-party modules deserve their own assessment
Odoo's app marketplace is genuinely useful for niche requirements. Where a marketplace module supports a core process, though, you have taken on a dependency on an unrelated publisher's maintenance schedule. Assess the publisher as you would a vendor: how long has the module existed, has it been maintained across versions, and what happens if the publisher stops.
Governing the portfolio
Customisation governance that works
- A written register: module, purpose, requester, cost, and why standard was rejected
- Monthly review of the register with the project sponsor during implementation
- A stated upgrade policy — which versions you will adopt, and on what cadence
- A named owner for upgrade re-testing, internal or contracted
- Budget for upgrade maintenance from year one, proportional to portfolio size
- A periodic review asking which modules could now be retired
- Source code held in a repository you control, not only by the partner
If your customisation portfolio has grown beyond what you can comfortably upgrade, an independent review is usually the cheapest next step.
Book ERP Assessment