Leaving Odoo Online: the intermediate-version trap

Companies leave Odoo Online for many reasons: they want to install a module from the Apps Store or the OCA, they need their own custom code, they want direct database access for reporting, or they simply want the system on a server in their own name.

Code is a common trigger: Odoo's documentation says Online is incompatible with custom modules and Apps Store modules, and version 13 of Odoo's Enterprise subscription agreement (dated September 24, 2026) counts "Python-based customizations created in a database (e.g. with Odoo Studio)" used on Online as covered extra modules, charged a monthly fee per 100 lines of code.

The download button makes leaving look easy. For many Online databases, though, the move cannot happen yet, and the reason is not obvious until you try.

Two kinds of Odoo version

Odoo publishes major versions, such as 18.0, 19.0 and 20.0. These are the versions you can run anywhere: on your own server, on Odoo.sh, or with a hosting provider. Between majors, Odoo also releases intermediate versions for its Online service. Odoo's documentation describes them this way:

"SaaS versions (also called Online versions) are released every two to three months. They are only available on Odoo Online and are not eligible for extended support."

These appear as versions like 19.2, 19.3 or 19.4, and in technical places as saas~19.3. Odoo's support table marks them N/A for Odoo.sh and on-premise, which its legend defines as "Never released for this platform".

Odoo Online also moves databases forward on a schedule. The upgrade documentation says major upgrades on Online are mandatory every two years and minor (intermediate) upgrades become mandatory a few weeks after the next version is released, with an automatic upgrade if no action is taken before the due date. So an Online database spends much of its life on an intermediate version, often without anyone at the company having chosen one.

The trap

Odoo's hosting documentation is direct about what this means for leaving:

"Odoo Online's intermediary versions are not supported by Odoo.sh or on-premise. Therefore, if the database to transfer is running an intermediary version, it must be upgraded first to the next major version, waiting for its release if necessary."

Its example: a database on 16.3 would first have to be upgraded to 17.0. A database on 19.3 today cannot run on your own server until it has been upgraded to a major version on Online. Odoo 20.0 was released in September 2026, so for a database on any 19.x intermediate version the next major is 20.0; it cannot go back to 19.0.

Why not just run the intermediate code yourself? The Community source for the saas-* branches is public on GitHub, but the Enterprise side is not, and running that code yourself is unsupported. Restoring the database into the nearest major version is not a way out either: the database was made by newer code than that version, so you would be running a database that does not match its software.

How to tell which version you are on

• Look in the database manager on odoo.com and on the Settings screen inside Odoo. If you cannot find it, ask Odoo support which version your database runs; it is a routine question.
• A backup downloaded in Odoo's standard zip format includes a manifest.json with the Odoo version that made the backup and every installed module with its version. This is the most precise source, and the one a new host will look at.

A number with a minor part other than zero (18.3, saas~18.3) is an intermediate version. A number ending in .0 is a major one.

What to do while you wait

The wait is not wasted time. Almost everything that makes a move go smoothly can be done before the upgrade is possible, and doing it early means the move itself is short.

1. Download a backup and look inside it

A database administrator can download a backup zip from the database manager on odoo.com (for a very large database, Odoo support provides it on request). You cannot run it on a major version of Odoo yet, but you can still learn a lot from it. Odoo's standard backup zip holds a plain SQL dump, the filestore and the manifest. The SQL dump restores into an ordinary PostgreSQL server without Odoo at all, which gives you a private, read-only copy to query: how many records, which modules, which custom fields, how large the attachments are. None of this touches your live database.

2. Decide on the edition

Leaving Online changes the licensing conversation. Enterprise on your own server is sold under a different plan than Online, so check the current terms on Odoo's pricing page and with Odoo directly. The alternative is Community, with OCA modules covering some Enterprise features. That is a real project with gaps, not a switch, and it is worth deciding early because it changes what you test.

3. Inventory what you have customized

List every Studio field and view, automation rule, server action, scheduled action and installed app. On Online the list is usually shorter than on self-hosted systems, but Studio work accumulates. If you are moving to Community, Studio itself is an Enterprise app, so anything built with it needs a plan: keep it as data, rebuild it as a small module, or drop it. We wrote up read-only queries for a customization inventory that work on the restored copy from step 1.

4. Prepare everything that does not travel with the database

An Online database leans on services Odoo runs for you. On your own server you provide them:

• Mail. Outgoing SMTP, incoming mail for aliases and replies, the catchall domain, and SPF, DKIM and DMARC records for your domain.
• Domain and certificates. DNS for the new address, TLS certificates, and the web.base.url system parameter.
• Integrations. Payment provider webhooks, OAuth apps for Google or Microsoft sign-in and sync, shipping carriers, bank feeds. Each one points at an address that is about to change.
• In-app purchases. SMS credits, document digitization and similar IAP services are tied to the database and its account; check how each continues after the move.
• Backups and monitoring. On Online these happen without you. On your own server they need to exist, be offsite, and be restore-tested.

5. Build and test the target server

Set up the server for the major version you will land on, with the addons you plan to use. You can install a fresh database on it and rehearse mail, backups and integrations with test data, so that on move day the only new thing is your data.

6. Freeze new customizations

Every Studio change made on Online between now and the move is one more thing to verify afterwards. Agree internally to hold new ones until the move is done.

When the major version arrives

1. Request a test upgrade on Online. The upgrade flow in the database manager lets you choose the target version and asks for the purpose; the first request is a test. Odoo neutralizes test databases: scheduled actions off, outgoing mail replaced by a fake server, payment providers and carriers in test mode, bank sync off.
2. Test the upgraded copy with the people who use each area. Fix what breaks, on Online.
3. Upgrade production on Online to the major version.
4. Download it and restore it on your server as a neutralized copy (odoo-bin neutralize exists from Odoo 16 onward), and test again in parallel with the live system.
5. Cut over: stop users, take a final download, restore it, switch DNS and mail, check integrations, and open the doors.

Keep the move and any later upgrade separate. Arrive on your server on the same major version you left Online on, run there for a while, and upgrade later on your own schedule.

Where Odoo 20 fits

If your Online database is on 19.0 today, it can move now and land on 19, which is where we recommend running production while Odoo 20 settles. If it is on 19.1 to 19.4, its next major version is 20.0, so the move happens on 20.0 once the database has been upgraded to it on Online. Like every new major version, 20.0 will get a stream of fixes in its first months, so test that upgrade with the people who use each area before you plan the move.

A note for Odoo.sh users

Odoo.sh runs major versions only, so Odoo.sh projects do not hit this trap. Their move has other details (the repository, submodules and build settings), which our handover checklist and our page on leaving Odoo.sh cover. For what the destination looks like, see Odoo hosting on a server you own.

Everything else that changes when you leave Odoo Online, including mail, payment webhooks, single sign-on and the Enterprise plan, is on our page about migrating from Odoo Online to a server you own, and Odoo.sh vs self-hosted cost compares the monthly numbers.