Skip to main content
Ready to deploy? Start Free Trial

Documentation Help & reference

Migrating from Odoo.sh

How a move from Odoo.sh works: what our team does, what you provide, what carries over and what changes, and what to set up afterwards.

Updated 10/20/2026

How the move works

A move from Odoo.sh is done together with our team: you can't upload an Odoo.sh backup in the dashboard yourself. Your Odoo.sh project keeps running the whole time, and nothing changes for your users until you point your domain at the new app.

  1. Assessment. You share an Odoo.sh backup, or give us temporary access to the project. We look at the Odoo version, the modules, the size of the filestore and any custom modules.
  2. Restore. We create the app in your workspace, on your server, and restore the database and the filestore into it.
  3. Verification. You sign in to the new app at its own address and check the flows that matter to you: signing in, sales and purchases, reports, automations. Odoo.sh is still your live system while you do.
  4. Cutover. You point your domain's DNS record at the new app. Keep the Odoo.sh project for a day or two afterwards, as your way back.

To start, tell us about your Odoo.sh setup. The migration page has the details of the offer.

What you provide

  • The Odoo.sh project and the branch to move, production or staging.
  • An Odoo.sh backup (the ZIP with the database and the filestore), or temporary access to the project.
  • Your Git repository connected to CloudWady, through the GitHub App or a Personal Access Token, so your custom modules install from it as they did on Odoo.sh.
  • A workspace with a project on a plan, and a server for the app: one you already have, or one created through your connected cloud provider.
  • Access to your domain's DNS, for the cutover.
  • Someone who can answer questions about your customizations during the assessment, and a short window for the cutover.

What carries over

  • The whole database: your records, users, access rights, multi-company setup, scheduled actions, automations and translations.
  • The filestore: attachments, signed documents and images.
  • Your modules, installed from your own repository; nothing is rewritten.

What changes

  • Outgoing email. Mail servers set up in your database move with it. If you used Odoo.sh's own mail service, set up your own SMTP provider before the cutover.
  • Branches and environments. Odoo.sh's branches become CloudWady environments, Production, Staging and Development, and each app follows the branches you choose for it.
  • Shell access. Instead of the Odoo.sh shell you get terminal and SSH access to your server, according to your access level, and root with your own SSH key.
  • Versions. The app keeps the Odoo version it had on Odoo.sh. Upgrading to a newer Odoo version is a separate engagement, after the move: moving first and upgrading second keeps each step easy to check.

After the move

  • A staging copy. In a staging environment, Build → Build gives an app a neutralized copy of the production database, to try changes on real data. See Deployments & rollback.
  • Restore points. Every change to the app records a restore point first, so you can roll back the code, the data or both.
  • Backups off the server. Turn on Auto Backup and connect a storage, so every backup also has a copy away from the server. See Backups & restore.

Was this page helpful?

Your answer helps us prioritize documentation improvements.

Thanks — your feedback helps us improve.