Odoo 20 Upgrade Checklist: What Breaks and How to Test Before You Commit

Before you upgrade production to Odoo 20, restore your backup, upgrade a copy of your own database, and test custom code, money and stock flows, access rights and integrations with the people who use them. Go live only when no critical defect is open. This Odoo 20 upgrade checklist is for business owners, IT managers and ERP administrators who have custom modules or connected tools and need to decide whether, and when, to commit. If you would rather have specialists review those first, Odiware's Odoo migration services cover version upgrades, custom module migration and integration migration.

Odoo 20 was released in September 2026, and Odoo's supported versions page lists planned standard support until September 2029. This guide covers testing and the go-live decision. For the wider migration process from Odoo 19, see Odiware's Odoo 19 to 20 migration guide.

Quick checklist: eight readiness gates

• [ ] A backup of the database and filestore has been restored on a separate machine.
• [ ] Self-hosted servers run Python 3.12 or later and PostgreSQL 16 or later.
• [ ] Every custom module and third-party app has an owner and an Odoo 20 version.
• [ ] Custom modules install on an empty Odoo 20 database and on the upgraded copy.
• [ ] The core sales, purchase, inventory and accounting cases match saved baselines.
• [ ] Every user role has been tested for access.
• [ ] Integrations and scripts work in sandboxes, and none relies on the removed RPC db service.
• [ ] Each department has signed off in writing, no S1 defect is open, and every S2 defect has a tested workaround.

The sections below show how to prove each gate, rate what you find and make the final call.

How to test an Odoo upgrade before production: what a test copy can and cannot prove

Odoo's upgrade documentation sets out the sequence: request an upgraded test database, test it, report problems, and only then upgrade production. Test databases are neutralized so they cannot affect production. According to the documentation:

• Scheduled actions are disabled.
• Outgoing mail servers are archived and replaced with a fake one.
• Payment providers and delivery carriers are reset to their test environment.
• Bank synchronization is disabled. To test it, ask your synchronization provider for sandbox credentials.

A clean test copy therefore proves that your data, views, documents and business logic survive the upgrade. It does not prove that live mail, scheduled jobs, payment gateways, carriers or bank feeds work. Those need their own check right after go-live, covered below.

Two further points from the documentation. First, read the upgrade report: it is attached to the completion email and available in the Discuss app to users in the Administration / Settings group, and Odoo's guide for customized databases notes that views which cause problems are disabled during the upgrade and listed there. Second, request fresh test databases as work continues, because upgrade scripts and your own data keep changing. Never test in production, and never point a test copy at real customers or live accounts.

Odoo 20 upgrade checklist: before you request a test database

Each item names the evidence that proves it is done.

Environment and recovery

• [ ] Version, edition and hosting type recorded. Evidence: one-page environment sheet.
• [ ] Self-hosted only: servers meet the Odoo 20 minimums of Python 3.12 and PostgreSQL 16, per Odoo's source install guide. Evidence: version output from each server.
• [ ] Full backup of the database and filestore, copied off the server and restored on a separate machine. Evidence: a recent transaction and an opened attachment on the restored copy.

Custom module compatibility and third-party apps

• [ ] Every custom module and third-party app listed with its owner, source repository and Odoo 20 status. Evidence: vendor reply or release page for each app.
• [ ] Custom development frozen, apart from bug fixes. Odoo's guide for upgrading a customized database recommends this because every change after the upgrade starts must be upgraded and retested.
• [ ] Each custom module installs cleanly on an empty Odoo 20 database before you work on the upgraded copy, as that guide recommends.
• [ ] Studio customizations listed. They are not custom modules, but they touch standard views and models.

Integrations and baselines

• [ ] Every integration listed with its owner, credential location and sandbox.
• [ ] Scripts that create, duplicate, list or drop databases over RPC identified (see the Odoo 20 changes below).
• [ ] Baseline reports saved from the current system: trial balance, aged receivables and payables, tax report and stock valuation for a fixed date.
• [ ] Test owners named per department, and the severity rules agreed in writing.

What breaks in an Odoo upgrade, and how to find it

