Odoo upgrade: path, risks, testing and cutover

An Odoo upgrade moves your database and custom code from an older major version, such as 16 or 17, to a supported one. Odoo's upgrade service converts the standard data; your custom and third-party modules must be ported separately. A safe upgrade follows a fixed order: inventory the code, request a test upgrade, port and test on a copy, rehearse, then cut over production at a planned time with a rollback option.

Which Odoo versions are still supported?

Odoo supports every major version for three years of standard support; security updates are provided only in that period. The table below is taken from Odoo's standard and extended support page, checked on 20 October 2026.

According to the same page, you can upgrade to any major version still under standard support. Extended support for older versions exists, but it costs extra, does not include security updates and on Odoo.sh is limited to some versions.

What does the upgrade path look like?

What are the main migration risks?

Most upgrade problems are predictable once you know where to look:

• Removed or renamed fields and methods. Between Odoo 17 and 19, for example, the user groups field changed from groups_id to group_ids, group categories moved to a new res.groups.privilege model, and the product type field detailed_type was replaced by type plus an is_storable flag. Custom code and import templates that still use the old names fail.
• View changes. List views are declared with <list> instead of <tree> from Odoo 18, and Odoo 19 rejects some older search view structures. These errors stop a module from installing at all.
• Changed method signatures. Core methods such as the login check have different arguments in 17, 18 and 19. Overrides written for one version break silently or loudly on the next.
• Third-party add-ons. A module bought years ago may have no maintained version for the target release, or a version from a different author.
• Data surprises. Old records that violate new constraints, products without units, unreconciled entries that block the migration of accounting data.
• Integrations. External systems calling the API with old field names or old authentication.

Why test on a copy, and how?

All porting and testing happens on a copy of production that is neutralised before anyone logs in: outgoing mail servers and mail fetching are removed, scheduled jobs are reviewed, and the database gets its own identity, so the copy can never send an e-mail to a real customer or post to a real bank. Key users then test with their own data, not demo data. Automated tests of each custom module run on the target version, and I compare key reports, such as stock valuation and balances, between the old and the upgraded copy.

What experience do I bring?

I maintain my own Odoo modules on four versions, 16, 17, 18 and 19, with the same automated test suite passing on each version, which is exactly the discipline an upgrade needs. I also work with clients on Odoo 20. In client work I have ported custom modules from Odoo 16 to 17 and built new modules directly on Odoo 19 Enterprise. I start every upgrade with a health check of the custom code, because the module inventory decides the cost far more than the database size.

What does the cutover day look like?

Users stop working at an agreed time. A backup is taken and checked. The final upgrade runs, then the custom modules are updated and a short checklist of flows is tested by key users. If everything passes, the new version opens; if not, the old version is restored from the backup and nothing is lost. A written log of the day goes into your documentation.