Odoo Upgrade Guide: Enterprise, Community and When to Move

I lead ERPNext and Frappe programmes at MithTech, a small senior AI-assisted team of Frappe specialists in Bengaluru. We support businesses on Odoo as well as ERPNext, including porting custom modules at upgrade time. We sell no Odoo subscription. The upgrade itself is a service; the custom modules are a project.

Which Odoo versions are supported?

Three major versions are in standard support: 20.0, 19.0 and 18.0. Odoo gives each major version three years of standard support, on Odoo Online, Odoo.sh and on-premise. After that, extended support is a paid extra, only on Odoo.sh for a limited number of versions and on-premise for any version. Security updates stop when standard support ends.

Odoo Online also gets SaaS versions (19.1 to 19.4 in 2026) every two to three months. They exist only on Odoo Online and are not eligible for extended support. Odoo's support page says you can upgrade from any version to any major version still in standard support, or one that left standard support less than six months ago.

Do you have to upgrade Odoo?

It depends on where Odoo runs. On Odoo Online, upgrades are mandatory on a schedule: major versions every two years, SaaS versions a few weeks after the next one ships, and Odoo runs the upgrade itself if you miss the due date. On Odoo.sh you get two more years after support ends. On-premise you can stay on a version indefinitely.

Staying is a choice with costs. After standard support, there are no security fixes unless you pay for extended support where it is offered. And Odoo's own advice holds: the smaller the gap between versions, the easier the upgrade. A database three versions behind is a harder job than three single-version upgrades done on time.

How does the Enterprise upgrade service work?

Through Odoo's upgrade platform. You ask for an upgraded test database, port any custom modules, test, report problems to Odoo, and only then upgrade production. Odoo Online uses the database manager, Odoo.sh runs it from a staging branch, and on-premise runs Odoo's upgrade script from the command line.

The steps, per Odoo's upgrade documentation:

1. Request an upgraded test database, from the upgrade page, the database manager, Odoo.sh or the command line.
2. Upgrade the source code of any custom modules for the target version.
3. Test the upgraded database thoroughly. Test databases are neutralised: scheduled actions, outgoing mail, real payment providers and bank sync are switched off.
4. Report issues to Odoo as an upgrade being tested, and request fresh test databases as you fix them.
5. Rehearse the full upgrade the day before, then upgrade production at a quiet time. The database is unavailable while it runs.

Two details matter on go-live day. On Odoo Online, once the production upgrade completes, you cannot go back to the previous version. On Odoo.sh, a failed upgrade is reverted automatically, and a successful one keeps a backup from before the upgrade. Either way, take your own backup first.

What about custom and third-party modules?

They are where the time goes. Odoo's service covers standard apps, Studio customisations while Studio and its subscription are active, and anything under a maintenance-of-customisations subscription. Modules written in-house or by third parties, Odoo partners included, are not covered. A database with custom modules cannot be upgraded until those modules exist for the target version.

So someone has to port each module: the person or firm that maintains it, your implementer, or a team you bring in. Odoo's documentation suggests doing it in parallel with the test upgrade, so the module code and the upgraded data meet in testing rather than on go-live day. Its guide to upgrading a customised database covers the steps: stop adding features to the old modules, port them, test them on an empty database, then on the upgraded copy of your data, and rehearse.

Odoo's upgrade service also does not cover cleaning old data and configuration, or training on the new version. Plan both.

How do you upgrade Odoo Community?

With OpenUpgrade, the Odoo Community Association's open-source project, because Odoo's own upgrade scripts serve Enterprise customers. OpenUpgrade moves a database one major version at a time, and each step needs the community to have covered your modules for that version. Check its coverage before you plan dates.

As of 29 October 2026, OpenUpgrade's 19.0 branch covers the 18.0 to 19.0 step, and the 20.0 branch exists, but the project's tracking issue for the move to 20.0 was still open, with its groundwork in progress. Community users on 19.0 wanting 20.0 should wait or plan to contribute. Its issue tracker is also the best place to read about real failures, such as recent 19.0 reports on sale options and PoS data.

The practical shape of a Community upgrade:

• One version at a time, each with its own test run.
• Community modules from the OCA and the Apps store need their own port for each version.
• Your custom modules need porting exactly as on Enterprise.
• No vendor helpdesk behind the upgrade; the project's issues and your own team are the support.

What should you test before going live?

Everything your business does in a week. Odoo's own checklist starts with views that are deactivated in the test copy but active in production, then reports such as invoices and sales orders, website pages, creating and editing records, mail templates, translations, saved filters and exports. Then run a full end-to-end flow.

A useful end-to-end pass, following Odoo's example:

• Pick a product and compare it field by field between test and production.
• Buy it, receive it, and check the receiving route.
• Sell it, ship it, and check the delivery route.
• Validate the customer invoice, credit it, and compare the result with production.
• Check accounting reports, taxes, currencies, bank accounts and the fiscal year.
• Place an online order through your shop, if you have one.
• Check every integration: payment, shipping, bank feeds and any API connections to other systems.

Who does the work?

Three parties. Odoo upgrades the standard apps and Studio work on Enterprise. Whoever maintains each custom or third-party module ports it. You test and sign off. Name each one before you start, and the upgrade stops being a surprise.

That middle row is how we work on Odoo: porting custom modules and integrations, and helping your users through the change. New Odoo setups are on request.

When is moving better than upgrading?

Usually it isn't: most businesses on Odoo should upgrade on time and keep going. A move is worth costing when the same custom modules are re-ported every cycle and the bill keeps growing, when you are on Community with no upgrade path to your target version, or when an upgrade is due and the fit was poor anyway.

If that is you, ERPNext vs Odoo has the honest comparison, and the open-source ERP guide and the ERP roundup cover the wider field. Odoo to ERPNext shows what moves, with the steps in the Odoo to ERPNext migration guide. ERPNext has upgrades too; ERPNext v15 vs v16 shows what one involves.

Skimmable summary: upgrade on time if Odoo fits; cost a move only when module porting repeats every cycle or Community has no path.

Frequently asked questions