Most businesses don't plan to fall behind on their Odoo version. It happens gradually, for example the business is busy, the current version is stable enough, the upgrade feels like a project for next quarter. Then next quarter becomes next year and suddenly you are two or three versions behind and facing a migration that is significantly more complex and costly than it needed to be.
If you are planning an Odoo upgrade, whether you are one version behind or several, this is what you need to understand before you start.
1) Odoo upgrades are version-to-version. There are no shortcuts.
Odoo releases a new major version every year, with each version supported for three years. What many businesses don't realise is that there is no single migration path that jumps you from v14 straight to v19. Upgrades move version-to-version, which means:
- The further back you are, the more likely the upgrade needs to be staged across multiple versions, each requiring its own assessment, testing and sign-off.
- Every version in between represents real work, not a formality to pass through.
- The cost and complexity doesn't scale neatly. For example two skipped versions doesn't mean twice the work. In practice it often means three or four times the complexity, because the gap between old and new architecture is wider and more of your custom layer needs to be rebuilt.
If you are more than one version behind the current supported release, the first thing to establish is your full upgrade path and not just the destination.
2) The migration scripts cover standard Odoo. Everything else is handled separately.
This is the most misunderstood aspect of Odoo upgrades and where the most expensive surprises come from.
Odoo SA provides official migration scripts for each version transition. These cover the core platform, standard module structures and base data and they work well. What they don't cover is anything outside standard Odoo.
That includes:
- Custom modules built by your partner.
- Third-party and OCA (Odoo Community Association) apps you have installed.
- Integrations with external systems.
- Any bespoke development added after your original go-live.
Each of these needs to be individually assessed, updated and retested for every version in the upgrade path. If your implementation has significant custom development, what you are actually undertaking is a partial re-implementation of that custom layer on top of the upgraded core. It is not a clean lift-and-shift.
This distinction matters enormously for scoping. A business with a near-vanilla Odoo installation upgrading one version is a very different project to a heavily customised implementation upgrading three versions. Both might be described as "an Odoo upgrade" in a quote but they are not the same thing.
Make sure you understand which one you are actually paying for.
3) OCA and third-party modules don't have a guaranteed upgrade path
The Odoo ecosystem has a rich library of community and third-party modules. Many businesses rely on them for localisation, industry-specific features, reporting enhancements or capabilities that didn't exist in standard Odoo when they first went live.
The problem is that these modules run on their own development timelines, completely independent of Odoo SA's release schedule. When Odoo releases a new version, OCA module maintainers have to update their modules to be compatible and outcomes vary significantly:
- Some maintainers update quickly.
- Some update slowly.
- Some abandon the module entirely.
- Some modules get absorbed into Odoo core in a later version but behave differently to what you are used to.
The wider your upgrade gap, the higher the risk that a module you depend on has no compatible version for your target release or that the maintainer has made breaking changes across versions that require significant rework.
Before your upgrade project starts, every third-party module in your system needs to be audited. For each one: does a compatible version exist for the target release and if so, does it behave the same way? If a compatible version doesn't exist, you need a plan to either rebuild it, find an alternative or accept the functional gap.
That is a business decision, not a technical one and it is yours to make.
4) Your data carries the configuration decisions of every year you have been live
Odoo's migration scripts move your data. They don't validate whether that data reflects sound configuration practice and the longer you have been on the same version, the more opportunity there is for configuration to drift.
Common areas where this surfaces during upgrades:
- Chart of accounts structures set up quickly during go-live and never revisited.
- Tax configurations that produce the right numbers but aren't structured the way a newer version expects.
- Warehouse routing rules built as workarounds for limitations that no longer exist in the new version.
- Multi-company configurations that grew in complexity over time without anyone reviewing the full picture.
These aren't errors but they are configuration decisions that worked in the context of the version they were built on but that a newer, more mature Odoo handles differently. When those records migrate, the behaviour can change in ways that don't throw errors. They just quietly produce different outcomes.
The wider the version gap, the more of these mismatches you are likely to encounter. An upgrade is the right time to review how your system is actually configured, understand why things are set up the way they are and make deliberate decisions about whether that still makes sense.
5) Workarounds don't disappear when you upgrade
Every business accumulates operational workarounds over time such as manual steps, Excel exports, out-of-system approvals, duplicate data entry. These exist because the version you are on had limitations or because something wasn't configured properly at go-live.
The problem: upgrading Odoo doesn't automatically retire any of them. Unless you deliberately review what you are doing and why, you will arrive on a newer, more capable version and continue operating it like the old one.
Common examples worth reviewing before go-live:
- Manual steps that were supposed to be temporary but became permanent process.
- Exports to Excel that filled a reporting gap Odoo now handles natively.
- Duplicate data entry between systems because an integration was never completed.
- Approval steps done outside the system because the workflow wasn't set up correctly.
Before go-live on the new version, go through your current workarounds with your partner. For each one, ask: does the new version handle this natively? Most of the time the answer will be yes and the upgrade becomes an opportunity to eliminate friction that has been quietly costing your team time for years. But only if you make it one.
What to do before you start
If an upgrade is on the horizon, here is where to focus your preparation:
- Plan for multiple database migrations. It is not unusual to migrate 3, 4 or even 5 times before going live. It can be an iterative and time-consuming process, so plan accordingly.
- Ensure accurate and normalised data. It is much easier to migrate a database with normalised data than sanitising post-migration.
- Audit every custom module and third-party app. Get a clear view of what is in your system and what has a compatible version for your target release. If a third-party application or custom module addresses a missing feature or pain point that has been resolved in the version of Odoo you are migrating to, remove it prior to migrating.
- Map your integrations. Assume they need to be retested. Know what each one does and who owns it.
- Review your licence structure. Understand what changes between your current version and the target version.
- Document your critical workflows. If you can't describe how a process works today, you can't validate that it works correctly after the upgrade.
- Identify your workarounds. List the manual steps and temporary fixes that have become permanent and ask whether the new version makes them redundant.
The businesses that come through Odoo upgrades well aren't the ones who were lucky. They are the ones who understood what they were dealing with before the project started.