Odoo Upgrades
An Odoo upgrade is not a 'click here' affair. It's a project with a scope, a budget, a test plan and a cut-over date — and the maturity of how you treat it determines whether it lands cleanly or breaks your business for two weeks.
We've upgraded clients from Odoo 12 to 17, 14 to 18, 16 to 19. Some upgrades took two weeks; some took two months. The variable isn't the version gap so much as the amount of custom code, the number of OCA modules in use, and the discipline of the team running it.
This guide is the playbook we follow internally for every upgrade engagement. If you take one thing from it: never upgrade in production, never skip the test cycles, and never let the upgrade become 'while we're at it, let's also redesign things'. Scope discipline saves the project.
Why upgrade at all — and why now
Each major Odoo version is supported for three years. After that, no more security fixes from Odoo, no Enterprise support, no module updates from the App Store. Staying on an unsupported version means accumulating risk and technical debt — and eventually you upgrade anyway, just later and worse.
Beyond support, each major version brings real improvements: better UX, faster reports, new features in modules you already use. We've seen clients gain back hours of monthly work just by moving from v14 to v17 because the accounting reconciliation flow improved that much.
- Each major version supported three years — staying behind = security and feature debt
- After support cut-off: no security fixes, no Enterprise support, no app updates
- New versions bring real UX, performance and feature gains in modules you already use
- Upgrade later = upgrade worse — debt compounds version by version
- Every two years is a healthy upgrade cadence for most SMEs
What actually changes between versions
Odoo's core data model evolves: fields renamed, models split, new modules introduced, old modules deprecated. The official upgrade tool handles the standard data, but it can't know about your custom fields, custom views, custom workflows. Those are your responsibility — and your cost.
Custom code written for v14 won't necessarily run on v17. Method signatures change, ORM behaviour changes, the JS framework changes (OWL adoption). The bigger your custom footprint, the bigger the upgrade. This is one of several reasons we push clients to keep customisation lean.
- Standard models evolve — Odoo's tool handles those
- Custom fields, views, workflows = your responsibility to migrate
- Custom Python code may need rewrites — method signatures, ORM behaviour change
- JS layer changed deeply (OWL framework) — old QWeb / legacy JS often needs updates
- OCA modules need their own upgraded versions — check availability per module before committing
The upgrade workstream — three environments, two cycles
We always work with at least three environments: a production copy (frozen reference), an upgrade staging (where the upgrade is run and tested), and a final UAT (where users validate). Two test cycles minimum — one to find issues, one to confirm the fixes.
The cut-over to production is rehearsed end-to-end on the staging environment. Time it, document each step, identify the rollback decision points. The actual cut-over weekend is then a known operation, not an experiment.
- Three environments minimum: prod copy, upgrade staging, UAT
- Two test cycles minimum — find issues, then confirm fixes
- Cut-over rehearsed end-to-end on staging, timed and documented
- Rollback decision points defined — at what stage do we abort and revert
- UAT signed off by business before cut-over scheduled
Custom code, OCA, and the dependencies that bite
Inventory all custom modules and OCA modules in use. For each, decide: upgrade (and budget for it), drop (and migrate the use case to standard), or replace (with a different module). This decision drives 60% of the upgrade cost.
OCA modules are great until upgrade time. Each module has its own community maintainer; some are updated for the new version on day one, some take six months, some never. We always check OCA module availability for the target version before quoting an upgrade — surprises here ruin budgets.
- Inventory all custom and OCA modules — for each, decide upgrade / drop / replace
- Custom-code rewrite is 60% of upgrade cost for typical implementations
- OCA module availability for target version checked before quoting
- Some OCA modules never get upgraded — plan for replacement or refactor
- Upgrade is a great moment to delete unused customisations — be ruthless
Cut-over weekend and post-go-live
Plan the cut-over for a low-activity period — typically a weekend. Lock the production system, run the final upgrade from the latest production data, run smoke tests, switch DNS / users, monitor. Most cut-overs we run finish within a Friday-night-to-Sunday-evening window.
The first week post-upgrade is intensive. Hyper-care from the implementation team, daily standups with key users, fast triage of reported issues. Most issues are minor (views, permissions, small data quirks); a few will require code fixes. Plan for it.
- Cut-over in low-activity window — typically Friday evening to Sunday evening
- Final upgrade run from latest production data, not from staging snapshot
- Smoke tests scripted and executed before users return on Monday
- Hyper-care week 1 with daily standups — most issues caught and fixed in first 5 days
- Communication plan for users — what's new, what changed, where to ask
Upgrade mistakes that turn projects ugly
These are the mistakes we see most often when clients try to upgrade without our involvement.
- 'Quick' upgrade in production with no staging — broken business and no rollback.
- Letting the upgrade scope creep into a redesign — every workshop adds work and the date slips.
- Not inventorying OCA module availability — discover at week three that key module isn't ready.
- No UAT cycle — go-live exposes issues to all users at once.
- Forgetting integrations — the EDI feed, the e-commerce sync, the BI exports all need testing.
Metrics that prove the upgrade went well
We track these for two weeks post-cut-over. Healthy upgrade = healthy numbers.
- Cut-over completed in planned window — no overflow into Monday business hours.
- Smoke tests pass before users return on Monday morning.
- Number of P1/P2 issues in week 1 below pre-agreed threshold (typically <10).
- All integrations (EDI, e-commerce, payment, BI) operational by Tuesday.
- User satisfaction survey at +2 weeks shows >75% positive.
How we run Odoo upgrades at Flydoo
We start every upgrade with a discovery: inventory of custom modules, OCA dependencies, integrations, customer list of pet-peeve issues to fix while we're in there. From the discovery comes a fixed-scope quote — including the drop / replace / upgrade decision per module.
Then it's the standard playbook: upgrade staging, two UAT cycles, cut-over rehearsal, cut-over weekend, hyper-care. We never let scope creep happen during the upgrade — improvement requests are logged for the next quarterly release, not bolted onto the cut-over.
- Discovery: inventory custom + OCA + integrations + pet-peeve list
- Fixed-scope quote with drop / replace / upgrade decision per module
- Three environments: prod copy, upgrade staging, UAT
- Two UAT cycles minimum, cut-over rehearsed end-to-end
- Hyper-care week 1, scope creep deferred to next quarterly release
Practical checklist before scheduling your Odoo upgrade
Walk this list with your IT lead and Odoo product owner. Most ticked = ready to schedule.
- Custom module inventory complete with decisions: upgrade / drop / replace
- OCA module availability verified for target version
- Integration list documented with test plans (EDI, e-commerce, BI, payment)
- Three environments provisioned: prod copy, upgrade staging, UAT
- Two UAT cycles scheduled with key users
- Cut-over weekend agreed and communicated to business
- Rollback plan documented and rehearsed
- Hyper-care plan defined: who, when, how to escalate
Key takeaways
- Upgrade every two years is a healthy cadence — staying behind compounds risk
- Custom code and OCA modules drive 60% of upgrade cost — inventory ruthlessly
- Three environments minimum: prod copy, upgrade staging, UAT
- Cut-over rehearsed end-to-end on staging — never improvise on the actual weekend
- Scope discipline matters — don't let the upgrade become a redesign
- Hyper-care week 1 catches and fixes 80% of post-upgrade issues
Frequently asked questions
Can we skip versions, e.g. v14 to v17 directly?
Yes, the Odoo upgrade tool handles multi-version jumps. The risk doesn't grow linearly with the gap — it grows with the amount of custom code that needs porting and the OCA module landscape change. We've done v12 → v17 in one go, and v15 → v16 that took longer because of a heavily customised manufacturing module. Plan based on your custom footprint, not just the version distance.
How much does an Odoo upgrade cost?
For a small SME on standard Odoo with one or two custom fields, a few thousand euros. For a mid-size company with a dozen custom modules, OCA dependencies and integrations, typically €15-50k. For a complex multi-entity setup with heavy customisation, six figures is realistic. The cost driver is custom code, not the upgrade itself.
Should we upgrade and add new features at the same time?
We strongly advise against it. Upgrades are about parity — same business processes, new version. New features are a separate project, ideally after the upgrade is stabilised. Mixing them makes scope unmanageable and rolls back impossible. Let the dust settle two months, then build new things.
Does Odoo Online (SaaS) get upgraded automatically?
Yes — Odoo manages the upgrade for SaaS customers, typically once per year. The tradeoff is less control over timing and over which custom modules you can install. For Belgian SMEs we often recommend Odoo.sh or self-hosting precisely because they let you control the upgrade schedule and customisation surface.
What if the upgrade exposes data quality issues?
It's actually one of the benefits — and one of the surprises. Upgrades often expose long-standing data quirks that the previous version tolerated. We treat this as a positive: clean it up during the upgrade window and you get a healthier database afterwards. The pain is real but the outcome is good.
Need help applying any of this to your own context? We're happy to talk.