In this piece
Odoo Online to Odoo.sh: prove the integration requirement first
Your warehouse project needs to exchange data with Odoo. Someone adds “move to Odoo.sh” to the estimate before showing which part of the workflow cannot run in the current setup. The move might be justified. The missing step is the evidence connecting that hosting change to an approved business requirement.
Move from Odoo Online to Odoo.sh when a demonstrated requirement needs capabilities your current deployment cannot supply, and the proposed target supports them. Resolve the version path and operating ownership before scheduling migration. If existing configuration or an approved external integration satisfies the requirement, staying on Online remains a valid outcome.
Research checked: 5 November 2026. This decision guide uses official Odoo 20.0 sources and the Odoo.sh FAQ. The warehouse example and twelve downloadable cases are fictional design aids. We did not migrate a database, install a module or run the proposed acceptance checks.
What requirement would justify moving?
Write the business rule independently of the proposed technology, then demonstrate the capability that is missing. A request to exchange warehouse information is too broad to establish a hosting requirement. Specify who may perform the action, which record it affects and what must be true when the operation completes.
Consider fictional requirement R-17: a warehouse receipt may be accepted only when its supplier certificate matches the approved revision for that receipt. The operations owner wants the rule to hold for the relevant user and integration paths. This is an invented requirement, not a statement about a particular Odoo model, field or installed Quality configuration.
The discovery task has two possible outcomes. The team might demonstrate an existing configuration that satisfies R-17. Alternatively, a reviewed gap might require an installable custom Python module. Do not decide which outcome is true from the wording of this example; inspect the actual application and proposed behavior.
| Question | Evidence to request | Decision consequence |
|---|---|---|
| What business result is required? | An approved rule and representative valid and invalid cases | Sets the acceptance target |
| Can the current setup satisfy it? | A demonstration on the relevant entry paths | Keeps staying on Online available |
| What exact capability is missing? | A documented gap with configuration alternatives considered | Defines the proposed extension |
| Does the target support that extension? | Reviewed runtime and deployment requirements | Establishes a viable hosting candidate |
| Can this database transfer on time? | Exact version and supported migration route | Determines scheduling constraints |
| Who will own it afterwards? | Named responsibility and demonstrated access | Makes the operating commitment explicit |
A proposal can answer the first three questions and still be unready for approval. Technical need, platform fit and operational readiness are separate pieces of evidence. Keep their unresolved items visible rather than letting one successful demonstration stand in for all of them.
Can the integration stay on Odoo Online?
Evaluate the required supported operations and configuration before changing hosts. An external component that reads authorized records or invokes an existing appropriate operation does not, by itself, prove a custom-module requirement. Confirm entitlement, permissions and the actual operation, then demonstrate the intended behavior with the deployed versions.
The Odoo 20 API reference places external API access on Custom plans. A missing entitlement is a commercial question to resolve before treating it as a hosting limitation.
For example, a warehouse status screen might only need a permitted read of selected information. Its acceptance record should show the correct records for the intended identity, the fields needed and the workload the design creates. None of those observations requires assuming that a new custom module will exist.
For outbound events, the automation documentation describes a webhook action that posts selected record fields. Demonstrate its suitability and availability in your configuration; a feature description is not an end-to-end delivery test.
The Odoo API integration limits guide owns the detailed entitlement, transaction and protocol discussion. Use those constraints when evaluating the proposed connection. This hosting decision should record which requirement remains unsatisfied after that review, if any.
When does a custom module change the decision?
An evidenced need to install custom application code changes the eligible deployment options. First identify the smallest missing behavior and why the existing configuration cannot supply it. Then review the proposed module as a maintained software dependency, with an owner and acceptance criteria, before selecting its host.
The Odoo Online documentation excludes custom and Apps Store modules. That restriction matters once the requirement for such a module has been established.
For R-17, ask the implementer to show both an accepted matching certificate and a rejected outdated revision. Include each relevant entry path, including the intended integration identity. A screen that displays a warning is insufficient evidence if the approved requirement says the receipt must not be accepted.
If native configuration passes those cases, retain that evidence and reconsider the module proposal. If the gap remains, document the intended extension point, permitted actions and expected failure behavior. The Odoo custom-module acceptance review provides a separate code and behavior review pattern; it does not establish that this particular module is needed.
Keep optional convenience changes out of the minimum hosting justification. Combining an essential control with unrelated interface wishes can obscure why the move is necessary and make its scope harder to approve. Record the additional work separately so the buyer can make a deliberate decision.
Will Odoo.sh support the whole proposed design?
Check the proposed runtime as well as the Odoo module. List background components, external connections and dependencies that the design assumes. A platform can be suitable for the application extension while another component needs to run elsewhere. Resolve that placement before promising a single-host solution.
The Odoo.sh FAQ rules out additional long-living processes and arbitrary system-package installation. Review those limits against the proposed dependency list.
Suppose the integration design includes a continuously running warehouse listener. Ask whether that component can operate as a supported external service and which team would maintain it. Do not assume that placing an Odoo module on the target also approves the listener’s runtime.
Use a deployment inventory with one row per component. Record its purpose, required privileges, persistence needs, communication pattern and accountable owner. For a module supplied by a third party, request evidence for the exact revision and dependencies you intend to use. A product name or a demonstration on another installation does not establish the proposed target’s compatibility.
If an essential dependency cannot be placed within the supported architecture, return to design review. The honest result may be a split deployment, a different implementation or another hosting option. That is useful discovery before a database transfer becomes a scheduled commitment.
Can the current database move when you need it?
Inspect the exact source version before agreeing a migration date. Record the proposed target and the supported route between them. Keep version eligibility separate from the time needed to adapt modules, verify behavior and obtain business acceptance; each can constrain the date even when the others look straightforward.
Odoo’s hosting-transfer guidance requires intermediary Online versions to reach the next major version first, waiting for its release if necessary.
Do not substitute the latest release headline for the version on your database. The decision record needs the observed version, observation date and confirmed transfer path. If that path is not currently available, mark the migration as deferred and review what portion of the business need can be addressed meanwhile.
A short-term external integration can be a candidate during that waiting period, provided it meets the accepted requirement. It should not be described as an equivalent substitute if it leaves the essential control unenforced. State which capability is delivered now and which remains blocked.
For a later rehearsal, use the Odoo migration reconciliation checks to define the evidence you need from the restored target. A version-compatible import is one input to acceptance; the business owner still needs the relevant records and workflows to behave correctly.
Who owns the system after the move?
Name the people who can approve code changes, administer access and recover the business workflow. Their responsibilities must be specific enough to survive a provider change. Hosting approval should include this operating handover, because a new deployment path creates work that a feature demonstration does not assign.
The Odoo.sh project guide uses a GitHub repository, major version and eligible subscription; its import warning states that existing branch data is overwritten.
| Responsibility | Evidence before approval | Question for the owner |
|---|---|---|
| Application code | Approved repository, revision and dependency inventory | Who reviews the next change and maintains compatibility? |
| Project and credentials | Verified access for accountable administrators | Can the company retain control when a provider leaves? |
| Business acceptance | Approved cases and named sign-off responsibility | Who decides whether the warehouse rule is satisfied? |
| Recovery and cutover | Rehearsal evidence and a reviewed recovery procedure | Who can stop the transfer and account for later writes? |
| Ongoing integration | Monitoring, incident and change responsibilities | Who handles a failed exchange after the project ends? |
These are proposed project controls, not additional guarantees from the hosting provider. Verify access through the actual supported account setup. Owning a repository name on paper is insufficient if the responsible company cannot retrieve the code or manage the people who may change it.
Request an estimate that identifies migration work, module maintenance and ongoing operations separately. The Enterprise upgrade scope and budget guide handles the contractual and budgeting distinction. Do not assume that choosing a host resolves what a supplier has agreed to maintain.
What evidence should the decision record contain?
Record the requirement, observed condition, proposed disposition and evidence needed to accept it. Preserve unresolved cases rather than converting them to a positive recommendation. The downloadable template deliberately includes reasons to stay, reasons to investigate a move and reasons to stop scheduling until a dependency is resolved.
| Case | Condition to investigate | Proposed response |
|---|---|---|
| H01 | Supported external status read | Evaluate staying on Online |
| H02 | Missing external API entitlement | Resolve the subscription question |
| H03 | Outbound event fits a native webhook candidate | Demonstrate the configuration |
| H04 | Existing write operation enforces the required rule | Evaluate staying with recorded acceptance evidence |
| H05 | Reviewed gap requires a custom Python module | Evaluate Odoo.sh and its remaining gates |
| H06 | Existing configuration satisfies R-17 | Retain the successful configuration evidence |
| H07 | Source version cannot transfer directly | Defer until the supported route is available |
| H08 | Unsupported runtime dependency | Review component placement or architecture |
| H09 | Unassigned code or project responsibility | Hold the operating handover |
| H10 | Backup exists without restoration evidence | Complete the approved rehearsal |
| H11 | Target module compatibility is unreviewed | Resolve the module evidence |
| H12 | Rehearsal may trigger uncontrolled external effects | Demonstrate isolation before testing |
Download the hosting decision and evidence template. Every row has NOT_RUN status, PENDING policy approval and blank actual evidence. The proposed disposition is a hypothesis for review, not authorization to migrate or a native compatibility result.
For each applicable case, attach the observed configuration or revision and the acceptance evidence. If a case does not apply, record why and who agreed. Keep an unmodified copy of the template so later reviewers can distinguish the proposed controls from what the project demonstrated.
What would we approve before scheduling migration?
Approve a specific requirement gap, a supported target design and a staffed handover. Require the version path and rehearsal scope to be clear enough for a realistic plan. If the current configuration already meets the accepted requirement, document that result and keep the smaller deployment until another evidenced need changes the decision.
The technology-selection guide offers a broader way to evaluate implementation choices. The Twinsoft AI case study is separate delivery context, not evidence that this warehouse or hosting scenario has been implemented.
Wavect’s technology consulting can turn a hosting recommendation into a reviewable scope. Discuss your Odoo hosting decision with the required workflow, current version and proposed extension.