Most failures cluster where your setup departs from standard Odoo. The table lists general upgrade risks, not confirmed Odoo 20 breaking changes.

Odoo 20 changes that Odoo documents

These are specific to Odoo 20, with their sources, and each one turns into a test.

• Server software. Odoo 20 requires Python 3.12 or later, up from 3.10, and PostgreSQL 16 or later, up from 13 (source install guide). Custom code written for older Python versions needs its own check.
• RPC database service. The db service of the XML-RPC and JSON-RPC APIs was removed in Odoo 20. The common and object services are deprecated and scheduled for removal in Odoo 22 (fall 2028), with the JSON-2 API as the replacement (external RPC API page). Backup, provisioning or test-environment scripts that call db are the ones to find.
• ORM changes for custom code. The ORM changelog for 20.0 lists a changed RPC format for binary fields and the removal of Model._table_query. Integrations that move files and custom reporting models that use that method should be tested.
• Access rules. The same changelog lists a new ir.access model that merges access control lists and record rules, introduced in Odoo Online 19.4, the release before Odoo 20.0. If your custom modules define their own security rules, review them and test every role.

Who is responsible for what

Decide ownership before testing, because it decides who fixes what. Odoo's documentation is direct on three points. A database with custom modules cannot be upgraded until a version of those modules exists for the target version of Odoo. Differences in standard views, features, fields and models cannot be reverted case by case. And if a new version breaks a customization, making it compatible is the responsibility of the maintainer of that custom module.

For Odoo Enterprise databases, the documentation describes upgrade services that cover standard applications, Studio customizations and customizations under a maintenance subscription. It lists data cleaning, in-house or third-party modules without a maintenance contract, and training as not included, and notes that the Enterprise Subscription Agreement governs. Modules that nobody maintains are the usual point where businesses look for outside help, for example from an Odoo customization team that can update them for Odoo 20.

Rate every defect: a four-level severity framework

Rate every finding the same way. Without a rule, teams argue case by case under deadline pressure.

Re-rate a defect when the facts change: a "cosmetic" layout problem on a legal tax invoice may be S1. Problems in standard apps found in the test copy can be reported to Odoo through its support page, as the documentation describes.

Odoo upgrade test cases with pass/fail criteria

These 15 cases are an example set built from common business scenarios, not results from any client project. Replace the generic scenarios with your own products, taxes, roles and connectors, and run each one on the current version first to get a baseline.

Three end-to-end scenarios (examples)

These examples string tests into realistic flows. They are illustrations, not client case studies.

Scenario 1: Quote-to-cash with a partial delivery and a credit note

1. Create a quotation for a stocked product with a customer discount and tax, then confirm it.
2. Deliver part of the order, leaving a backorder. Invoice the delivered quantity.
3. Register a payment. Issue a credit note for one returned unit and process the return.
4. Run the receivables report and the stock valuation for that customer and product.

It proves that sales, stock and accounting stay linked. Fail signals: a wrong backorder quantity, a credit note whose tax differs from the invoice's, or valuation that does not move with the return. Wrong money or stock is S1.

Scenario 2: Procure-to-pay in a foreign currency

1. Raise a purchase order in a foreign currency above your approval threshold.
2. Approve it as the manager role, then receive part of it.
3. Create the vendor bill from the receipt, post it, pay it and reconcile.
4. Compare the booked amounts and exchange differences with a similar transaction on the current version.

It proves approval rules, currency handling and payables. Fail signals: a skipped or misdirected approval, a bill that cannot be matched to the receipt, or exchange differences posted to a different account. Treat a ledger difference as S1 and a missed approval as S2 or higher.

Scenario 3: Web order to shipped parcel, with a partial refund

1. Place an order in your web store's sandbox and pay with the gateway's test credentials.
2. Confirm that exactly one order and one payment arrive in the Odoo test database.
3. Create the delivery, generate a label with the carrier sandbox and check that tracking returns to Odoo.
4. Refund part of the order and confirm the credit note and the gateway status.

It proves the integration chain, not only each connection. Fail signals: duplicate orders, a paid order left unpaid, missing tracking, or a refund that updates only one side. Silent data loss is S2 at minimum and S1 if it affects revenue.

