Odoo Upgrade Guide: Planning a Move from v14, v15 or v16 to v18

If you run Odoo 14, 15 or 16 and want to reach 18, the short answer is this: it is a project, not a button. Odoo provides an upgrade service that migrates the standard data and schema. What it cannot do for you is rewrite your custom modules, retrain your users, or decide which customizations are still worth keeping. Budget your time around those three things, not around the upgrade tool.

This guide covers what Odoo’s own documentation says about the process, where the real effort sits, and a sequence that keeps risk low. It is written for owners and operations or IT leads who need to plan, not for developers who will run the commands.

Why you cannot stay put forever

According to Odoo’s upgrade documentation, each major version gets three years of support, and databases then get two more years to complete the upgrade. The same page says you can stay on a version indefinitely, but does not recommend it, and that databases on a major version must be upgraded every two years.

Counting from each version’s October release (2020, 2021 and 2022), v14 is past both the support period and the extra upgrade period, v15 is at the end of its extra period, and v16 is out of its three-year support but still inside the two-year upgrade period. Check the current dates for your version on Odoo’s side rather than relying on ours, since the policy applies per database and hosting type.

Staying put has real costs: fewer or no vendor fixes once support ends, growing incompatibility with third-party apps and connectors, and a bigger jump later. Odoo itself notes that the smaller the version gap, the easier the upgrade should be.

One caution: Odoo ships a new major version every year, so 18 is not the newest release. If you are planning for late 2026 or 2027, ask whether a newer version is a better target before you commit. Version 18 is a reasonable answer, but it should be a decision rather than a default.

What the upgrade covers, and what it does not

The documentation is explicit about the boundaries. An upgrade moves a database to a newer supported version. It does not cover:

• Downgrading.
• Switching edition, for example Community to Enterprise.
• Changing hosting type.
• Migrating from another ERP.

If you want to change edition or hosting at the same time, treat that as a separate workstream and do not bundle it into the same cutover weekend.

The documented hosting paths differ:

Hosting	How the upgrade works
Odoo Online	Rolling release. For mandatory upgrades Odoo runs a silent test upgrade first, and you can also request a test upgrade yourself from the database manager.
Odoo.sh	Integrated with the upgrade platform. The upgraded production backup is restored on a staging branch, and each commit re-runs the restore and a module update.
On-premise	You run Odoo’s upgrade script from the command line, with network access to the upgrade servers.

Teams on open-source Odoo can also look at the OCA OpenUpgrade project, described on its repository as an open source upgrade path for Odoo and maintained by the Odoo Community Association. It is a different path with different guarantees, so confirm its coverage for your exact versions and modules before relying on it.

Where the effort really is: custom modules

This is the line that matters most in the official documentation: a database with custom modules cannot be upgraded until those modules are available for the target version. Odoo recommends requesting a test database and upgrading your custom code in parallel.

Odoo’s guide to upgrading a customized database lays out a sensible order. The parts worth knowing as a decision-maker:

1. Freeze development. Bug fixes are fine. New features on the old version only add to the migration bill.
2. Challenge every customization. Compare each one with what standard Odoo does in the target version. Some of your v14 workarounds may now be standard features. Removing a custom module is the cheapest migration there is.
3. Make modules installable on an empty target-version database. Odoo lists typical breakages: invalid dependencies, syntax changes (assets, OWL, attrs), removed or renamed fields, views and methods, and XPaths that moved.
4. Test behavior, not just installation. A module that installs can still be wrong at runtime. Views, email templates, reports, server and automated actions, and computed fields all need checking, ideally with automated tests.

The older your source version, the larger the gap on this front. The front-end framework and view syntax changed meaningfully across these releases, so v14 custom code usually needs more rework than v16 code. We will not put a number on it, because it depends entirely on how much custom code you have and how it was written.

A sequence that works

Here is the order we would plan, adapted from Odoo’s recommended steps.

1. Inventory (week 1). List installed apps, custom modules, Studio customizations, third-party apps, integrations (payment, shipping, e-commerce, accounting exports), reports and scheduled actions. Mark each one keep, replace with standard, or retire.

2. Request a first test upgrade. Do this early, before any custom work. The goal, per Odoo, is to confirm that the standard upgrade works and that you receive a usable test database. If it fails, Odoo support wants to hear about it through the upgrade testing option, and you want to know now.

3. Port the custom code. Work against an empty target-version database first, then against the upgraded copy of your data.

4. Test with real users. Note that the test database is delivered without the filestore, so attachments and some documents will not behave as in production until you account for that. Have people run their actual month-end close, a real sales order to invoice cycle, and the reports they send to auditors or lenders.

5. Rehearse the cutover. Time it. Decide in advance how long production will be frozen, who signs off, and what the rollback is. The rollback is simply keeping the old production database untouched until you are satisfied.

6. Go live and monitor. Report post-upgrade issues promptly. Keep a short list of people who can verify numbers in the first week, particularly in accounting and inventory valuation.

Skipping versions: one jump or several?

The documentation does not give a hard rule on how many versions you can skip in one request, only that smaller gaps are easier. Going from v14 to v18 means crossing four major versions of changes, so expect more test cycles and more differences for users to absorb than a v16 to v18 move. If the stakes are high, ask Odoo or your partner what path they recommend for your specific hosting and edition.

Risks to plan for

• Accounting. Check opening balances, tax configuration, fiscal positions and localization changes. If you operate in the EU or UK, check your e-invoicing and tax reporting setup against the target version before cutover.
• Integrations. APIs, connectors and webhooks written for older versions may need changes.
• Users. Even without custom code, the interface and some workflows differ. Schedule training, and do not plan the cutover for your busiest week.
• Third-party apps. Confirm each one has a release for the target version, or has a standard replacement.

What it costs

We will not quote figures here because they vary widely with database size, amount of custom code, number of integrations and how much testing you do in-house. A useful rule: the upgrade tool itself is the smallest line in the budget. Custom module porting, testing and training are the largest.

Next step

If you are weighing whether to move now, wait for a newer version, or retire some customizations first, we are happy to talk it through. Teknologia Solutions offers a no-charge conversation where we review your current version, your custom modules and your constraints, and tell you honestly whether an upgrade is the right next step. No obligation, and you keep the notes either way.

---

Sources: Odoo 18.0 documentation: Upgrade; Odoo 18.0 documentation: Upgrade a customized database; OCA OpenUpgrade. Support windows, hosting procedures and tooling change between releases, so verify details against Odoo’s primary documentation and your own contract before planning.