How to migrate Odoo Online or Odoo.sh to self-hosted

The direct answer: Odoo officially supports downloading an Odoo Online backup or an Odoo.sh production backup and restoring it on-premise. That does not guarantee that any dump will run on any server. The destination must match the database’s exact supported major version, include its filestore and required addons, and use a legally compatible edition.

A rehearsal on isolated staging is mandatory for a responsible production move. Expect a write freeze and some service interruption during the final backup, restore, validation, and DNS switch; do not promise zero downtime.

Resolve version, edition, and license compatibility first

Read the database’s displayed version before provisioning anything. Odoo’s official hosting transfer guide says Odoo Online intermediary versions are unsupported on Odoo.sh and on-premise. A database on 16.3, for example, must first be upgraded to 17.0. For an Odoo 19.0 database, build a 19.0 target; a restore is not an in-place major-version upgrade.

Choose the destination edition deliberately. Moving Enterprise to self-hosted Enterprise still requires the matching proprietary Enterprise addons and, under Odoo’s official license terms, a valid Enterprise subscription for the correct number of users. Coordinate the subscription/database transfer with Odoo support, then register the on-premise database. Do not copy Enterprise code into an unlicensed installation.

Moving an Enterprise database to Community is a conversion project, not a simple restore. Enterprise modules, Studio output, fields, views, reports, accounting localizations, documents, helpdesk, sign, or other dependencies may block startup or leave unusable records. Inventory each dependency and remove it safely on a duplicate or replace it with tested Community-compatible functionality. Some conversions require data transformation and custom module work.

Map what the new server must reproduce

Export the installed-app list and record every custom, Enterprise, OCA, and third-party addon with its source repository, branch, commit or release, license, Python/system dependencies, and owner. Odoo Online does not accept custom code, but it can contain Studio customizations and Enterprise apps. Odoo.sh commonly has custom code in Git; preserve the repository, submodules, deployment settings, and exact production commit independently of the database backup.

Also inventory PostgreSQL and Odoo configuration, workers, memory, storage growth, PDF rendering, fonts, image processing, reverse proxy, TLS, object storage, payment and shipping callbacks, SSO, API clients, webhooks, SMTP, inbound mail aliases, catchall/bounce domains, scheduled actions, automated actions, and external secrets. Rotate secrets if they appeared in repositories or exported configuration.

Move from Odoo Online to self-hosted

1. Confirm the version. In the Online database manager, use the gear menu to see the version. Upgrade an intermediary release to the next supported major release before attempting the transfer.
2. Coordinate the subscription. If an active subscription is linked, contact Odoo support or your Customer Service Manager about transferring it.
3. Download the backup. Sign in to the Odoo Online database manager and choose Download. The ZIP is the transfer artifact. If the option is disabled or the file is too large, Odoo directs customers to Support for an alternative download.
4. Restore only to staging first. Install the exact Odoo release and all licensed dependencies, restore through the target database manager, and keep the database unreachable from public traffic while testing.

Do not delete the Online database after the first successful login. A login proves little about attachments, accounting totals, integrations, or workflows.

Move from Odoo.sh to self-hosted

1. Tag the deployed code. Record the production branch and commit, then reproduce its addons and dependency files on the target.
2. Create a production backup. In the production branch Backups tab, create or select a backup and download it with the filestore. Odoo’s branch documentation says production backups include the database dump and filestore; logs and sessions may also be present.
3. Keep code and data together. A database restored without the exact custom modules can fail registry loading. A filestore omitted or placed under the wrong database name produces missing attachments even when records exist.
4. Restore to isolated staging. Match Odoo, Enterprise, PostgreSQL compatibility, packages, fonts, and system libraries. Neutralize outbound effects before opening staging to testers.

Download the Git repository and deployment information separately; the database archive is not a replacement for source control. Preserve an Odoo.sh manual backup and do not terminate the project until the acceptance and fallback windows expire.

Build a neutralized target and prove the data

Block outgoing email, payment capture, SMS, webhooks, connector writes, and scheduled jobs on staging. Use a non-production hostname and restrict access. Test as representative users, not only as administrator.

Reconcile objective control totals between source and target: companies, active users, contacts, products, stock quantities and valuation, open sales and purchases, posted and draft invoices, receivables/payables, journal balances by account and period, payments, taxes, manufacturing orders, projects, subscriptions, attachments, and document counts. Sample old and new attachments, reports, translations, access rules, search, imports, exports, and multi-company isolation. Record expected totals and signed acceptance; screenshots alone are weak evidence.

Run at least one timed rehearsal from backup request through validated service. Measure dump generation, secure transfer, restore, module initialization, asset build, smoke tests, and DNS propagation. The result defines the real freeze window and rollback deadline.

Freeze, transfer, validate, then release

1. Announce scope, affected systems, freeze start, expected interruption, support channel, and go/no-go owner to every user and integration owner.
2. Lower DNS TTL well before cutover. Prepare TLS, proxy, monitoring, backups, firewall rules, and the final hostname without directing users there.
3. Stop user writes and integration traffic at the source. Pause cron and inbound processing. Confirm no background import or posting job remains active.
4. Create the final backup with filestore, checksum it, copy it through an encrypted channel, and retain an immutable copy.
5. Restore on the production target with the approved code and configuration. Keep outbound actions disabled during technical checks.
6. Run smoke tests and the agreed reconciliation controls. Verify mail routing, integrations, callbacks, cron ownership, domain, certificates, and permissions.
7. Make an explicit go/no-go decision. On go, switch DNS and enable integrations in a controlled sequence. On no-go, reopen the preserved source and communicate the rollback.
8. Tell users when access resumes, what changed, how to refresh DNS/browser state, what to verify, and where to report discrepancies.

Preserve the source without creating split-brain data

Keep the old Odoo Online or Odoo.sh environment, final backup, code revision, configuration record, checksums, and runbook for an agreed fallback period. After go-live, keep the source read-only or inaccessible to normal users: allowing transactions in both systems creates two competing truths that are difficult to merge.

Define rollback triggers before cutover—failed reconciliation, unavailable critical workflow, unacceptable corruption, or missed recovery-time objective—and identify who can invoke them. A rollback usually means stopping writes on the target, documenting any new transactions, restoring access to the frozen source, and handling the target-period delta explicitly. It is not a magic reverse sync.

Monitor business outcomes, not only server uptime

For the first hours and days, watch HTTP errors, Odoo and PostgreSQL logs, worker restarts, latency, CPU, memory, disk and filestore growth, backup completion and test restores, cron duration, mail queues, bounce/catchall behavior, webhook failures, payment and shipping callbacks, API rate errors, PDF generation, and certificate expiry. Re-run daily accounting, stock, order, invoice, and attachment controls until stable.

Hire experienced Odoo migration help when editions change, Studio or proprietary modules are present, accounting or regulated data is material, the database is large, custom Odoo.sh code lacks ownership, integrations cannot tolerate duplicate events, or the allowable outage is shorter than the measured rehearsal. Expertise should produce an assessed dependency map, rehearsal evidence, reconciliation report, cutover runbook, and rollback criteria—not an unsupported promise of direct portability.

Official Odoo 19 documentation

• Hosting: transferring Online and Odoo.sh databases
• Odoo Online database manager and backup download
• Odoo.sh branches, production backups, and filestore
• On-premise registration and neutralized duplicates
• Odoo 19 source installation
• Community, Enterprise, and proprietary licenses