Data integrity and reconciliation

Reconcile instead of eyeballing. Compare record counts for partners, products, users and open documents with the source. Reconcile balances and stock values at a fixed date, and spot-check sample records field by field, in the way Odoo's own end-to-end example does: pick a product and a customer and compare their data in the test and production databases. Open attachments to confirm files came across. On-premise, the upgraded test database is delivered without your production filestore, so merge the filestores before judging attachments. The target is zero unexplained differences. Record any difference you explain, who explained it and who approved it. Finance should own this sign-off, not IT.

User acceptance testing

Have the people who do the work run their own tasks on the test database, using scripts you write with them.

1. Pick testers by role, including at least one person who handles exceptions such as returns and corrections.
2. Give each a short script covering daily and month-end tasks, with the expected result written down.
3. Capture evidence: screenshots or exported documents, not "looks fine."
4. Log each defect with a severity from the framework above.
5. Collect written sign-off per department, listing any accepted S2 items and their workarounds.

If your team lacks capacity for this, Odiware's Odoo testing services list functional, regression and user acceptance testing.

Go/no-go decision and go-live checklist

Go live only when every gate is met.

• [ ] Exit criteria: no open S1; each open S2 has a tested workaround and written business-owner approval; S3 and S4 are logged with owners.
• [ ] Rehearsal: the upgrade has been rehearsed in full the day before, which Odoo's documentation recommends, and a fresh test upgrade passed the same cases.
• [ ] Backup: a new database and filestore backup taken immediately before cutover, location recorded.
• [ ] Recovery plan: restore steps written and rehearsed, with a named person and a point at which you stop and recover.
• [ ] Approvals: business owner, finance and IT sign off in writing.
• [ ] Communication: staff and affected customers or vendors know the window and who to contact. Production is unavailable while its upgrade runs, so Odoo advises choosing a time of minimal use.

Recovery depends on hosting. According to Odoo's documentation, on Odoo Online it is impossible to revert to the previous version once the upgrade completes. On Odoo.sh the platform automatically reverts the upgrade if anything goes wrong, and creates a backup of the pre-upgrade database when it succeeds. On-premise, changes made to production after the database is uploaded are not present in the upgraded copy, so stop using the system during the upgrade.

Post-upgrade verification, before reopening to everyone. These are the checks a neutralized test copy could not make:

• [ ] Log in as several roles and confirm access.
• [ ] Process a test order and post a test invoice.
• [ ] Confirm outgoing and incoming mail work and that scheduled actions are running.
• [ ] Confirm payment providers and carriers are in live mode, and that bank synchronization works.
• [ ] Rerun the baseline reports and compare.
• [ ] Read the server and scheduled-action logs.

Keep the pre-upgrade backup at least until the first accounting period closes cleanly, and watch logs and support requests closely for the first days.

Frequently asked questions

Do we have to upgrade to Odoo 20 right now?

It depends on your hosting. Odoo's documentation says a database on Odoo Online that sits on a major version must be upgraded every two years, Odoo.sh databases get two further years after the initial three years of support, and on-premise databases can stay on the same version indefinitely, though that is not recommended. A smaller version gap generally makes the upgrade easier.

What if a custom module or third-party app has no Odoo 20 version yet?

The database cannot be upgraded with that module installed until a version exists for Odoo 20. Your options are to wait for the maintainer, commission the update, replace the feature with standard Odoo functionality, or retire it. Check what data the module holds before choosing, and test the outcome on a copy.

Do we need to test if we only use standard Odoo?

Yes, though the effort is lighter. Odoo recommends testing as many of your business flows as possible, because views, behavior and error messages can change even without custom code.

Can the changes to standard behavior be reversed if we do not like them?

No. Odoo's documentation says differences in standard views, features, fields and models cannot be reverted case by case. You can adapt your processes or, where a customization breaks, have its maintainer update it.

Conclusion: decide on evidence

If any gate in the quick checklist is not met, move the date, not the testing.

If your database has custom modules or integrations you are unsure about, Odiware offers a free migration assessment: share your current version and setup, and the team will outline risk and next steps.