> ## Documentation Index
> Fetch the complete documentation index at: https://docs.doploy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Upgrading Odoo

> Move a production or staging database to a newer Odoo version from the Upgrade tab

# Upgrading Odoo

The **Upgrade** tab on a production or staging branch runs Odoo's official database upgrade and switches the instance to the new version in one operation. It uses the upgrade service at upgrade.odoo.com, so it requires an Odoo Enterprise subscription.

## Requirements

* **Odoo Enterprise.** Your project must have an Enterprise subscription code saved in Project Settings. Without it the tab shows "Odoo Enterprise required". See [Odoo Enterprise](/managing-odoo/odoo-enterprise).
* **Backup storage.** The pre-flight check verifies backup storage is configured. A production upgrade will not start without a pre-upgrade backup.
* **Role.** You need the owner, administrator or developer role on the project.
* **A production or staging branch.** Development branches do not have the Upgrade tab.
* **The feature enabled on your project.** Upgrades are rolled out per project. If you do not see the tab, contact [support@doploy.io](mailto:support@doploy.io).

The target version must be higher than the branch's current version. If the branch is already on the newest version doploy supports, the tab says so and there is nothing to do.

## Test mode and production mode

**Test mode** asks Odoo to upgrade a copy of your database. When the copy comes back, doploy replaces the instance's database with the upgraded copy and switches the instance to the new version. Your original data is kept in the pre-upgrade backup. On staging branches test mode is the only mode.

**Production mode** upgrades the database in place. The instance goes offline for the whole run. On production branches you choose between the two, and production mode asks you to confirm that you have already tested the upgrade on staging.

Run the upgrade in test mode on a staging branch as many times as you need. That is where you find out which custom modules break and fix them.

## What happens

1. **Preparing.** doploy creates a backup of the database. In production mode the upgrade is cancelled if this backup fails.
   When the target is 20.0 or newer and the instance's PostgreSQL container is not yet PostgreSQL 17 with pgvector (instances created on 15.0 to 18.0), doploy first moves the database to a new PostgreSQL 17 with pgvector container. The pre-flight check tells you when this will happen. The old data directory stays on the server until you delete it.
2. **Upgrading.** The Odoo container is stopped so nothing writes to the database. doploy downloads the official upgrade script and runs it against your PostgreSQL container. Odoo receives a dump, upgrades it, and returns it. This step can take from minutes to several hours depending on database size.
3. **Switching version.** doploy rebuilds the instance container from the target version's base image, updates the Odoo source and Enterprise addons to the target version, and starts the instance. The branch's Odoo version is updated to match.

The tab shows the current stage while it runs. You can cancel while the upgrade is still in the Preparing or Upgrading stage; after that it runs to completion.

## If it fails

Failed upgrades appear in **Upgrade History** with a message explaining where they stopped. If a pre-upgrade backup exists, a **Rollback** button restores it. Test-mode runs with a failed backup show a warning and have no rollback point.

Custom modules that do not install on the new version are the usual cause of a failed switch. Fix the module on a development branch, merge, and run the upgrade again.

## Before upgrading to 20.0

Odoo 20.0 has larger framework changes than the last few releases. Work through this list on staging before touching production:

1. Read the 20.0 section of [Supported Odoo Versions](/managing-odoo/supported-versions) for the API changes.
2. Search your modules for `security/ir.model.access.csv` files and `model="ir.rule"` records. Each one needs converting to `security/ir.access.csv`.
3. Search your JavaScript for `this.props`, `t-ref`, `onWillUpdateProps` and `static defaultProps`. These are OWL 3 changes.
4. Search your Python for `api.Self`, `registry.clear_cache` and list-valued `_rec_names_search`.
5. Check whether any module you depend on was folded into core or renamed in 20.0 (for example `base_vat` and `base_iban` are now part of `base`, `stock_picking_batch` is part of `stock`).
6. Run the upgrade in test mode on staging, install your modules, and click through the workflows your users rely on.
7. Only then run the production upgrade, with a maintenance window sized for the time the staging run took.