Odoo Online vs Odoo.sh depends on the changes you need
Compare Odoo Online and Odoo.sh using required modules, integrations and maintenance ownership. Check the version constraints on a future hosting move.
Choose Odoo hosting after classifying the changes and integrations your business requires. Separate custom Python server code from supported configuration and importable XML/data modules before deciding which hosting options fit. Do not choose hosting from the word “customization” alone.
This guide concerns Odoo 19 Enterprise and the documented hosting boundaries checked September 22, 2026. Confirm the version, subscription and current vendor terms for the actual proposal.
Separate four kinds of change
Ask the implementer to classify each requested outcome before recommending a platform.
| Requirement type | Evidence to request | Hosting question |
|---|---|---|
| Standard application setting | Demonstration of the exact setting and result | Does standard configuration meet the requirement? |
| No-code configuration | Identified tool, required plan and maintained change | Is it supported in the proposed Online setup? |
| External integration | API requirement, connection owner and failure handling | Does the plan permit the required access? |
| Code or data module | Whether it uses Python server code or importable XML/data, plus dependencies and owner | Which supported deployment permits this specific module? |
Odoo's 19.0 importable-module tutorial explains that managed Odoo.com hosting does not allow custom Python server code. It separately documents defining models, fields and logic through importable XML/data modules. That does not make every module compatible with Online: the implementer must identify the module type, dependencies and deployment conditions in the proposal.
The Odoo.sh overview describes its cloud platform for hosting and managing Odoo applications, including module dependencies and continuous integration. Access to those tools does not assign someone to maintain your module. The delivery agreement still needs that responsibility.
Test whether custom code is actually necessary
Take one requirement that supposedly forces the hosting decision. Ask for the standard workflow first. Identify exactly where it fails the agreed acceptance case. Then compare a configuration, process change, integration or module against that gap.
For a fictional example, a company wants a purchasing review before a commitment is made. The phrase “custom approval” could refer to several different solutions. Ask who reviews which record, under what condition and what must be prevented. Demonstrate that requirement in the proposed applications before assuming a custom module is needed.
Do not remove an essential control merely to fit a cheaper hosting choice. Equally, do not accept ongoing code maintenance for a requirement that supported configuration already satisfies. Preserve the tradeoff in the decision record.
Compare the operating responsibility, not just the deployment button
For each viable option, identify who handles configuration, extensions, testing after updates, backups or restore requests, incidents and departures of the implementation partner. Ask how you obtain your source and data if the relationship ends.
Use one small release rehearsal where applicable: change a non-production setting or module, run its acceptance cases and show the route to a reviewed release. This is a proposed evaluation exercise, not a promise that every host or plan uses the same tools.
Commercial terms also matter. Odoo's plan comparison places external API access and the listed alternative hosting options under Custom and states that Odoo.sh hosting cost is separate. The Enterprise quote worksheet helps record those prerequisites without confusing them with implementation work.
Check the route out before committing
Hosting can change later, but the path has conditions. Odoo's 19.0 transfer guidance states that Online intermediary versions are not supported by Odoo.sh or on-premise, so a transfer may require moving to the next major version. Before a move to Online, have the implementer review each extension against the documented deployment boundary, including the distinction between Python server code and importable data modules.
Ask the implementer to record the current version, installed modules and any dependency that constrains a future move. “We can migrate later” is incomplete without those facts.
Finish the decision with a short requirement list, the tested solution for each requirement and the person responsible for maintaining it. Use the partner-selection guide to challenge that ownership. A hosting choice is ready when the required behavior and its ongoing responsibility fit the same proposal.