What Odoo upgrades and support involve
Plan every Odoo upgrade around the standard support window. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Security patches stop when standard support ends, so a version that has passed that point is a security exposure whether or not anything visible breaks. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, which means the upgrade is a recurring cost of the platform rather than an occasional project.
Four events usually start an upgrade. The first is a version approaching the end of standard support, which the Odoo standard and extended support documentation lists by release date. The second is a planned upgrade to pick up new features. The third is a new module need, such as a feature only available in a later version. The fourth is a failed upgrade test, where the upgraded test database shows errors that must be fixed before production. Confirm the current support dates for your version in Odoo's documentation before setting a plan, because the dates are published by Odoo and may change.
Most teams keep routine patching and day-to-day administration in-house, since those tasks mainly involve applying updates, watching logs and restoring backups in their own environment. Major upgrades and porting custom modules usually go to a partner, because each major version can change APIs and views that custom code depends on. Ask any partner for a written scope that names the test database work, the custom modules to be ported, the number of test cycles and who signs off before production.
Ask your implementation partner or upgrade provider to confirm which support tier applies to your edition and hosting, and whether the Enterprise subscription covers the upgrade service you plan to use. Community edition has no access to Odoo's upgrade service, so an on-premise team on Community must plan the upgrade path without it. Keep a current inventory of custom and third-party modules, since that list drives most of the effort in any upgrade quote.
What the service includes
The upgrade service is delivered as a sequence of work packages, each ending in a document or tested system you keep. Note that the Odoo upgrade service requires an Enterprise subscription for on-premise use, and Community databases have no access to it.
Version assessment and upgrade plan
We compare your current Odoo version, installed apps, custom modules and third-party add-ons against the target release and its standard support window. The deliverable is an upgrade plan listing the target version, the modules that need porting, the data checks and the decision points. Confirm early that your subscription covers the Enterprise upgrade service, since Community databases cannot use it.
Upgraded test database and functional testing
We build an upgraded test database from a copy of production using Odoo's upgrade process, then run functional tests on the business flows that matter most, such as sales, invoicing, stock moves and payroll exports. The deliverable is a test report with pass, fail and waived items. Odoo recommends testing the upgraded test database before any production upgrade.
Porting custom and third-party modules
Custom Python modules and third-party add-ons often change their APIs, views and inherited fields between versions, so each one needs code changes and tests. We port and review each module against the target version and record every change. The deliverable is a list of ported modules with their versions, changes and open issues, including any add-on with no release for the target version.
Production upgrade and cutover
We schedule the production upgrade, freeze data entry, run the upgrade on a verified backup and switch users to the new version. The deliverable is a cutover runbook with steps, owners, timings, rollback points and the backup restore procedure. Agree in writing who approves the go or no-go decision and who can trigger a rollback.
Post-upgrade verification
After cutover we check that data counts, open transactions, scheduled actions, integrations, reports and user access behave as they did before the upgrade. The deliverable is a verification checklist signed off against the test report, along with a list of known differences. Ask how long the hypercare window runs and who handles defects raised during it.
Ongoing support after go-live
Support after go-live covers defect triage, patch review and planning for the next upgrade within standard support. Standard support for each Odoo version runs for three years after a major release, including security updates and bug fixes, so the upgrade calendar should be set against those dates. The deliverable is a support schedule and an upgrade roadmap. Confirm response times and the scope of the retainer in writing before work starts.
What drives cost and timing
The table lists the factors that change how much work an Odoo upgrade or support engagement takes, why each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom modules and core dependencies | Each custom module must be ported at every major version. Modules that override core methods or depend on internal APIs break more often and need more testing than modules that use public extension points. | Prefer configuration and Odoo Studio where they meet the need. Inherit core models through documented hooks, and count how many modules touch core internals before quoting. |
| Installed apps and third-party modules | Every installed app and third-party module adds code that may change between versions. Modules from unmaintained sources can block an upgrade entirely. | Remove unused apps before the upgrade. Confirm each third-party module has a release for the target version before the test database is built. |
| Database size and data quality | Large databases take longer to upgrade and test. Duplicate partners, inconsistent product records and orphaned data can cause upgrade errors or wrong reports that someone must investigate. | Archive old records the business no longer needs, clean duplicates before the upgrade, and measure the database size with the partner during scoping. |
| Integrations that must be retested | eCommerce, banking, logistics and other systems that use the Odoo external API need retesting against the upgraded instance. Changed field names, sync logic or authentication can break them silently. | Document each integration, its data flows and its owner. Keep a list of test transactions per integration so retests are repeatable and fast. |
| Hosting model | Odoo Online and Odoo.sh are upgraded on Odoo's schedule with a managed path. On-premise instances need your own backup, test database and cutover steps, and the Enterprise subscription must be current for the upgrade service. | Confirm the hosting plan allows the custom code you run. Agree who owns the test database, backups and cutover window before work starts. |
| Environments and test cycles | Each environment needs its own upgraded copy and test pass. Repeated test cycles after defects are found add effort, especially when the upgrade is run several times to rehearse cutover. | Build the test database from a fresh production copy with neutralization, fix defects in a single batch, and agree how many test cycles the quote includes. |
| Users and business processes needing acceptance testing | Each business process that users run daily, such as order-to-cash or month-end close, needs scripted acceptance testing. More processes and more user roles mean more scenarios to sign off. | Limit acceptance testing to critical processes and roles, prepare test scripts with process owners, and agree sign-off criteria in writing. |
| Code and integration surface, not the version number | Effort follows how much custom code and how many integrations the instance depends on. Two upgrades of the same version step can differ widely in effort because their module and integration footprints differ. | Ask for a scoping review that counts custom modules, core dependencies, apps and integrations, then price the upgrade from that inventory. |
How an upgrade project runs
The sequence turns an existing Odoo database into a tested upgrade on a supported version, with each phase closing on a written output the business can sign off.
Assess apps, custom code and integrations
We inventory installed apps, custom and third-party modules, integrations, scheduled actions and data volumes, and check each module against the target version. The output is an inventory register listing what changes, what is removed by the core, and what needs porting or replacement, reviewed with your technical owner.
Agree the upgrade plan and target version
We compare your current version against the standard support dates published by Odoo and recommend a target version that keeps you inside standard support, which includes security updates and bug fixes. The output is a written upgrade plan with the chosen target, the cutover approach and the decisions your leadership needs to make before build starts.
Build the upgraded test database
We create a neutralized copy of production, so outgoing emails, payment and integration endpoints do not reach live systems, and run the upgrade on that copy. The output is an upgraded test database with a log of every migration error, which is the basis for the porting work.
Port modules and fix errors
We adapt custom and third-party modules to the target version, fix migration errors and reconnect integrations to the test environment. Each change is reviewed and tested in code, and the output is a build where all custom modules install and run without errors on the upgraded database.
Test functions and integrations with business users
Your business users run their daily processes on the test database, such as sales orders, invoicing, stock moves and month-end reports, while we verify integration flows and data results. The output is a signed test log with defects triaged and closed or accepted, which decides whether cutover is approved.
Rehearse cutover and upgrade production
We run the full production upgrade steps at least once on a fresh copy, timing each step and recording the rollback point, then repeat the same steps on production during the agreed window. The output is an upgraded production database, a verified backup taken before the upgrade, and a rehearsal record your team can reuse.
Support hypercare and hand over
After go-live we monitor logs, scheduled actions and integration queues and fix issues found by users during the agreed support period. The output is a handover pack with the updated module inventory, runbook, known issues and the support arrangement for the next upgrade, which you should confirm in the written scope.
What stays in-house and what goes to a partner
This table shows which Odoo upgrade and support activities most teams keep internally, which they usually hand to a partner, and which depend on hosting or connected systems, with the skills each one needs.
| Activity | Usually kept in-house | Usually outsourced | Skills each part needs |
|---|---|---|---|
| Business acceptance testing | Process owners sign off that upgraded workflows match how the business actually runs | Test scripts and regression checklists drafted by the partner for owners to execute | Process knowledge from finance, sales, inventory and HR; basic test design so owners can record clear pass or fail results |
| Routine patching and backups | Depends on hosting: teams on Odoo.sh or Odoo Online rely on the platform, while on-premise teams often run this themselves | Managed for on-premise or private cloud environments under a support retainer, if the partner's scope includes it | Linux administration, PostgreSQL backup and restore, and an understanding of which Odoo releases still receive security patches |
| Python module porting and code review | Kept in-house only where the team already employs Odoo developers who know the core ORM and view inheritance | Usually outsourced, since porting custom modules to a new major version touches models, views, security rules and tests | Python, Odoo ORM and XML view internals, module manifests, and writing automated tests that exercise custom behavior |
| Integration retesting | Depends on skills in the connected systems: teams that own the eCommerce, banking or logistics APIs can retest their side directly | Often shared: the partner reruns Odoo-side sync logic while the system owners verify their endpoints | API authentication, data mapping, error handling and duplicate-record checks on each connected system |
| Production cutover | Shared: the business schedules the window, freezes data entry and confirms go-live sign-off | Shared: the partner runs the upgrade steps, the test database rehearsal and the rollback plan | Upgrade service procedures, database backup verification, reconciliation of key balances and a rehearsed rollback path |
| Staff knowledge of the new version | Kept in-house: administrators and power users learn the changed screens, menus and reports | Training materials and sessions can be bought in as part of the upgrade scope | Functional knowledge of each app in use and a record of local customizations that changed |
What goes wrong and how to prevent it
Most Odoo upgrade problems are visible long before go-live if the team checks the right things early. The cards below cover the failure patterns we see most often and the step that prevents each one.
Upgrading without a current test database
Teams sometimes run an upgrade against an old or partial copy of production, then discover problems only at cutover. Odoo's upgrade service produces an upgraded test database that should be reviewed before production is touched. Build that test copy from a recent production backup, duplicated with neutralization so no outbound emails or payments are triggered, and refresh it before each test cycle.
Custom modules that override core internals
Custom modules that replace core methods or depend on internal field names often break when the next version changes them. Inspect each custom module for overridden methods, direct SQL and hard-coded technical names before the upgrade plan is set. Prefer inheritance hooks and documented extension points so the port at each version stays small and reviewable.
Third-party modules without a target version release
A third-party module may have no release for the version you are moving to, which can block the whole upgrade. Make an inventory of every non-core module with its source, license and current version, then confirm with each publisher whether a release exists for the target version. Plan a replacement, a fork or a port for any module where that confirmation is missing.
Data that fails validation after migration
Upgrade scripts and new version rules can reject records that were accepted before, such as invalid partner data, incomplete accounting setups or orphaned references. Run the upgraded test database through validation reports and reconcile key totals against the source, including open invoices, stock valuations and user counts. Log every rejected record with an owner and a fix before the production run.
Integrations that duplicate or stop syncing
External systems such as eCommerce, banking and logistics connectors often keep their own identifiers and sync schedules, so an upgrade can change field names or break external IDs. The result is duplicate orders, missed payments or silent sync stops. Pause each integration during cutover, confirm the external ID mapping in the test database, and verify record counts on both sides after the first sync.
Missed standard support dates
When a version leaves standard support, security patches stop for that version, and extended support is not offered in every case. Record the end-of-support date for your version from Odoo's support documentation and schedule the upgrade with enough lead time to test and cut over before it. Review the date at each quarterly planning cycle so it is not discovered late.
Sign-off before testing real processes
Business users sometimes approve an upgrade after checking screens or reports rather than running full processes. Errors then surface in month-end close, shipping or payroll after go-live. Write test scripts from real end-to-end flows such as quote to invoice to payment, and have process owners run them in the test database with their own data before signing off.
How the work changes by hosting and starting point
Odoo Online is the vendor-hosted SaaS model. Odoo runs the environment, and the upgrade path follows the vendor's release cadence rather than a schedule the client sets.
- Who runs the upgrade: Odoo performs the platform upgrade on its own infrastructure. The client's work is testing and adjusting its own data, configuration and any custom code.
- Upgrade service: The upgrade service is not used in the same way here, because the vendor moves the environment forward. Confirm with Odoo how upgrade timing is communicated to your account.
- Access: The client has application-level administration only. There is no server, database or filestore access for custom code deployment.
- Release cadence: SaaS releases arrive every two to three months and cannot use extended support, so the client must keep pace with them.
- Air-gapped or private networks: Odoo Online is not an option for air-gapped environments, so this model does not apply to them.
Odoo.sh is the platform-hosted model. Odoo hosts the environment, but the client has much more direct access to branches, staging and custom code than in Odoo Online.
- Who runs the upgrade: The client plans the upgrade and validates it, while Odoo provides the hosting platform and upgrade tooling.
- Upgrade service: Upgrades use the upgraded test database approach, which should be tested before anything goes to production.
- Access: The client can work with branches, staging and custom module deployment, so custom code must be ported and tested before each major version.
- Mandatory cadence: Major version upgrades are mandatory every two years on Odoo.sh, so the client should plan the calendar early.
- Plan requirement: Only the Custom plan can be hosted on Odoo.sh, so confirm the plan and subscription terms before design work starts.
On-premise with an Enterprise subscription places the client in charge of hosting, backups, patching and upgrades in its own infrastructure.
- Who runs the upgrade: The client's team or its partner runs the upgrade in its own environment, using a test database before production.
- Upgrade service: The upgrade service requires an Enterprise subscription on on-premise installations.
- Subscription activation: Enterprise databases are activated by entering the subscription code. Confirm how that code is applied in each environment, including test copies.
- Access: The client controls the server, database, filestore and custom module deployment, which gives full control and full responsibility.
- Support window: Standard support covers the first three years after a major release, and paid extended support is available for on-premise. Confirm the versions covered at the time of planning.
Community starting point means the organization runs the open-source edition and does not hold an Enterprise subscription. The upgrade path changes because the upgrade service is not available.
- Who runs the upgrade: The client or its partner performs the upgrade manually, including code and data review.
- Upgrade service: The Community edition has no access to the upgrade service, so the upgrade plan must not depend on it.
- Access: The client controls the full environment, as with on-premise, and must test custom modules against each target version.
- Migration path: Moving from Community to Enterprise requires a subscription and a checked migration plan, covered on the sibling page.
- Comparison: For the full difference between Community and Enterprise, including hosting options, see the sibling pages on hosting models and on the Community to Enterprise migration.
What you need to provide
Most of the quote and timeline for an Odoo upgrade depends on what you hand over at the start. Gaps in these inputs are the most common reason an upgrade estimate grows after work begins. Confirm each item below before a fixed-scope quote is written, because each one changes the amount of testing, porting and coordination that has to be priced.
Database access comes first. We need the production database or a recent copy, and written approval to create a duplicate that is neutralized before it leaves production, so scheduled actions, outgoing mail and external connectors do not fire in test. Also provide a current inventory of installed apps, custom modules and third-party modules, with the source and version of each. Porting effort grows with every module that has no owner or source, and an unlisted module usually surfaces during the upgraded test database run.
Next, provide integration contracts and endpoints for every system that reads from or writes to Odoo through its external API, such as eCommerce, banking or logistics connections. Name business owners who can sign off test results for finance, sales, inventory and other affected areas. Sign-off without named owners tends to stall acceptance. Confirm whether you need a test environment on your own infrastructure, which affects hosting and the Enterprise subscription check.
Confirm Enterprise subscription status for any on-premise system, since the upgrade service requires it and the Community edition has no access to it. Also name the person who owns the change window and the rollback decision, and agree a backup and restore plan that has been tested. Ask the implementation partner to state in the quote which of these inputs they assume are already in place.
Common questions about Odoo upgrades and support
How much does an Odoo upgrade cost and what changes the price?
The cost follows from the written scope, so no price applies until the scope is agreed. The main drivers are the number of Odoo apps in use, the number and complexity of custom and third-party modules that must be ported, the volume and condition of the data, the number of integrations to retest, and how many test cycles the business needs before go-live. Hosting and edition add recurring costs: on-premise upgrades require an Odoo Enterprise subscription, which is paid to Odoo and renews separately. Ask for a quote that lists each module to port, each integration to retest, and who runs the production cutover.
How long does an Odoo major version upgrade take from start to go-live?
Duration depends on scope, and a fixed-scope quote sets the timeline in writing before work starts. The biggest factors are how much custom code must be ported and tested, how many integrations depend on changed behavior, and how many business processes need sign-off on the upgraded test database. Data volume affects both the upgrade run and the validation effort. Client availability for testing and decisions also sets the pace. Because Odoo Online and Odoo.sh major upgrades follow a two-year cycle, plan the upgrade window early so it does not collide with other system changes.
Can our own team upgrade Odoo, and is the upgrade service on Community?
A team with Python and PostgreSQL skills can upgrade a simple system alone, but only with strict test-database discipline. Run the upgrade against a duplicated copy, neutralize that copy so it cannot send email or trigger live integrations, test every app and custom module on the upgraded test database, and move to production only after sign-off. The upgrade service is available for on-premise systems only with an Enterprise subscription. The Community edition has no access to the upgrade service, so Community users must plan and carry out the move without it.
What must our team provide before an Odoo upgrade starts?
Provide a current backup, access to the production server or Odoo.sh project, and an inventory of installed apps, custom modules and third-party modules with their sources. Share a list of integrations with their owners and name a business owner who can approve test results for each process. Give the team a test environment that closely matches production in configuration and size. For on-premise systems, supply the Enterprise subscription code and the deployment credentials. Confirm any change freeze and data retention rules that apply. The inventory comes first, because the quote depends on it.
What does DeployOpen support include after an Odoo go-live?
Support after go-live is defined in the written scope or in a retainer. Odoo's standard support covers security updates and bug fixes for the first three years after a major release, on Odoo Online, Odoo.sh and on-premise. DeployOpen offers ongoing support, upgrades and continuous testing under a retainer, and can document, back up and harden the system where those tasks are in scope. Confirm which issues Odoo handles and which DeployOpen handles, and ask for the response process and exact services in the proposal before signing.
What happens when an Odoo version leaves standard support?
Once standard support ends, the version no longer receives security patches on the standard track. Paid extended support is limited to Odoo.sh for select versions and to on-premise systems, and SaaS versions cannot use it. Odoo 17.0 standard support ended in September 2026, Odoo 18.0 runs until September 2027, and Odoo 19.0 runs until September 2028. Plan the move to a supported version before the end date, because the upgrade may cross several major versions. Ask for written confirmation of which extended support option applies to your hosting.
How DeployOpen delivers Odoo upgrades and support
DeployOpen plans, tests and carries out Odoo version upgrades and ongoing support inside infrastructure you control, starting from a written scope and a test database before anything reaches production. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- We confirm which Odoo version and edition you run, and which apps, custom modules and third-party modules the upgrade must cover.
- We record the target version and the support window it falls in, so the written scope states which release the upgrade is aimed at.
- We list what the written scope includes and excludes, such as module porting, data cleanup, integration retesting and user acceptance testing.
How we build
- We restore a copy of your production database into a test environment and run the Odoo upgrade service against it.
- We port custom modules and review changed views, workflows and reports, then fix issues found in functional and regression tests.
- We keep the test database and upgrade steps documented, so the same sequence can be repeated before the production cutover.
How we hand over
- We deliver a written record of the upgrade: versions, module changes, test results, known issues and rollback steps.
- We walk your administrators and key users through changed features, so they know what to check after the production cutover.
- We provide runbooks for backups, restores and patch application, written for the team that will operate the system after handover.
How we support
- Ongoing support is available as a retainer, covering patch application, incident response and planning for the next major version.
- We track when your version leaves standard support, so upgrade planning starts well before security patches stop.
- Confirm with us during scoping which support hours, response channels and escalation paths the retainer includes, and what it excludes.
