How to Run a Test Migration to Odoo 20 Without Touching Production

An Odoo upgrade is one of the few operations you cannot undo: once a production database has been upgraded, there is no reverting to the previous version. Odoo's own documentation is blunt about the consequences of skipping the rehearsal — users who cannot adjust to changed behaviour, business interruptions, and a broken eCommerce checkout are the standard outcomes of going live untested. The alternative is neither expensive nor complicated. Odoo's upgrade platform will convert a copy of your database to Odoo 20, hand it back to you in a neutralized test environment, and let you break it as thoroughly as you like while production keeps running on 17, 18, or 19. This guide walks through that process end to end: how to obtain the test copy on each hosting type, what “neutralized” protects you from, and how to test so the rehearsal actually predicts the real thing.

Diagram of a production database copy flowing through an upgrade service into a neutralized test environment

The golden rule: production is never the test

Everything in this article follows from one principle: the upgraded database you experiment on must be a copy, running somewhere that cannot send a real email, charge a real card, or print a real shipping label. Odoo builds that safety in. Test databases obtained through the upgrade platform are neutralized — deliberately defused copies of your data. Your job is to request the copy the right way for your hosting type, test it like you mean it, and only then repeat the exercise with the purpose set to Production.

Step 0: Inventory before you touch anything

A test migration tests whatever you bring to it, so start with a list: every app in use, every Studio customization, every custom module, and every integration that talks to Odoo from outside. Two facts from the upgrade documentation shape the whole project. First, if your database contains custom modules, it cannot be upgraded until a version of those modules exists for the target version — Odoo's upgrade service covers standard applications and Studio customizations, not third-party or in-house code without a maintenance contract. Second, the smart way to run the project is in parallel: request the upgraded test database while your developers port the custom code, rather than waiting for one to finish before starting the other. Your inventory list becomes your test plan in the steps below.

Step 1: Get an upgraded test copy — three routes

Odoo Online

Open the database manager, select your database, and click Manage, then Upgrade in the Database section. Choose Odoo 20 as the target version, enter the email address that should receive the link, and leave the purpose set to Test — it is set that way automatically on a first request. When the conversion finishes, you receive an email with a link to the upgraded test database, which also appears in the database manager under your production database. You can request multiple test databases if you want to test more than once.

Odoo.sh

Fork your production branch into a staging branch, then use the branch's Upgrade tab: select Odoo 20 as the target version and click Test Upgrade. The platform sends the latest daily backup of your production database to the upgrade service, and the upgraded copy is downloaded back onto that staging branch. The staging branch then enters a special upgrade mode: every time a commit is pushed, the upgraded backup is restored and all custom modules are updated, which lets developers iterate quickly on module ports. The upgrade process log is available at ~/logs/upgrade.log in the staging build. Two cautions from the documentation: do not upload a backup from the Backups tab to the upgrade platform — download a proper dump instead (exact copy, without filestore) — and note that the special upgrade mode closes automatically after 30 days, so do not start it months before you intend to work.

Self-hosted (on-premise)

The same upgrade platform at upgrade.odoo.com serves self-hosted databases: you submit a dump of your database, select the testing purpose and the target version, and receive an upgraded dump in return, which you restore onto a separate test server — never over the production instance. If you have custom code, you choose whether Odoo upgrades it under a maintenance subscription or your own team handles the port. Either way, the mechanics mirror the cloud routes: a dump goes in, an upgraded copy comes back, and production is never in the room.

Step 2: Understand what “neutralized” means

When your test copy arrives, it looks exactly like production — same customers, same open invoices, same users. That fidelity is the point, and it is also the danger the neutralization step removes. Per the upgrade documentation, test databases are neutralized in four specific ways:

Scheduled actions are disabled, so no cron job fires a reminder, a reordering rule, or a subscription invoice from the test copy.
Outgoing mail servers are disabled — the existing ones are archived and replaced with a fake one — so testing an automated action cannot email your real customers.
Payment providers and delivery carriers are reset to their test environments, so a test checkout cannot charge a card or book a real shipment.
Bank synchronization is disabled; if you genuinely need to test it, you arrange sandbox credentials with your synchronization provider.

Verify the neutralization before you invite testers in, and brief them anyway: the test database contains real customer data, so it deserves the same access discipline as production, minus the ability to act on the outside world.

Step 3: Test like a user, not like an installer

The most common failure of a test migration is testing that the database opens rather than that the business runs. Work through your real flows end to end, ideally with the people who perform them daily. Odoo's basic checklist is a good skeleton: confirm your usual views display correctly and none were deactivated, generate your standard reports (invoice, sales order), create and modify records in each app, check mail templates, verify saved filters and exports still work, and compare a random product's full data — category, prices, cost, vendor, accounts, routes — between test and production.

Then extend the checklist to the seams, because that is where upgrades break: integrations with external software, cross-app workflows such as a lead becoming a sales order becoming a delivery, data exports, and automated actions — Odoo 20 can now trigger AI agents from automated actions, and your existing rules deserve a fresh look regardless. Given what changed in this release, add three targeted checks: post and reconcile a bank transaction (manual entries on bank accounts are no longer allowed), log in as a restricted user and confirm they see exactly the records they should (record rules were replaced by access-right domains), and run one complete POS or eCommerce order if you sell through either channel. Log every issue as you find it; problems found in testing are reported to Odoo under “An issue related to my future upgrade”, and problems in custom code go back to whoever maintains the module.

Step 4: Time it, then rehearse again before go-live

Your production database will be unavailable for the duration of its upgrade, so the test run doubles as a stopwatch: note how long the conversion and your testing took, and schedule the real upgrade in a quiet window sized accordingly. If your project stretches over weeks, request a fresh upgraded test database before committing — the upgrade scripts and your data both keep changing, and Odoo explicitly recommends fully rehearsing the upgrade process the day before upgrading production. The final production request is identical to the test request with one difference: the purpose is set to Production. Everything you practised — the dump, the wait, the verification — happens once more, this time for keeps.

Mistakes that defeat the purpose

Uploading a backup instead of a dump on Odoo.sh — backups are incompatible with the upgrade platform; use the Download Dump option.
Testing a stale copy — a test database requested in week one says little about production in week six; refresh before deciding.
Skipping the custom-module port — the upgrade cannot proceed until your modules exist for Odoo 20, so discovering this at go-live converts a delay into a crisis.
Letting the 30-day window lapse on Odoo.sh staging — the special upgrade mode closes automatically; time your start.
Testing only as administrator — access-right domains, like the record rules before them, only reveal their mistakes to restricted users.