Odoo Community vs Enterprise upgrades

No. The upgrade service is available to Enterprise subscribers, so a Community database has no route into it. Community users upgrade by working through the open source codebase themselves, using community tooling such as OCA OpenUpgrade or in-house migration scripts, and they carry the full test and cleanup burden. The practical consequence is that the upgrade plan, the test environment and the person accountable for the result all sit with your team or the partner you hire. Ask any provider to state in writing which upgrade path they use for a Community database and who maintains the scripts after handover. Odoo's upgrade documentation describes its test-first workflow, which is a useful baseline for judging your own process.

Yes. Running Odoo Enterprise on-premise requires an Enterprise subscription, and the upgrade service is part of what that subscription provides. Odoo's licenses documentation says the Enterprise license requires a valid subscription matching the user count, so a lapsed or undersized subscription creates a licensing question on top of the technical upgrade. Check three things before you plan: that the subscription covers your current user count, that it stays active through the target version's support window, and that every database you intend to upgrade is linked to that subscription. Standard support covers only the first three years after a major release, so a subscription that ends mid-project can leave you upgrading without the service your plan assumed. Confirm the terms with Odoo directly, because your subscription contract governs your rights.

Custom modules usually drive most of the upgrade effort. The upgrade moves the standard modules forward, while your code must be checked against each changed model, field, view and API. Effort rises with the number of custom modules, how deeply they depend on core internals, how many inherited views and method overrides they carry, and how much data migration logic they need. Modules that only add fields and menus are usually quicker to review than modules that patch core methods. If a custom module hooks into Enterprise-only apps such as Studio, Documents or Payroll, it must also be tested against those apps. Ask for an inventory listing each module, its dependencies on core and Enterprise, its overrides and its test coverage. Without that list, no quote can be reliable, and the review effort repeats with each later major version.

Not always. The answer depends on your team's skills and the size of your custom code. A team with experienced Odoo developers, a staging environment and time for testing can run the process internally, following the test-first workflow in Odoo's upgrade documentation. A partner adds the most value where the team lacks Python and PostgreSQL experience, where custom code is large, where the upgrade must fit a change freeze, or where an independent reviewer of data migration reduces risk. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, so confirm your team can support that stack before you commit. DeployOpen plans, implements, tests, documents and supports self-hosted open source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Compare that model honestly with the cost of keeping experienced staff on the upgrade.

A quote should follow from a written scope, so the first deliverable is the scope itself. Ask that it names the source and target versions, the edition and subscription status, the number and size of databases, the custom module inventory, the integrations that read or write to the database, and who builds the test environment. It should also state functional testing responsibilities, the data migration and rollback approach, the cutover window and the documentation handed over. Ask what is excluded, such as new feature work, third-party connector changes or user training. Separate one-time costs, such as assessment, script work, testing and cutover, from recurring costs, such as support retainers and later upgrades. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask every provider to list its assumptions and the conditions that would change the estimate.

No general duration can be supplied for every project, so confirm it with the vendor and against your own test environment. The main drivers are database size and age, the number and complexity of custom modules, the number of data migration steps, the number of integrations and how much functional testing your business needs before sign-off. A rehearsal on a copy of production usually matters most, because the first trial run reveals the problems that set the cutover window. Ask for the duration of each phase, including assessment, script build, each test cycle and cutover, with the assumption behind each one. Odoo's documentation says the upgraded test database should be tested before production, so your timeline must include test cycles, not only the migration run. For test copies, Odoo's on-premise documentation describes database duplication with neutralization, which helps keep outbound emails and external integrations from firing during rehearsals.

Security updates are provided only during standard support, which covers three years after a major release. Odoo 19 (September 2025) has standard support until September 2028, Odoo 18 (October 2024) until September 2027, and Odoo 17 standard support ended in September 2026. Odoo 20 was released in September 2026, with standard support planned until September 2029. Paid extended support is limited to on-premise and selected Odoo.sh versions, and Odoo SaaS versions cannot use it. So an on-premise database running a version past standard support can keep receiving security patches only if you have purchased extended support for that version. Plan upgrades to land inside the window, and confirm in writing with Odoo which extended support terms apply to your version and hosting model.