How to upgrade Odoo 18 to 19 safely with a staging copy

Why a major upgrade is different

Moving from 18.0 to 19.0 is not like applying a bug-fix release. Each major version changes models, fields and views. Some data moves between tables, some features are redesigned, and modules written for 18.0 will often fail to install or load on 19.0.

That means an upgrade has two separate tracks of work:

• The database. Your data has to be converted to the 19.0 structure by migration scripts.
• The code. Every custom, OCA or third-party module you use has to exist in a 19.0 version.

Both have to be ready before production can move. Most upgrade delays come from the second track, not the first.

Step 1: Take stock before you start

Start with a list of everything that is installed and everything that touches Odoo from outside:

• Modules. Export the list of installed apps and modules. Mark each one as standard, custom (written for you), OCA or bought from the Odoo Apps store.
• Unused modules. Uninstall what nobody uses. Every module you drop is one less module to port and test.
• Integrations. Note every system that talks to Odoo: e-commerce, payment providers, shipping, EDI, BI tools and scripts using the API. Each needs a test after the upgrade.
• Customizations. List Studio changes, custom reports, server actions and automated actions. These are easy to forget and often break quietly.

Step 2: Choose your migration path

Odoo Enterprise: Odoo's upgrade service

Enterprise customers use Odoo's upgrade platform (upgrade.odoo.com), including for self-hosted databases. Odoo's documentation describes the same two-stage process for each upgrade: you request a test upgrade, check the result, report problems, and only then request the production upgrade. For self-hosted databases there is a command-line script that sends a dump of your database to the platform and brings the upgraded copy back.

According to Odoo's documentation, the service covers standard apps and Studio customizations. It does not port custom modules written in-house or by a partner; that is your work, or your partner's (as of October 2026). Check the upgrade page in Odoo's documentation for your exact options before you plan.

Odoo Community: OpenUpgrade

Odoo's upgrade service is part of the Enterprise offer. Community databases are usually migrated with OpenUpgrade, an open-source project of the Odoo Community Association (OCA) that provides migration scripts between versions. Before you commit to a date, check the 19.0 branch of OpenUpgrade on GitHub: which modules it covers, and whether the OCA modules you depend on have 19.0 ports yet.

Not sure which edition fits you after the upgrade? Our Community vs Enterprise guide compares them.

Step 3: Port your custom modules

Create a 19.0 branch in each Git repository that holds your addons. Update the version in each module's manifest, fix code that uses APIs changed in 19.0, and update views, reports and tests. Then install the modules on an empty Odoo 19 database and run their tests before you try them on real data.

For OCA modules, check the 19.0 branch of each repository. For modules from the Odoo Apps store, check whether the vendor has released a 19.0 version. If a module has no 19.0 version and nobody plans one, now is the time to replace it or drop it.

With CloudPilot, custom modules come straight from Git: you connect a repository and branch on an instance, and it redeploys when you push. See Deploy custom modules from Git.

Step 4: Check the server requirements

Odoo's source installation guide for 19.0 lists Python 3.10 or later and PostgreSQL 13 or later (as of October 2026). An Odoo 18 server that was set up a while ago may not meet these, so check before you upgrade in place.

Odoo 20 raises the minimums again; see what Odoo 20 changes for hosting.

A cleaner approach is a new server for Odoo 19. You test on it without touching production, and the old server stays untouched as your fallback. Size it for at least the same load; our server sizing guide explains workers and RAM.

Step 5: Run a test upgrade on a copy

Never run the first upgrade against production. Work on a recent copy:

1. Take a fresh backup of production that includes the filestore. Our backup strategy guide explains why the filestore matters.
2. Upgrade the copy with Odoo's upgrade service or OpenUpgrade, as in step 2.
3. Restore the upgraded database on the Odoo 19 server.
4. Deploy the 19.0 branches of your custom modules and update them.
5. Make sure the copy cannot email customers or call live integrations before anyone logs in.

Expect the first test to surface problems: a module that fails to update, a view that no longer renders, a report with missing fields. Fix them, then run the test again on a newer copy. Repeat until a test upgrade goes through cleanly.

Step 6: Let real users test

Technical success is not the same as a working business. Ask one person from each team to run their daily tasks on the upgraded copy, with a written checklist:

• Create and confirm a quote, a sales order and an invoice.
• Receive and deliver stock, and check stock levels.
• Register a payment and reconcile a bank statement.
• Print the reports and documents you send to customers.
• Check that integrations and scheduled jobs behave as expected.
• Compare key numbers with production: open invoices, stock value, account balances.

Ask users to note anything that looks different, not only what is broken. Version 19 moves some menus and screens, and a short note to staff before go-live saves many support questions afterwards.

Step 7: Cut over with a rollback plan

When tests pass and users have signed off, plan the production move:

1. Pick a quiet window and tell users when Odoo will be unavailable.
2. Freeze data entry on Odoo 18 and take a final backup, including the filestore. Download a copy and keep it somewhere safe.
3. Run the production upgrade on that final backup, the same way as your last successful test.
4. Restore and deploy on the Odoo 19 server, then run a short smoke test from your checklist.
5. Switch your domain to the new server and reopen access.

Agree in advance on what would make you roll back, and who decides. If something serious goes wrong in the first hours, pointing the domain back to the untouched Odoo 18 server is quick. Once users start entering data on 19, rolling back gets harder, because that new data would need re-entering. Keep the old server and the final backup for a few weeks anyway.

How CloudPilot helps with the upgrade

CloudPilot does not migrate the database itself; that is the job of Odoo's upgrade service or OpenUpgrade. It takes care of the hosting work around it, on servers in your own cloud account:

• A server per version. Each CloudPilot server runs one Odoo version, 18, 19 or 20, so you add an Odoo 19 server next to your Odoo 18 one and keep both running during the project. Pro and Business include unlimited servers.
• Backups in Odoo's standard format. Download a backup of production with the database and filestore at any time, ready for the upgrade.
• Instances from a backup. Create an instance from the upgraded database on the Odoo 19 server, and check it on its free subdomain before your real domain points to it.
• Staging on Odoo 18. Clone production into a staging copy with outgoing email and scheduled actions neutralised, to clean up data and uninstall unused modules safely before the upgrade. Read the staging docs.
• Domain switch. Move your custom domain to the new instance, with HTTPS issued automatically once DNS points to the new server.

Staging is part of the Pro and Business plans. See pricing for what each plan includes.

If you would rather not manage servers or upgrades at all, Odoo's own hosting may suit you better: on Odoo Online, Odoo S.A. runs the platform for you. Our CloudPilot vs Odoo.sh comparison covers the trade-offs of each approach.

Staging copies for upgrade rehearsals come with managed Odoo hosting on every plan. Odoo's own process is in its upgrade documentation.

Frequently asked questions