Skip to main content

Upgrade to a New Odoo Version

Skysize does not run the upgrade itself. You upgrade a copy of your database with an upgrade tool, port your custom code, then import the result into your branch. This guide covers the path from your current version to the next one, tested on staging first.

:::danger Do not change the Odoo Version field to upgrade Changing Odoo Version in a branch's Core Settings does not upgrade the database. It tears the deployment down and starts a fresh install with a new, empty database. :::

1. Choose an upgrade tool​

EditionToolHow it works
EnterpriseOdoo Upgrade serviceYou send Odoo a dump and get an upgraded dump back. It needs a valid Enterprise subscription.
CommunityOCA OpenUpgradeYou run the migration yourself, on your own machine, one version at a time. For example, 17.0 to 19.0 means running 17.0 to 18.0, then 18.0 to 19.0.

Check that the target version is available on Skysize: it must be in the Odoo Version list of your branch. A backup from a version the platform does not offer is refused at import.

2. Port your custom code​

Update your custom modules for the target version in a separate Git branch, and add any new Python packages to requirements.txt. Third-party modules need a version for the target as well.

If you have no custom code, skip to the next step.

3. Test on a staging branch​

  1. Create a backup copy of production: on the Deployments tab, click Download Backup, choose Exact database dump and With Filestore, then click Create Dump. When it is ready, download it from the Backups tab. See Manage Backups.
  2. Run the upgrade tool on this file. On the Odoo Upgrade service, request a test upgrade.
  3. Open the upgraded .zip and check its contents:
    • manifest.json shows the target version.
    • filestore/ is present. If it is missing, copy it in from the backup you downloaded.
  4. Point a staging branch at the Git branch with your ported code.
  5. Import the upgraded file into that staging branch. See Import an Existing Odoo Backup.

The import reads the version from manifest.json and switches the branch to it, so you do not need to change the version yourself. A restore into a staging branch is neutralized automatically, so it cannot send email or call live integrations.

Then test on staging:

  • Users can log in, and Apps shows the expected installed modules.
  • The runtime log has no missing module errors.
  • Attachments and PDF reports open.
  • Your main business flows work, especially anything that relies on custom code.

Fix any problem in your code, push, and repeat until the test is clean. A problem in the upgraded data itself goes back to the upgrade tool: rerun it, or contact Odoo for the Upgrade service.

4. Upgrade production​

Plan a maintenance window, because anything entered after the final backup is lost.

  1. Tell users the window has started and ask them to stop working in Odoo.
  2. Set Action on Code Update on the production branch to Do nothing, so that merging the ported code does not start a build on the old version.
  3. Merge the ported code into the production Git branch.
  4. Create a final dump as in step 3, with Exact database dump and With Filestore, and download it.
  5. Upgrade this file. On the Odoo Upgrade service, request a production upgrade this time: test upgrades are neutralized and must not go live.
  6. Import the upgraded file into the production branch. A production restore is not neutralized.
  7. Follow the progress with View Logs, then repeat the checks from step 3.
  8. Set Action on Code Update back to its previous value.

The current deployment keeps running during the restore, and is replaced only once the new one passes its health check. If the restore fails, production stays on the old version.

:::note Upload size limit Imports are limited to 2 GB per file on managed hosting. If your upgraded file is larger, contact support before the maintenance window. See Import an Existing Odoo Backup. :::

Go back to the old version​

Keep the final dump from step 4 until you are sure about the upgrade.

To go back, revert the code merge on the production Git branch, then import that dump into the production branch. The branch switches back to the old version automatically. Anything entered since the upgrade is lost.