Upgrading to Odoo 19 from Odoo 16, 17 or 18

You can upgrade a database straight from Odoo 16, 17 or 18 to Odoo 19 in one jump; there is no need to stop at each version in between. Odoo's upgrade service converts the standard apps, their data and your Studio customisations. Your custom and third-party modules are not included: they must be ported to 19 by whoever maintains them before the upgrade can go live. The safe sequence is always the same: upgraded test copy, fixed modules, thorough testing, a full rehearsal, then production.

This is part 36 of our Odoo 19 guide. If you are still deciding whether to move now or wait for Odoo 20, read our decision guide first.

Why upgrade to Odoo 19 now

Support dates set the pace. Odoo gives each major version three years of standard support. Odoo 16 left standard support in September 2025. Odoo 17 is scheduled to leave it in September 2026, which is now. Odoo 18 runs to September 2027 and Odoo 19 to September 2028. Beyond standard support, Odoo.sh and on-premise customers can buy extended support for an extra fee; Odoo Online does not offer it and upgrades databases on its own schedule.

The smaller the version gap, the easier the upgrade. A jump from 16 to 19 is possible in one step, but it carries three years of changes to views, models and workflows, and your custom modules and your users both have to absorb all of them.

What Odoo's upgrade service does and does not cover

With an Enterprise subscription, upgrading to the latest version is included. Odoo's service-level agreement covers:

• all standard applications and their data;
• Studio customisations, as long as Studio is still installed and the subscription is active;
• customisations covered by a maintenance of customisations subscription.

It explicitly does not cover cleaning up existing data or configuration, upgrading in-house or third-party modules (including those written by Odoo partners) without a maintenance contract, or training your users. An upgrade also never changes edition or hosting: moving from Community to Enterprise, or from on-premise to Odoo Online, is a separate project.

Getting an upgraded test copy

You always start with a test upgrade. How you request it depends on hosting:

• Odoo Online: the database manager at odoo.com/my/databases, Manage, then Upgrade, with Purpose set to Test.
• Odoo.sh: request the upgrade on a staging branch. The latest daily production backup is upgraded and loaded, and every commit you push restores the upgraded copy and updates your custom modules, so you test against a clean copy each time.
• On-premise: run Odoo's upgrade script on the database server, or upload a dump at upgrade.odoo.com.

$ python <(curl -s https://upgrade.odoo.com/upgrade) test -d mydb -t 19.0
# later, for the real thing
$ python <(curl -s https://upgrade.odoo.com/upgrade) production -d mydb -t 19.0

On-premise, the database goes to Odoo without its filestore. What comes back is a dump.sql and a filestore folder of new files, which you must merge with your production filestore before restoring. Skip that and attachments go missing in the test copy. When the upgrade finishes, Odoo also sends an upgrade report, which is posted in Discuss for administrators. Read it; it lists what changed.

Test copies are neutralised: scheduled actions are disabled, outgoing mail servers are replaced with a fake one, payment providers and delivery carriers are switched to test mode, and bank synchronisation is off. That protects your customers, but it also means scheduled jobs and bank feeds must be tested deliberately.

What custom modules need for Odoo 19

Odoo's documented process for customised databases has six steps: stop development and challenge each customisation, request an upgraded database, make your modules install on an empty 19 database, make them work on the upgraded database, test and rehearse, then upgrade production. The first step is the one teams skip. Odoo 19 may now do natively what you built in 16, and removing a module is cheaper than porting it.

From reading the 19.0 source, these are the changes that break the most custom code coming from 16, 17 or 18:

• Contracts moved into Employees. The separate hr_contract module is gone; wage and contract dates now live on the hr.version model in the Employees app. Anything that extended contracts, including payroll customisations, needs rework.
• Product packagings removed. Packagings are now units of measure listed on the product's Packagings field. Code and imports that used product packagings need rewriting.
• User and group fields renamed. A user's groups are now group_ids, and groups are organised under the new res.groups.privilege model. Security XML and code that assigns groups usually needs updating.
• Controller and API changes. @route(type='json') is a deprecated alias for type='jsonrpc'. The external /xmlrpc, /xmlrpc/2 and /jsonrpc endpoints are deprecated; Odoo's documentation schedules their removal for Odoo 22 (fall 2028), with the JSON-2 API at /json/2 as the replacement. Integrations will keep working on 19, but plan the move.
• Platform minimums. Python 3.10 and PostgreSQL 13 at least. Coming from 16, check your server before anything else.

Every custom module you retire before an upgrade is one you never have to port, test or pay for again.

Testing the upgraded database and checking the data

Test with the people who do the work, not only the implementer. Run full flows end to end: a purchase received into stock and billed, a sale delivered, invoiced and paid, a credit note, a payroll run, a website order. Check that reports and email templates render, that your saved filters still exist, and that integrations and automated actions behave. Odoo's own checklist also asks whether any views active in production are deactivated in the test copy, which is a quick way to find broken customisations.

1. Freeze a reference date. Take figures from production at the moment the test dump was made.
2. Compare the finance numbers. Trial balance, receivable and payable ageing, bank balances, and for Indian companies GSTR-1 and GSTR-3B figures for the last closed period. They should match to the rupee.
3. Compare stock. Quantity on hand and inventory valuation per warehouse, and a sample of products checked against production: category, cost, routes, vendors.
4. Count the open work. Open quotations, sales and purchase orders, pending deliveries and receipts, unpaid invoices, active subscriptions.
5. Rehearse the whole go-live. Request a fresh test upgrade shortly before the date, repeat it end to end, and time it so you know how long production will be down.

On go-live day, production is unavailable while it upgrades, and on Odoo Online there is no reverting afterwards. Schedule it for a quiet period, never during month-end or a GST filing week, and tell users what will look different on Monday.

If you would like the whole upgrade handled for you, including porting custom modules and the data checks above, see our Odoo upgrade service. The final part of this guide, part 37, brings the whole series together.