Every new Odoo version brings real improvements — better performance, cleaner interfaces, features your teams have been asking for. Yet in many companies, the annual release announcement lands with quiet dread instead of anticipation. Somewhere in the system sits custom code that nobody fully understands anymore, and everyone suspects an upgrade will break it.
That fear is rarely irrational. It is the predictable bill for decisions made years earlier, usually under deadline pressure: a quick edit inside Odoo's core, a patch applied straight on the server, a feature bolted on without tests or version control. The customization worked on day one. The debt comes due at upgrade time.
We build customizations with one non-negotiable assumption: this system will be upgraded, repeatedly, for as long as it exists. That single assumption changes almost everything about how the work is done.
Why editing core is borrowed time
Odoo is designed to be extended, not edited. When an integrator modifies core files directly, the customization and the framework fuse into one inseparable blob. The next version replaces those core files — and with them, silently, everything that was patched in. At that point the company faces a painful menu: reconstruct the changes by archaeology, pay someone to diff years of undocumented edits, or simply stop upgrading.
Freezing the version is the most common choice, and the most expensive one. A frozen Odoo means no security fixes, no new features, growing friction with connectors and libraries, and a shrinking pool of people willing to maintain it. A core hack does not save time. It converts a few hours saved today into a structural liability that compounds with every release cycle.
What module-grade customization actually means
The alternative is not less customization — it is customization done as engineering rather than improvisation. Every change we ship lives in its own module that extends Odoo through the framework's official inheritance mechanisms. Core stays untouched. The module declares its dependencies, carries its own data, views and tests, and can be installed, upgraded or removed as a unit.
Before writing a line of custom code, we check whether the community has already solved the problem. We work Community-first and lean on the OCA — the Odoo Community Association — whose published modules and coding conventions are the closest thing the ecosystem has to a shared engineering standard. Following those conventions is not bureaucracy; it is what allows any competent Odoo developer, years later, to open the code and understand it.
Discipline around the code matters as much as the code itself. Every module we deliver is versioned in Git with a readable history, goes through code review before it merges, and ships with automated tests that pin down the behavior it is supposed to guarantee. When the next Odoo version arrives, those tests are the difference between verifying a migration and hoping for one.
Upgrade-testing, and what to demand from any integrator
A module is not finished when it works on the current version. Part of our routine is testing custom modules against the next Odoo version — running the test suite, exercising the real workflows, and fixing incompatibilities while they are still small. When an actual migration happens, it follows the same discipline: dry-runs on a copy of the data, a reconciliation report that proves what came across, and a rollback plan in case something does not. Restore-tested backups sit underneath all of it.
If you are evaluating an integrator — including us — these are the commitments worth demanding in writing:
- No core edits, ever. All customization lives in dedicated modules that extend Odoo through supported mechanisms.
- Community-first sourcing. A maintained OCA module beats a bespoke rewrite of the same feature.
- Version control you can see. Full Git history, with the customer given access to their own code.
- Code review and automated tests on every module, not just the big ones.
- A written upgrade story. Dry-runs, a reconciliation report, and a rollback plan for any migration.
- A verifiable price. Fixed-price quotes after proper scoping, so discipline is built into the budget rather than billed by the hour of firefighting.
- Support with real commitments. Tiered SLAs with defined response times, and role-based training so the system is actually used the way it was built.
Custom code is not the enemy of upgrades — undisciplined custom code is. Built module-grade, reviewed, tested and versioned, your customizations become assets that travel with you from version to version instead of anchors that hold you to one. And if a version jump is already on your horizon with custom modules in the mix, our migration approach — reconciliation reports, dry-runs and rollback plans included — is laid out in detail on our services page.