Planning a multi-version jump from Odoo 14, 15 or 16 to Odoo 20

You can upgrade from Odoo 14, 15 or 16 straight to the latest version without installing each version in between. Odoo's upgrade service takes your database and a target version and returns an upgraded database in one request. The effort in a multi-version jump is in your custom modules, which have to be rewritten for the target version, and in the several rounds of testing that follow.

This post is for companies that have stayed on an older version and are now looking at Odoo 19 or the upcoming Odoo 20. As of 22 September 2026, Odoo 20 has not been released. It is due at Odoo Experience on 24 September, and nothing below depends on its features. If you are only one or two versions behind, our guide to upgrading to Odoo 19 from 16, 17 or 18 is shorter and more direct.

How Odoo's upgrade service handles a multi-version jump

You never choose the intermediate versions. You name the target, and the upgrade platform handles the rest. Odoo's own documentation describes an upgrade as moving a database "from an older version to a newer supported version" and gives 16.0 to 18.0 as its example. The target must be a supported version. Today the upgrade form offers 19.0, 18.0 and 17.0.

How you submit depends on hosting:

• On-premise: run Odoo's upgrade script on the database server, or upload a dump through the upgrade page.
• Odoo.sh: use the Upgrade tab on a staging branch. The platform sends the latest daily production backup, restores the result and then updates your custom modules on every commit.
• Odoo Online: request the upgrade from the database manager. Custom Python modules can't be installed on Online, so the question of porting them doesn't come up.

python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>

Two practical details catch people out. The upgraded dump comes back without your production filestore, so you have to merge the returned filestore folder with your existing one before testing. And the script needs outbound access on port 443 and on a range of high TCP ports. Strict corporate firewalls often block that range.

The service is part of an Enterprise subscription. The upload form asks for your subscription code. Community databases need the community-maintained OpenUpgrade project or a partner-led migration instead.

Why custom code decides the size of the job

Odoo's documentation is blunt: a database with custom modules cannot be upgraded until a version of those modules exists for the target version. Odoo's SLA covers standard apps and Studio customisations. It does not cover in-house or third-party modules, unless they are under a maintenance-of-customisations subscription.

In a multi-version jump, your code has to absorb every change between your version and the target, all at once. Odoo's upgrade guide lists the kinds of breakage you can expect:

• invalid module dependencies;
• syntax changes in asset declarations, OWL components and view attrs;
• references to standard fields, models or views that were renamed or removed;
• XPaths into views that have moved;
• renamed or removed methods.

Data is the other half. When a model changes shape across versions, custom data has to be moved with upgrade scripts. Odoo's own example is custom fields on sale.subscription, which aren't migrated automatically when that model was merged into sale.order in Odoo 16. The upgrade-util helpers (rename_field, rename_model, rename_xmlid) exist for exactly this.

A multi-version jump doesn't cost the same as several single upgrades. The standard part is one request. The custom part is one rewrite against a much larger set of changes.

That is why the first step in Odoo's guide is to stop development and challenge every customisation. Between 14 and 19, a lot of what companies once built themselves has become standard. Each module you drop is one you don't port.

The six steps Odoo recommends for a customised database

1. Stop development and challenge it. Freeze the codebase except for bug fixes, and compare each module with what the target version does as standard.
2. Request an upgraded test database. The only aim here is to confirm the standard upgrade succeeds on your data.
3. Make your modules work on an empty database of the target version. Install them one by one, fix tracebacks, test, clean the code and get the standard tests passing.
4. Make them work on the upgraded database. Write upgrade scripts for renamed fields and moved data, re-enable views the upgrade disabled, and update records flagged noupdate.
5. Test extensively and rehearse. Request fresh test upgrades as you go, and do a full rehearsal the day before go-live.
6. Upgrade production. The database is unavailable while this runs, and on Odoo Online it can't be reverted once complete.

How many testing rounds to plan

We plan at least three rounds for a multi-version jump, and more if the module list is long. The first round is technical: the standard upgrade on its own, checking the upgrade report Odoo posts in Discuss for disabled views and other warnings. The second runs your ported modules on the upgraded database. The third is user acceptance: key users run real flows end to end, such as purchase to receipt to bill, or quotation to delivery to GST invoice, and compare results with production.

Request a fresh upgraded database for each round. Odoo advises this because the upgrade scripts and your data keep changing. Remember that test databases are neutralised. Scheduled actions are off, mail goes to a fake server, and payment providers and bank sync are disabled. Test integrations deliberately, with sandbox credentials.

Odoo 19 now or Odoo 20 as the target

Odoo 20 can't be a target until Odoo releases it and the upgrade platform offers it. If you start now, the realistic target is Odoo 19. You can move from 19 to 20 later as an ordinary one-version upgrade. If you start in a few months, 20 may be available. The porting work you have done by then carries forward, because most of the gap between 14 and 20 is the gap between 14 and 19. Our now-or-wait guide weighs this by version.

Either way, start with the inventory in our Odoo 20 readiness checklist. When you want to see your own database on the target version, request a test upgrade with us. It is the fastest way to turn a vague worry into a list of specific fixes.