Odoo.sh versus on-premise hosting

After go-live, the main difference between Odoo.sh and on-premise hosting is not the software. It is who holds each operating task. On Odoo.sh, the platform handles much of the server layer, including deployment, backup scheduling and restores within the platform's tooling, while your team or partner still owns the database content, custom modules, functional testing and the decision about when to move to a new version. On-premise, your organization owns every layer: the operating system, the Odoo service, PostgreSQL, the filestore, the reverse proxy, backup storage, monitoring and patching. Before you choose, ask the vendor to put in writing which of these tasks it performs, how often, and what it does not cover. Do not assume that a hosting label answers the question.

Security updates are the sharpest split. Odoo provides security patches only during standard support, which the Odoo standard and extended support documentation describes as three years after a major release. Extended support is paid and, according to the same documentation, is limited to Odoo.sh for select versions and to on-premise deployments. Once a version leaves standard support, a database still runs, but the organization is carrying the security risk unless it has a named owner and a funded plan to upgrade or to buy extended support where it is available. Check your version against the dates in the Odoo documentation, and record the end date in your asset register so it is visible to the CISO and the budget holder, not only to the engineers.

Third-party and custom modules are the usual cause of an upgrade running late. On either host, someone must own a review of every module that is not from the core Odoo distribution before a major upgrade starts. That review covers the module's maintainer, whether a version for the target release exists, which core views or methods it overrides, and whether it reads or writes personal data. On Odoo.sh the platform does not port your custom code for you, and on-premise the same work sits with your team. Ask your implementation partner whether module porting is inside the fixed scope of a support or upgrade engagement, and what happens to a module that has no target-version release.

Monitoring and backups need explicit owners as well. Decide who receives alerts for failed backups, disk growth, PostgreSQL errors, worker exhaustion and certificate expiry, and who responds out of hours. For backups, confirm the retention period, the storage location, the restore procedure and the time required to restore to a separate environment. Test a restore on a schedule rather than trusting the backup job log. Treat the restore test as the evidence. Document who may request a restore, who approves it, and whether a restore on Odoo.sh is handled by the platform or by your team.

Finally, write a short responsibility matrix and review it at each quarterly change window. List each task (patching the operating system, applying Odoo updates, upgrading the major version, backing up and restoring, monitoring PostgreSQL, tracking support end dates and reviewing modules) with a named role, an interval and the contractual source of the commitment. Where a commitment comes from a partner or the vendor, attach the written terms to the matrix. Ask for the vendor's written terms on response times and update cadence, because this page does not state service levels and any figure you hear without a contract behind it should be treated as an intention.

A host is proven only when a set of tests passes on it, using your modules, your sign-in setup and a copy of your data. Run these checks on the host you chose before cutover, and record each result with a named owner. Start with the edition and modules. On on-premise, confirm that the Enterprise subscription code activates the database and that every app in scope installs without errors. On Odoo.sh, confirm with Odoo that your plan is the Custom plan, because Odoo's pricing page lists Custom as the only plan that can be hosted on Odoo.sh or on-premise, and confirm that multi-company, Studio, external API access and custom modules are all active. A failure here usually appears as a missing app menu or a module that will not install because a dependency is absent. That tells you the licence or plan is wrong before any data moves.

Next, run the upgrade service against a copy of production and open the upgraded test database. On-premise, this requires an Enterprise subscription, and a Community install has no access to the service, so it fails this test by definition. Then check every custom module on the upgraded copy: install it, open its views, run its reports, trigger its scheduled actions and exercise its security rules with a test user from each access group. Failures look different by host. On-premise, the upgrade can stop with a server error or leave a module that fails to load, so keep the upgrade log and the module error output. On Odoo.sh, ask Odoo which logs and build output your plan exposes, and confirm how you will see them before the window opens. Both paths should end with a written list of modules that need porting work.

Test sign-in with each provider you plan to enable, using test accounts that match the access groups people will hold. Odoo documents LDAP with optional user creation on first login from a template, Google Sign-In, Microsoft Azure OAuth, Facebook sign-in and two-factor authentication. For each one, confirm the user lands in the right groups and that a user outside those groups is refused. Enable two-factor authentication on a test account and confirm the enrolment and recovery steps work. On on-premise, the common failures are a reverse proxy or certificate setting that breaks the OAuth callback, or an LDAP bind that is blocked by a firewall between the Odoo server and the directory. On Odoo.sh, confirm in writing whether the platform can reach your directory from its network path, since that depends on how your environment is connected and will not work by default.

Restore a backup to a separate server, not the production host, and time the restore so you know how long a recovery would take. Check that the database opens and that attachments in the filestore display correctly. Then create a neutralized test copy and inspect it. Confirm that it holds no live payment keys, API tokens, SMTP credentials or connection strings to production systems, that scheduled actions are disabled, and that outbound mail is blocked or redirected to an internal address. The failure you are guarding against is a test copy that sends real invoices or reminders to customers, or that writes to a live integration. Odoo documents database duplication with neutralization for on-premise, but your own mail server and integration settings still need explicit checks. On Odoo.sh, ask how copies are created, whether neutralization runs automatically, and whether it also covers your custom configuration parameters.

Confirm in writing the support end date for the version you will go live on, using Odoo's standard and extended support documentation. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates. After that, paid extended support is limited to Odoo.sh for select versions and on-premise, and security patches are provided only during standard support. Odoo 19.0 was released in September 2025 with standard support planned until September 2028, and Odoo 17.0 standard support has already ended, so the window differs by version. On Odoo.sh, major upgrades are mandatory every two years, which means the upgrade budget recurs. A go-live on a version close to its end date, with no funded upgrade path, is a failure you can detect now. Ask the team to name the date, the owner of the next upgrade and the test database they will use.