Moving to another host

Your Odoo runs on your own server, and its backups lie in your own storage, so you can take it elsewhere at any time. This guide covers the move to a host calmo.cloud does not manage: what you take along, how to get it out when the filestore is large, and what to tidy up once the database runs in its new place.

If you only want to keep the server and stop using calmo.cloud, see What happens if you leave.

What you take along #

The archive is the standard Odoo backup format: a .zip with dump.sql, filestore/ and manifest.json, which Odoo's database manager and odoo db load restore on any host.

Before you start #

The new host needs:

• The same Odoo version, as Odoo Enterprise. calmo.cloud runs Enterprise, so your database has Enterprise modules installed. The Enterprise code comes with your Odoo subscription, not with the backup.
• PostgreSQL at least as new as the one on your calmo.cloud server. manifest.json in the archive names it as pg_version.
• The Python packages your addons need. On calmo.cloud they are installed from the external_dependencies in each addon's manifest.

Note down what the new host should match. The service page shows the Odoo source commits and the Python version, and the service's settings hold your extra Odoo configuration (see Managing services). manifest.json lists every installed module with its version.

Step 1: Decide how the addon code travels #

Every custom addon on calmo.cloud is deployed from a GitHub repository that belongs to you. That includes apps added from the Odoo App Store or as a ZIP, which were committed to your private repository. So the code is already yours, and cloning the repositories is enough. The Addons tab shows which repository and commit each deployed addon comes from.

If you would rather have exactly what is deployed, in one piece, let the backup carry it: switch on Include addon code when you create the backup in step 2. The archive then has an addons/ folder with one folder per deployed addon. Odoo ignores that folder when it restores the archive, so the archive stays a normal backup.

Step 2: Create the final backup #

1. Ask your users to stop working in Odoo, so nothing changes after the backup.
2. Check the service's Backup Settings: with Back up the database only switched on, the backup has no filestore. Switch it off for a complete archive, unless you copy the filestore yourself (see A very large filestore).
3. Open the Backups tab, click Create Backup and switch on Include addon code if you want the addons in the archive.

The archive is streamed from the server straight to your backup destination. Nothing is staged on the server's disk, so the server needs no free space for it, however large the filestore. The Contents column shows what the finished backup holds.

Step 3: Download the archive #

In the Backups tab, click Prepare Download on the backup. calmo.cloud puts the backup together into one archive, because its files are spread over the backups before it, and writes it to your backup destination. That takes a while for a large filestore; you get a notification when it is done. Then click Download. The link points straight at your storage and is valid for 60 minutes. The archive itself stays available for 72 hours.

For a large archive, download with a tool that can resume:

curl -L -C - -o backup.zip 'https://…the download link…'

A download that is still running when the link expires finishes normally. If the connection drops after that, click Download again for a new link and run the same command with it: curl continues where it stopped.

A very large filestore #

A backup can run for up to three hours and hold several hundred gigabytes. If your filestore is larger than that, or the upload to your storage is slow, move the filestore separately. Your server is yours, so you can copy the files directly:

1. Switch on Back up the database only in the service's Backup Settings.

2. Copy the filestore from the server to the new host while Odoo is still in use. This first pass moves the bulk of the data:

   rsync -a --info=progress2 \
     root@203.0.113.10:/data/aura/services/odoo/<service UUID>/volumes/odoo/data/filestore/<service UUID>/ \
     /var/lib/odoo/filestore/<database name>/
   

3. Ask your users to stop working, then create the backup as in step 2. It now contains the database (and the addon code, if you chose that) and is small.

4. When the backup has completed, run the same rsync command again. It only transfers what changed since the first pass.

The service UUID is the name of the service's folder under /data/aura/services/odoo/ on the server, and the db_name in the archive's manifest.json. The target path depends on the new host: the filestore belongs in filestore/<database name> inside Odoo's data directory.

Step 4: Restore on the new host #

How you restore depends on the new host. With Odoo's command line:

unzip backup.zip 'addons/*' -d /opt/odoo/custom   # only if the archive carries addon code
odoo db load --move <database name> backup.zip

• Put the addons on the new Odoo's addons path before the first start, and install their Python packages. A restored database expects every installed module to be there.
• --move keeps the database's UUID, which your Odoo Enterprise subscription is registered with. In Odoo's database manager, the same choice is This database was moved. Without it Odoo treats the database as a copy and gives it a new UUID.
• If you copied the filestore yourself, it has to be in place under the name of the new database before Odoo starts.

Other hosts take the same archive through their own import, for example Odoo's database manager at /web/database/manager.

Step 5: Clean up after the restore #

• Uninstall the havsh module. calmo.cloud installs this small companion module in every database to keep the panel's module list in sync. Its code is part of the calmo.cloud image and does not travel with you. Until it is uninstalled, Odoo logs module havsh: not installable, skipped on every start, which is harmless. In Apps, remove the Apps filter, search for havsh and uninstall it, or run this in odoo shell:

  env['ir.module.module'].search([('name', '=', 'havsh')]).button_immediate_uninstall()
  env.cr.commit()
  

• Set web.base.url. calmo.cloud set it to the service's address. Change it under Settings → Technical → System Parameters to the new address.

• Check everything that pointed at the old server: outgoing and incoming mail servers, scheduled actions that call external systems, integrations that allow a fixed IP address.

• Switch your domain. Point its DNS record at the new host. The platform domain of the service stays with calmo.cloud, so replace it wherever it was used.

• Replace what calmo.cloud did for you: scheduled backups, TLS certificates, redirects, monitoring and uptime checks do not move with the database.

Step 6: Wind down on calmo.cloud #

Keep the service on calmo.cloud stopped, not deleted, until the new instance has run without problems for a few days.

With the API or an AI assistant #

On a plan that includes the API, the same steps can be scripted: POST /api/service-odoo/{uuid}/create-backup takes include_addons, POST /api/service-odoo/{uuid}/backups/{backup}/prepare-download puts the backup together into one archive (poll the backup until its download_status is available), and GET /api/service-odoo/{uuid}/backups/{backup}/download-url returns the download link. An AI assistant connected through the MCP server uses create_backup, prepare_backup_download and get_backup_download_url for the same. See the API overview.

What's next? #