All articles

How to migrate from Odoo.sh to Odoo Cloud

A step-by-step move from Odoo.sh: download a backup, connect the same GitHub repository, rehearse the import on staging, import production, move your custom domain and register the Enterprise code.

By Odoo Cloud · Published 25 September 2026 · 8 min read · Odoo.sh, Migration, Enterprise

Moving an Odoo database between hosts sounds risky, but most of the work is preparation. Your code already lives in GitHub, and an Odoo backup is a standard format that any Odoo of the same version can restore. This guide covers the move from Odoo.sh to Odoo Cloud in the order we recommend, with a rehearsal on staging before production is touched.

Odoo and Odoo.sh are trademarks of Odoo S.A. Odoo Cloud is an independent service, not affiliated with or endorsed by Odoo S.A. Your Odoo subscription is a contract between you and Odoo S.A.; check its terms before you move.

Before you start

Gather four things:

1. The Odoo version of your production database, for example 17.0. The project on Odoo Cloud must use the same version: an import is refused when the versions differ. If you want to upgrade as well, move first and upgrade afterwards, or upgrade on Odoo.sh before you move.
2. The GitHub repository that Odoo.sh builds from, and the name of your production branch.
3. Your edition. Odoo.sh projects run Enterprise. On Odoo Cloud you tick Enterprise on the project, and the Enterprise apps are provided by the platform.
4. A quiet window for the final switch, when nobody needs to write to Odoo for an hour or two. For a small database it is much shorter, but plan for the upload time of your backup.

Also list what is connected to production from outside: payment providers, shipping connectors, incoming mail servers, bank synchronisation and any integrations of your own. You will check each one after the move.

Step 1: create the project

Create a project on Odoo Cloud linked to the same GitHub repository, on the same Odoo version, with Enterprise ticked. If your repository uses private submodules, add a deploy key in Settings → Submodules; Python dependencies listed in requirements.txt are installed on every build, as on Odoo.sh.

The first build of the production branch creates a fresh production database with your modules. It is only a placeholder: the import replaces it. Before going further, open the build log and check that every module was found and installed. A module that fails here will also fail after the import.

Step 2: download a backup from Odoo.sh

In Odoo.sh, open your production branch and its Backups tab, and download a backup that includes the filestore (attachments, images and documents are stored there, not in the database). The download is a zip with the database dump (dump.sql), the filestore folder and a manifest.json: the same format Odoo's own database manager produces.

If Odoo.sh offers a choice between a copy neutralized for testing and an exact dump, take the exact dump for the production import. A neutralized copy has outgoing mail and scheduled actions turned off, which is what you want on staging and not on production.

For the rehearsal in step 3 you can use today's backup; for the final switch in step 5 you will take a fresh one.

Step 3: rehearse on staging

Create a staging branch on Odoo Cloud (drag a branch onto the Staging stage, or push a new branch and move it). Then, in that branch's Backups tab, click Import database and upload the zip.

• Large files are uploaded in chunks, and an interrupted upload resumes where it stopped.
• Keep Neutralize ticked: the imported copy then catches every email and keeps scheduled actions off, so your customers never hear from the rehearsal.
• The import is a build of its own. Its progress and log are in the branch's History.

When it is done, click Connect and go through your usual checks: log in as a few users, open recent invoices and their attachments, run a report, and try the custom modules you rely on most. Emails that Odoo tries to send appear in the branch's Mails tab.

This rehearsal tells you how long the upload and restore take, which is the length of your final switch window.

Step 4: prepare the domain and email

Moving the domain is the part users notice, so prepare it before the switch.

Lower the DNS TTL of your Odoo hostname (for example erp.yourcompany.com) to a few minutes, a day ahead, so the change later spreads quickly.

Add the domain to the production branch in Settings → Custom domains. The dashboard shows the record to create:

Don't change the record yet: it still points at Odoo.sh. With Cloudflare, the record must be set to "DNS only", not proxied.

Outgoing email. Production sends through the platform's mail server. To send as your own domain without landing in spam, open Settings → Outgoing mail, enter your domain and add the SPF and DKIM records it shows. You can add them before the switch; they don't affect Odoo.sh. If your team used a mail server of its own, configured inside Odoo, it keeps being used after the import. If your aliases relied on email handling provided by Odoo.sh, plan how incoming mail will reach Odoo, for example with an incoming mail server configured in Odoo against your mailbox provider.

Step 5: the switch

On the day:

1. Tell your users that Odoo is read-only for the window, and stop work that writes to it.
2. On Odoo.sh, download a fresh backup of production, with the filestore.
3. On Odoo Cloud, open the production branch's Backups tab and Import database. Production's current database is backed up first and put back if the import fails.
4. When the import build is live, Connect and run the same checks as on staging.
5. Change the DNS record of your domain to the value shown in Settings → Custom domains, then click Check. The status goes from Waiting for DNS to Waiting for certificate to Active: a free Let's Encrypt certificate is issued automatically.
6. Star the domain as the primary one. It becomes Odoo's base URL (web.base.url), used in emails and links.

Production on Odoo Cloud sends real emails and runs scheduled actions, so don't leave Odoo.sh's production running in parallel once users are on the new address: both would send the same reminders and run the same jobs.

Step 6: register the Enterprise code

An Odoo.sh subscription includes Odoo's hosting. Before you move, talk to Odoo S.A. or your Odoo partner about the subscription you need for hosting outside Odoo.sh; only they can change your contract.

Once production is live on Odoo Cloud, register the subscription code inside Odoo, as you would on your own server: use the "Register your subscription" banner at the top of Odoo, or Odoo's Settings. The code is stored in the production database. You never give it to Odoo Cloud, and staging and development copies are neutralized, which removes the code, so they never count as another database of your subscription.

Without a registered code, production runs, but Odoo shows the database as unregistered and it expires after Odoo's grace period. Enterprise upgrades also need the code.

Step 7: after the move

In the first days, check:

• Backups. Production is backed up every day from now on. The Backups tab lists them, and the project's Status page shows whether offsite copies are configured.
• Integrations. Payment providers, shipping connectors and anything that calls back into Odoo, now on the new address.
• Monitoring. Turn on downtime alerts for yourself on the Status page; admins get them by default.
• Your team. Invite collaborators as admins, testers or developers. Push rights on the repository stay managed on GitHub.

Keep your last Odoo.sh backup somewhere safe until you are confident in the new setup, and cancel the Odoo.sh project only after that.

Common questions

Do I need to change my code? Usually not. The build uses the same repository, and the shell has the commands Odoo.sh users know, such as odoo-update and odoosh-restart. Paths that hard-code Odoo.sh's layout are the exception worth searching for.

Can the database be on an older version? Not for the import itself. Import it into a project on its own version, upgrade it there with the Upgrade tab, then move the upgraded backup, or upgrade first on Odoo.sh.

What if I only have a database dump? A plain SQL file (.sql) or a PostgreSQL custom-format dump (.dump) imports too, but has no filestore, so attachments would be missing.

If you want a hand planning the move, contact us with your Odoo version, the size of your database and the number of users. The Odoo.sh alternative page summarises the differences between the two platforms, and the pricing page shows what the hosting costs.