Odoo 17 to 19 Upgrade Guide

Jumping two major versions, Odoo 17 to Odoo 19, is a bigger project than a single-version upgrade, but it is well within normal scope when planned properly. Here is what actually changes and how to run it safely.

Why go straight to 19 rather than 17 to 18 to 19

Odoo's own upgrade tooling (the upgrade.odoo.com service and the underlying upgrade scripts) supports jumping directly to the target version, it doesn't require stepping through every intermediate version manually. Going straight to 19 means one upgrade project and one round of custom module compatibility work, rather than two separate rounds if you stepped through 18 first. The exception: if you have a specific reason to validate behaviour at 18 first (a particularly high-risk customisation you want to de-risk incrementally), stepping through is a legitimate, more cautious choice, just a slower one.

What changes between 17 and 19 that actually affects upgrades

• ORM and ir.actions.server changes. Odoo's automated actions and server action framework has evolved across these versions; custom modules relying on specific internal method signatures in core models are the highest-risk category, review these first.
• Frontend framework updates. Odoo's OWL-based frontend continued maturing across 18 and 19; custom widgets or view extensions built against older frontend patterns need re-verification, not just a code compile check.
• Module manifest and dependency changes. Some core modules were renamed, merged, or restructured between major versions historically; a custom module's depends list needs re-checking against the 19.0 module list, not assumed unchanged.
• PostgreSQL version requirements. Confirm your target server's PostgreSQL version meets Odoo 19's minimum requirement; this is also a good moment to apply the tuning from our PostgreSQL tuning guide on the new server rather than carrying forward old, possibly outdated settings.

Custom module compatibility review

Before running any actual upgrade tooling, build the module inventory described in our upgrade planning guide (the same audit approach applies regardless of whether you're moving to 19 or eventually to 20). For each custom module, categorise it: pure new-model additions (lowest risk), view/report extensions (medium risk), and core-model method overrides (highest risk, needs line-by-line review against the target version's source).

Run this categorisation as an actual spreadsheet or tracked document, not just a mental note, on any instance with more than a handful of custom modules. For each module, record its risk category, the specific core methods it overrides if any, who on your team understands it well enough to review the diff, and its current test coverage if it has any. This turns what feels like an open-ended "test everything" task into a concrete, assignable checklist, and it's the single biggest factor in whether a two-version jump lands on schedule or drags on for months chasing regressions found one at a time in production.

The upgrade process

1. Take a full database and filestore backup of your Odoo 17 production instance (see our backup automation post if this isn't already in place).
2. Run the database through Odoo's official upgrade path to generate a 19.0-compatible database, on a copy, never directly against production.
3. Provision a staging server on Odoo 19 (our Ubuntu 24.04 install guide covers this from scratch).
4. Restore the upgraded database and filestore onto staging.
5. Install and test each custom module individually against the upgraded database, not just confirm they install without error, actually exercise their functionality.
6. Run a real testing period with actual users on staging, not just an engineer clicking through screens alone.
7. Only after staging is fully validated, schedule the production cutover with a tested rollback plan.

A realistic timeline

Phase	Typical duration
Module audit and compatibility review	3-5 days
Database upgrade + staging restore	1-2 days
Custom module fixes and re-testing	1-3 weeks, depending on customisation depth
User acceptance testing period	1-2 weeks
Production cutover	A single planned window, typically hours not days

A lightly customised instance can compress this to under two weeks total. A heavily customised instance with many integrations should budget six to eight weeks, and that is a realistic estimate, not padding.

Specific things that trip up a 17-to-19 jump

Beyond the general categories above, a few concrete patterns show up repeatedly in two-version jumps specifically:

• Report templates using deprecated QWeb syntax. Custom PDF report templates written against Odoo 17's QWeb conventions sometimes rely on helper methods or context variables that shifted by 19. These fail visibly (a broken or blank report), which makes them easier to catch than logic bugs, but budget time to fix each one individually rather than assuming a bulk find-and-replace covers it.
• Access rights and record rules on customised models. If custom modules added new models with their own security groups, re-verify those group definitions still apply as expected post-upgrade, security-relevant regressions are the category you most want to catch in staging, not in production.
• Third-party connector modules pinned to old Odoo version ranges. If you're using community modules from the Odoo Apps store for a specific integration (a payment gateway, a shipping carrier), confirm a 19.0-compatible version actually exists before starting the upgrade, not after, some smaller community modules lag behind Odoo's own release cadence by months.

Should you upgrade custom modules incrementally or all at once

For a small number of custom modules, testing and fixing them all together against the upgraded staging database is usually faster overall. For a large, complex set (dozens of interdependent custom modules), an incremental approach, upgrading and validating one functional area at a time, catches issues earlier and makes root-causing a regression much easier, since you're not trying to isolate one bug out of twenty simultaneous changes. There's no universally correct answer here, it scales with how many modules you have and how interdependent they are.

What to communicate to end users before cutover

The technical upgrade is only half the project. Odoo 19's interface and workflow changes from 17 in real, visible ways, not just under the hood, and users who aren't warned in advance treat every UI difference as a bug report rather than an expected change. A short internal briefing before cutover, covering what's visibly different and where to report genuine issues versus expected changes, meaningfully reduces the volume of "is this broken" tickets in the first week after go-live. This matters more on a two-version jump than a single-version one, since the cumulative visible difference between 17 and 19 is larger than between adjacent versions.

FAQ

Can I skip straight from 17 to 19 without going through 18?

Yes, Odoo's upgrade tooling supports this directly.

Will my custom modules just work after the upgrade?

Sometimes, for simple modules. Assume they need review and re-testing, not a guarantee, especially anything overriding core model methods.

How long should staging testing run before cutover?

At minimum one to two weeks of real usage, longer for heavily customised or business-critical instances.

What's the single biggest risk in a two-version jump specifically?

Core-model method overrides in custom code, by a clear margin. Anything that inherits and modifies core business logic (rather than adding new, isolated models) needs line-by-line review against the 19.0 source, not just a smoke test that the module installs.

Does the upgrade tooling cost anything?

Odoo's official database upgrade service has its own pricing and terms depending on your Odoo licensing status, check current terms directly on Odoo's own upgrade service pages rather than relying on a third-party summary, this changes over time and we don't want to publish a stale number here.

Should we upgrade Enterprise modules and custom modules in the same pass?

Yes, they need to be tested together regardless of how you sequence the actual upgrade steps, since custom modules frequently depend on or extend Enterprise module behaviour. Testing them in isolation from each other gives a false sense of confidence that doesn't hold once they're running together in production.

Sources: Odoo official documentation.