Odoo Customisation Discipline: How to Customise Without Breaking Upgrades

Odoo gives you four different ways to customise the platform: configuration in the UI, Studio for no-code data and view changes, custom modules in Python and OWL, and direct modification of core modules. Each level has more power and more upgrade risk. The implementations that succeed long-term are surgical about which lever they pull for which problem.

The customisation hierarchy

Level 1: configuration. Use built-in settings and UI options to change behaviour. Cost: minutes. Upgrade risk: zero. Always try this first.

Level 2: Studio. Add fields, modify views, create automations, build approval workflows without writing code. Cost: hours. Upgrade risk: low. Studio changes survive upgrades cleanly in almost all cases.

Level 3: custom modules. Python and OWL code in your own module that extends standard models without modifying core. Cost: days to weeks. Upgrade risk: medium. Survives upgrades with predictable maintenance work.

Level 4: forking core. Modifying the standard module code directly. Cost: anywhere. Upgrade risk: catastrophic. Almost always wrong; only acceptable for very specific patches that you commit to maintaining forever.

The discipline rule: try the lowest level first

Every customisation request should be triaged against the hierarchy. 'Can we do it with configuration? No? Studio? No? Custom module? Yes? Build the custom module.' Most teams skip the triage and go directly to custom modules because that is what the developer's first instinct is. The result is a codebase that should have been three Studio automations and ends up being three thousand lines of custom Python.

Make this an explicit gate in the implementation process. The Studio-vs-code decision should be made by a senior architect, not by the developer who wants to write code.

Custom modules that survive upgrades

When you do need a custom module, the patterns that survive upgrades are well-known: extend models with new fields and methods rather than overriding existing ones; use proper inheritance (_inherit) rather than monkey-patching; avoid relying on internal implementation details of core methods; write tests that run against the Odoo test framework; pin your module versions to Odoo versions and update them deliberately.

The customer-specific code should look like a clean Odoo module that happens to be private. If a developer joining the team can read it the same way they would read a public addon, you are doing it right.

Upgrade cycles are a discipline

Odoo releases a new major version every year. You do not have to upgrade every year, but you should plan to be no more than two versions behind at any time. The upgrade is a project: read the migration notes, run your customisations through the migration scripts, test against a full production data copy, fix what breaks, plan the production cutover. Companies that defer upgrades indefinitely end up with implementations that cannot be moved, cannot be supported by mainstream partners, and cannot benefit from new features.

Budget for an upgrade every 12–18 months. Treat it like any other strategic platform investment. The companies that do this stay current; the ones that do not eventually replace the system entirely at much higher cost.

In closing

Odoo's customisation power rewards discipline and punishes recklessness. The teams that customise surgically end up with a platform that grows with them; the teams that customise aggressively end up trapped on an old version.