Leaving Odoo.sh: the migration checklist, and what the platform did for you.
Your code is already in a git repository, usually in your company's own GitHub account, so the hard part of leaving Odoo.sh is the work the platform did quietly: builds, staging copies, mail, backups and settings. Here is what travels, what does not, and how the move runs.
Or call us: +1 515-644-1400, any time. How to start.
Allodi is run by Mark Kladivo in Des Moines, Iowa; his manufacturing company, Corn Belt Aluminum, is making the same move Allodi sells, to Odoo 19 Community on Hetzner with Backblaze backups. Read the case study.
What you already have
Your repository
Odoo.sh builds every branch from a GitHub repository. Usually it is in your company's own account; if a partner set up the project, check whose account it is in first. Your custom modules, the submodules that pull in OCA or third-party code, and the requirements.txt file with extra Python packages are all in it. Odoo.sh adds submodules to the addons path and installs those requirements for you; on your own server, the build does the same from the same files.
Your backups
Odoo.sh backs up production daily and, according to its documentation, keeps seven daily, four weekly and three monthly backups, each with the database dump and the filestore. You can download one from the Backups tab of the production branch. Odoo's own FAQ describes leaving the same way: download a dump and import it on your own Odoo server.
Your staging branches
On Odoo.sh a staging branch gets a neutralized copy of production, and staging databases are deleted after a month unless rebuilt. On your own server the branches stay in your repository, and Managed Odoo includes a staging copy on servers with 8 GB of memory or more: a neutralized copy of production on your server, refreshed when you ask. Updates and larger changes are tried on a neutralized copy of production first, and every deployment to production is approved by a person, from a branch you can read.
No intermediate-version trap
Odoo.sh runs major versions only, so an Odoo.sh database can move to your own server on the version it is on today. Odoo Online is different: see leaving Odoo Online.
What does not travel with the database
These are the things Odoo.sh set for you. None is hard, but each one has to be done on purpose, and each goes into your runbook as it is done.
| What | On Odoo.sh | On your own server |
|---|---|---|
| Outgoing mail | Works out of the box through Odoo's mail servers | An SMTP provider, plus SPF, DKIM and DMARC records for your domain |
| Incoming mail | Aliases and replies handled by the platform | A mailbox or forwarding for your aliases, and the catchall domain set in Odoo |
| Workers and limits | Set by your plan; more workers are bought through your account manager | Written into your Odoo configuration and sized for your server |
| Scheduled actions | Run by the platform, no more often than every five minutes | Reviewed before the first start, so no job runs twice during the move |
| Domain and certificate | Managed on the platform | DNS points to your server; the certificate is issued there |
| IP address | Can change, for example after a hardware failure or a move between servers | Your server's own public address, which suits banks, carriers and payment providers that allowlist IPs |
| Integrations | Webhooks and sign-in apps point at your Odoo.sh address | Payment webhooks, Google or Microsoft sign-in and carrier callbacks updated to the new address and tested |
| Enterprise subscription | Custom plan, plus separate Odoo.sh hosting fees | Custom plan, which covers self-hosting, if you keep Enterprise; the transfer is done with Odoo; no Odoo.sh fees |
The Odoo.sh migration checklist
Work through it in order. Everything in the first two columns can be done before you tell anyone you are leaving, and none of it changes your production database.
1. Code and build
- Check whose GitHub account the repository is in. Odoo.sh builds every branch from it; if a partner created the project, ask for the repository to be transferred to your company, or for admin access.
- List the submodules in
.gitmodules. Private ones are reached with deploy keys set in the project's Settings, under Submodules; your own server needs its own key for each. - Keep
requirements.txt: the extra Python packages Odoo.sh installs for you. - Note the Odoo version of the production branch, the database workers and the staging branches in the project's Settings, so the new server is sized from facts.
2. Settings that live outside the code
- Custom domains. Odoo.sh has you point them at the project with a CNAME record; write down each one and where its DNS is managed.
- Outgoing mail. Production mail on Odoo.sh is really sent, and Odoo's documentation asks you to authorize Odoo as a sending host in your SPF and DKIM records. On your own server, a mail provider takes its place and those records change.
- Scheduled actions: which run, how often, and which must not run twice during the move.
- Integrations: payment providers, carriers, bank connections and Google or Microsoft sign-in all point at your Odoo.sh address.
3. Backups
- Download a production backup from the Backups tab, with the filestore, and keep a copy in storage your company owns. The production server keeps one month of backups, seven daily and four weekly; Odoo's documentation says the three monthly ones sit on dedicated backup servers and are restored or downloaded through Odoo Support.
- Restore it on the new server as a neutralized copy, with mail, scheduled actions and payment providers switched off, and confirm every module loads.
- The Backups tab also takes a manual backup, which is how the final copy is made on cutover evening.
4. Cutover and after
- Parallel run: your team checks its own work on the copy, while changes on Odoo.sh are frozen so nothing is lost at cutover.
- Cutover evening: users stop, a manual backup is taken on Odoo.sh and restored, the domain records and mail are switched, and a go/no-go check runs before users start again.
- If you keep Enterprise, ask Odoo's support or your account manager to transfer the subscription to self-hosting on the Custom plan, and we set it up on the new server.
- Keep the Odoo.sh project available and unchanged for at least 30 days after cutover as a fallback, as your statement of work sets out. Then download one last backup for your records; cancelling the project is your decision.
Wondering whether the move pays? Our Odoo.sh vs self-hosted cost comparison uses Odoo.sh's published worker, storage and staging prices, and shows where Odoo.sh is the cheaper line.
How the move runs
The same steps as every migration, with the Odoo.sh details filled in.
-
Free scan and quote before you sign
The free scan counts your modules, Enterprise apps, users and customizations and gives a quote from the published prices, with project fees that are binding for what it counts. You run the scan yourself, or upload a backup, before you sign anything.
-
Inventory and plan within 10 business days of access
Once you have signed, we read your repository and settings, list every integration with you, and write the migration plan.
-
Your server and your bucket week 1
Your company opens a Hetzner Cloud project and a Backblaze account, and gives us access to both. Our step-by-step guides take about 35 minutes of your time in total.
-
Code and a backup week 1
You give read access to the repository, to the GitHub account name we send you, and download a production backup from the Backups tab into your bucket.
-
A neutralized copy weeks 1 to 2
The server is built from the same commit Odoo.sh runs, the backup is restored with mail, scheduled actions, payment providers and bank sync switched off, and we check that every module loads.
-
Plumbing and a parallel run one to four weeks, by size
Mail, domain and integrations are set up and documented. Your team works on the copy alongside Odoo.sh and reports anything that differs.
-
Cutover one evening
A final backup from Odoo.sh is restored, DNS and mail are switched, and a go/no-go checklist runs before users start again.
-
Handover within 30 days of cutover
You get the runbook, the integrations sheet and the credentials list. You keep the Odoo.sh project available and unchanged for at least 30 days after cutover as a fallback, as your statement of work sets out; after that, cancelling it is your decision.
The move is rescue and rehost: $750 per database, billed as $250 at signing, at cutover and at handover, plus $125 for each additional company in it. From cutover, Managed Odoo keeps it running.
Questions people ask
Do we lose our git history?
No. Your repository and its full history stay in your company's GitHub account, and the new server is built from the same repository. We ask for read access, and your branches stay as they are.
Do we have to leave Enterprise too?
No. Leaving Odoo.sh and leaving Enterprise are separate decisions. If you keep Enterprise, the subscription stays on Odoo's Custom plan, which covers self-hosting; Odoo's support or your account manager completes the transfer, and we set it up on the new server. If you want Community, we do that as its own step; see Enterprise to Community.
How long does the move take?
Usually two to six weeks from signing to cutover, depending on size, most of it a parallel run where your team checks its own work on the new server. The cutover itself is one evening.
How much downtime is there?
Users stop for the cutover evening: a final backup is taken on Odoo.sh, restored on the new server, and the domain and mail are switched. You pick the evening.
When should we cancel Odoo.sh?
Keep the Odoo.sh project available and unchanged for at least 30 days after cutover as a fallback, as your statement of work sets out. After that, cancelling it is your decision.
What about our Odoo version?
Odoo.sh runs major versions, so you move on the version you have. Upgrading is a separate project we do afterwards, never at the same time; see upgrading to Odoo 19.
Can we download our Odoo.sh backups?
Yes. The Backups tab of the production branch lists the backups kept on the production server and lets you download them and take a manual backup. Odoo's FAQ describes leaving the same way: download a dump and import it on your own Odoo server.
Is Odoo.sh cheaper than our own server?
For hosting alone, often yes for a small database. Your own server saves money mainly with Odoo Community, or when your own staff run it. Our cost comparison shows the arithmetic for three company sizes.
Sources, as of September 2026: Odoo.sh branches and backups (backups kept, Backups tab, staging databases deleted after one month), Odoo.sh FAQ (leaving with a database dump, IP address changes), Odoo.sh advanced (scheduled actions, submodules) (scheduled actions, submodules and requirements), Odoo.sh settings (workers) (extra workers through your account manager), Standard and extended support (Odoo.sh runs major versions only), Odoo pricing plans (Custom plan covers Odoo.sh and on-premise), Change hosting solution (subscription transfer when changing hosting). Odoo changes its terms and documentation from time to time; the linked pages are the current word.
Planning to leave Odoo.sh?
Enter your databases, companies and users for the price of the move and the monthly fee after it. Send it to us from the same page, or start the free scan today.
- Plans, add-ons and hourly rates are published; larger projects are quoted up front, and the project fees in the free scan's quote are binding for what the scan counts.
- On a move, the start milestone is refunded if your database cannot run on the new server, unless the cause is on your side or a third party refuses to release your data (conditions).
- Managed Odoo is month to month: thirty days' notice, no minimum term.
- Your server, code, backups and credentials are in your company's name.
Or call us: +1 515-644-1400, any time, or write to us. How to start.