Odoo Online, Odoo.sh, or on-premise: how to choose

Begin with the requirements that rule options in or out

Write down your required modules, external connections, availability expectations, data-handling constraints, and ability to operate infrastructure. Distinguish configuration from custom server-side code. Odoo Online does not support non-standard applications, which makes this distinction important before you commit.

The plan and the hosting platform are connected decisions. Ask the vendor to confirm your proposed combination, including external API use and any third-party modules. Keep that confirmation with your architecture notes so a later project does not rely on an assumption.

Compare operational responsibilities

• Odoo Online: assess whether supported standard workflows meet the scope and review the cloud service terms.
• Odoo.sh: evaluate custom-code deployment needs, environments, hosting charges, and who maintains the application code.
• On-premise: name owners for infrastructure, patching, monitoring, availability, backups, restores, and application maintenance.
• Every option: document user access, integration permissions, incident handling, and the process for removing access.

Ask precise security and residency questions

Request the hosting and backup locations, contractual data-handling terms, administrative access arrangements, and documented recovery commitments. Availability in Canada does not establish Canadian data residency. A regional label alone may be too broad for your requirements.

Odoo publishes cloud security practices, including encryption and backups. Use those documents as inputs to your review. Then identify the controls your own team still owns: role design, administrator accounts, secrets, integration permissions, and a practiced response when access must be revoked.

Plan the exit before the entry

Document how to export a complete backup, preserve custom source code, and move to a supported target. Odoo's hosting documentation describes version constraints for transfers: intermediary Online releases cannot move directly to Odoo.sh or on-premise. Review compatibility before promising a migration date.

Ask for a written transition runbook with responsibilities, expected downtime, validation steps, and recovery criteria. A hosting decision is stronger when the team understands both everyday operation and the process for changing direction later.

Example: evaluate a custom workflow before hosting

Imagine a team requests a specialized approval step because its old software worked that way. First demonstrate the available standard workflow and ask the process owner whether it meets the control objective. If it does, the hosting decision can stay focused on the remaining requirements. If a custom module is still justified, record why it is necessary and who will maintain it.

Now compare the operational cost of the eligible hosting options with that module included. Ask who deploys updates, validates a restore, investigates a slow job, and communicates during an outage. These concrete responsibilities reveal differences that a simple hosting price comparison can hide.

Revisit the decision when the business adds a company, enters a new market, or changes its integration needs. Keep these review triggers in the operating plan.