Last updated: 2026-08-09
Last updated: August 9, 2026. You don't need Odoo 20 to exist yet to start preparing for it. Most of the real upgrade risk in any Odoo major version jump lives in your own customisations, not in Odoo's core code, and that work can start today on your Odoo 19 instance.
Audit your custom modules now
Before Odoo 20 is even installable, build a complete inventory of every custom module and every third-party app installed on your production instance. For each one, record: what it does, whether you have the source (not just the installed .zip), whether it's actively maintained, and how deeply it touches core models versus adding new, isolated ones. Modules that override core methods (_compute methods on sale.order, for example, rather than adding a new model) are historically the highest-risk category in any Odoo major upgrade, because core method signatures and internal behaviour can and do change between versions.
# Quick inventory command, run on your Odoo server
sudo -u odoo /opt/odoo/venv/bin/python3 /opt/odoo/odoo-bin shell -d your_db --no-http <<'EOF'
mods = env['ir.module.module'].search([('state', '=', 'installed')])
for m in mods:
print(m.name, '-', m.author, '-', m.latest_version)
EOFXML-RPC and API risk
If Odoo 20 does introduce a JSON-2 API as reported (unconfirmed, treat as directional), any integration relying on Odoo's classic XML-RPC endpoint (/xmlrpc/2/common, /xmlrpc/2/object) is worth reviewing now, not because XML-RPC is confirmed to be removed, Odoo has a long track record of maintaining backward compatibility on this specific interface, but because any integration you don't fully understand today is much harder to safely re-verify later under upgrade pressure. List every external system that talks to your Odoo instance: e-commerce platforms, accounting sync tools, custom scripts, BI connectors, and note exactly which API surface each one uses.
For each integration in that list, capture three things while you still have easy access to whoever built it: the exact endpoints or methods it calls, whether it authenticates via API key or username/password, and whether it has any retry or error-handling logic if a call format changes. Integrations built years ago by a contractor who's no longer reachable are the ones that cause real pain during an upgrade, not because the integration itself is fragile, but because nobody left behind understands what it actually depends on. Documenting this now, while the system is stable and nothing is on fire, is cheap. Reverse-engineering it during an upgrade window under time pressure is not.
Build a real staging strategy
The single most common upgrade failure we see is treating staging as an afterthought, a quick clone made the week of the planned cutover. A real staging strategy means:
- A staging environment that mirrors production configuration (same modules, same server specs where reasonably possible, same data volume via a recent production clone).
- Running the full upgrade path on staging first, and actually using the upgraded instance for a real testing period, not just confirming it boots.
- A written rollback plan with a tested restore procedure, verified before the production attempt, not assumed to work because it worked once before.
- Every custom module re-tested individually post-upgrade, not just "the app loaded without an error."
A detail people underestimate: the staging test period needs real users clicking through real workflows, not just an engineer confirming pages load. The upgrade issues that actually cause production incidents are usually workflow-level, a report that used to total correctly now shows a rounding difference, an automated action that fires at the wrong stage transition, a custom approval flow that silently stopped enforcing a required field, and those only surface when someone runs the actual day-to-day process, not when someone checks that the login page renders.
Why to wait for the first stable patch, not day one
Major version zero-day releases of any software, Odoo included, routinely carry rough edges that get fixed in the first patch cycle. Odoo's own release pattern historically shows meaningful fixes landing in the weeks immediately after a major version's initial availability. Planning your actual production upgrade window for after the first stable patch, rather than the unveiling date, is not overcaution, it is matching the real maturity curve of the software.
This is doubly true for a version like Odoo 20, where the headline features (the AI layer, the native MCP server) are new categories of functionality for Odoo, not incremental refinements of existing features. New categories of functionality tend to have more edge cases discovered in their first real-world usage than a refinement of something that's shipped for years. If your business isn't depending specifically on a day-one Odoo 20 feature, there's no upside to being an early adopter of the roughest build of the year.
Testing against a live database vs a snapshot
A detail worth getting right early: your staging upgrade rehearsal should run against a genuinely recent production data snapshot, not a stale one from months ago, and definitely not synthetic test data. Odoo upgrade issues frequently correlate with actual data shapes and volumes, a report performance problem that only shows up past a certain record count, a data-migration edge case triggered by a specific historical value pattern that only exists in real production records. Testing against thin or old data gives false confidence: the upgrade appears clean in staging, then surfaces real issues only once run against the actual scale and shape of production data during the real cutover. Refresh your staging snapshot close to the actual rehearsal date, and again close to the real cutover date if there's a meaningful gap between the two.
Documenting institutional knowledge before it's needed under pressure
Beyond the technical audit, upgrade planning is a good forcing function for capturing knowledge that otherwise lives only in one person's head. For each custom module and each integration, note not just what it does technically but why it exists, what business requirement it was built to satisfy, and who requested it originally. This matters because an upgrade sometimes surfaces a genuine question of whether an old customisation is still needed at all, core Odoo may have grown a native equivalent to something that was custom-built years ago on an older version, and knowing the original business reason lets you make that call correctly instead of blindly re-porting something that's no longer actually necessary.
What changes if you're currently on Odoo.sh
If your Odoo 19 instance runs on Odoo.sh rather than your own server, the module-audit and API-review steps above still apply exactly the same way, that work is about your customisations, not your hosting platform. What's different is the staging step: Odoo.sh gives you built-in staging branches, so a version upgrade rehearsal is a more native part of the workflow than it is on a self-managed VPS. If you're also considering a move off Odoo.sh around the same time as this upgrade, treat that as a separate project, see our Odoo.sh vs self-hosted comparison and our Odoo.sh migration guide. Combining a platform move with a major version upgrade in one change window multiplies risk for no real benefit, do them as two verified steps.
A realistic timeline
| Phase | When |
|---|---|
| Custom module audit | Now, independent of Odoo 20's release date |
| Integration/API surface review | Now |
| Staging environment build | Once Odoo 20 has a stable (non-master-branch) build available |
| Staging upgrade + full testing period | 2-6 weeks after stable build, depending on customisation depth |
| Production cutover | After the first stable patch release, with a rehearsed and tested rollback plan |
FAQ
Can I start upgrade prep before Odoo 20 has a stable release?
Yes, and you should. Module auditing and API surface review don't depend on Odoo 20 existing.
How long should staging testing run before a production cutover?
For a lightly customised instance, a few weeks is often enough. For a heavily customised instance with many integrations, budget longer, and don't compress it to meet an external date.
Is XML-RPC being removed in Odoo 20?
Not confirmed. A JSON-2 API is reported but single-sourced. Odoo has historically maintained XML-RPC compatibility across major versions; review your integrations as good practice, not because removal is confirmed.
Should we hire external help for the module audit or do it internally?
Either can work, the key requirement is that whoever does it actually understands both the business purpose and the technical implementation of each customisation, not just one or the other. An engineer with no context on why a module exists may correctly assess its technical risk but miss that it's actually dead code nobody uses anymore, and misses the opportunity to simplify rather than just re-port it.
What's the single most common mistake in Odoo major-version upgrade planning?
Starting the module audit and staging rehearsal too late, typically once the new version is already released and there's external pressure (an approaching end-of-support date on the old version, a specific feature someone wants urgently) driving the timeline. The prep work in this post has no dependency on Odoo 20 actually existing, starting it now removes that time pressure entirely by the time a real cutover decision needs to be made.
Sources: Odoo official documentation, Odoo GitHub repository.