The Odoo Version Upgrade Path, and Why Skipping Costs More

Odoo releases once a year

A new major version arrives roughly annually. Each is supported for a limited window, after which it stops receiving fixes, including security fixes.

That support window is the real clock. Feature releases are a reason to want to upgrade; falling out of support is the reason you eventually have to.

Upgrades step through versions

Odoo does not convert a database directly from an old version to the newest one in a single transformation. The conversion moves through the intervening releases, applying each version's changes in turn.

Two consequences follow, and they pull in opposite directions.

The database side is largely fine. It is mechanical, it is the part Odoo's own upgrade service handles, and whether it does one step or four rarely changes the shape of the work.

The code side is where skipping compounds. Your custom modules must work against the destination framework, and every version between here and there contributed changes they have never met. Skipping does not avoid that work, it accumulates it into one testing cycle.

Why annual is cheaper than every four years

The total effort of four annual upgrades and one four-version upgrade is roughly comparable. The risk is not remotely comparable.

Upgrading annually, you absorb one version of change at a time, against code you were recently working in, with a known-good previous state to compare against. When something breaks, the search space is one version wide.

Upgrading every four years, everything arrives at once. The search space is four versions wide, nobody remembers why the code was written that way, there is no intermediate state to diff against, and the people who wrote the customisations may have moved on. The same total work becomes far harder to sequence, estimate and verify.

That is the honest argument for staying current, and it is worth making in budget terms rather than technical ones: annual upgrades are a predictable recurring cost, deferred upgrades are an unpredictable one-off.

What the current version does not tell you

Two databases on the same old version can be completely different projects. What actually predicts the effort:

• How many custom modules, and whether they extend cleanly or fight the framework
• How many integrations, since each is a separate contract that field renames can break
• Whether reports were customised, because those are the customer-facing failures
• How much validation the business needs before it will sign off

Data volume matters far less than people expect and user count barely matters at all. If someone quotes an upgrade from your version number and database size alone, they are guessing. The useful thing to send is the custom module inventory.

Do not change hosting at the same time

Moving between Odoo Online, Odoo.sh and self-hosted is its own migration with its own constraints. Doing it in the same window as a version upgrade doubles the number of possible explanations for anything odd, and you will spend the go-live window arguing about which change caused what.

Separate them. Upgrade, stabilise, then move, or move first and upgrade after. Either order beats both at once.

The decision, in practice

If you are one or two versions behind, upgrade on the normal annual cadence and keep it boring.

If you are three or more behind, treat it as a project with a testing plan and a rollback deadline rather than a maintenance task, and use it as the moment to retire customisations you no longer need.

If you are so far behind that every module needs rewriting and the processes have changed anyway, price a fresh implementation with a data migration alongside the upgrade. Sometimes it wins, and it is better to find that out during estimating than halfway through.