Moving Odoo Between Online, Odoo.sh and Self-Hosted

The three platforms differ in what they permit

The technical move is broadly the same in every direction. What differs is the constraint set at the destination, and that is what determines whether the move is easy or is actually a development project.

Odoo Online is the managed SaaS platform. Odoo runs it, upgrades it and backs it up. You cannot install custom modules or third-party apps, so customisation happens through configuration and Studio. This is the most constrained tier and the least work to operate.

Odoo.sh is Odoo's managed hosting for custom code. You get a Git-backed deployment with staging branches, custom modules are allowed, and Odoo still handles the infrastructure underneath. It is the middle position and the usual destination for a business that has outgrown Online.

Self-hosted is your infrastructure, your responsibility. Total control, including control of everything that can go wrong. It makes sense with real operational capability behind it and rarely makes sense without.

Direction determines difficulty

Moving outward, from Online towards Odoo.sh or self-hosted, is straightforward. The destination permits everything the source permitted, so the database restores and runs.

Moving inward is where projects fail. Odoo Online will not accept custom modules, so a database carrying them cannot simply be restored there. The functionality has to be removed, replaced by configuration, or rebuilt in Studio, and that is development work discovered during what was scoped as a hosting change.

Establish the direction first, and if it is inward, inventory the custom modules before agreeing a date. The same module inventory that drives an upgrade estimate drives this one.

What actually transfers

The database dump carries the records. The part people forget is the filestore, which holds attachments, uploaded documents, product images and report archives as files rather than rows.

A restore without the filestore looks successful. Records are all present, screens load, counts match. Then somebody opens an invoice PDF from last year and it is gone. Confirm the filestore is included and check a handful of attachments open after the restore, because this failure is silent at exactly the moment you would want it to be loud.

Beyond the database, these travel separately and each needs its own step: the domain and DNS, the SSL certificate, outbound and inbound email configuration, any scheduled jobs outside Odoo, and every integration endpoint pointing at the old URL.

That last one is a checklist rather than a task. Payment providers, shipping carriers, webhooks and internal scripts all hold your address, and none of them will tell you they are still using the old one.

Take the version with you unchanged

Restore the same version you left on. Confirm the new platform behaves identically. Then upgrade separately, later.

Combining them is tempting because both need downtime, and it is the reliable way to make a small project into a confusing one. When a report comes out wrong after a combined move, the cause is either the platform or the version, and telling them apart means unpicking both. Kept separate, each move has a single explanation for anything that changes.

Plan the responsibility transfer, not just the data

This is the part that gets left out, and it is the part that matters six months later.

On Odoo Online, backups happen whether or not anyone remembers. On your own server they happen because somebody configured them, and are useful because somebody tested a restore. The same applies to security patching, monitoring, capacity, and knowing who is called when it stops.

Before the move, name the owner of each of those. If the honest answer is "we assumed it was handled", the move is not ready, and the failure will not show up during the cutover. It shows up the first time you need a backup that nobody verified.

Cut over like any other migration

The mechanics are familiar: a freeze window during which nobody writes to the old system, a restore, verification, then users. Announce the freeze, verify it held, and keep the old instance running and reachable until you are certain, because the old platform staying available is what your rollback plan depends on.

Run the validation checks after the restore rather than assuming a dump and restore is lossless. It usually is. The point of checking is the case where it was not, and attachments are the usual place that shows.