Odoo end-of-support versions and extended support guide

What an Odoo end-of-support version means for your database

If your live Odoo database runs on a version whose standard support has ended, it no longer receives security patches. That single fact changes the risk profile of every record in the database, including customer, financial and employee data, and it means the version now needs a plan, not just a maintenance window. Start by confirming which version each environment runs (production, staging and any test copies), because a database duplicated for testing often carries the same exposure as production. Odoo's standard support covers the first three years after a major release, on Odoo Online, Odoo.sh and on-premise, and includes security updates and bug fixes. Security patches are provided only during that window. The deadline is set by the version's release date, not by the calendar year of your project, so a project that starts late in a version's life may have far less runway than the team expects. Check the release and end dates for your version in Odoo's standard and extended support documentation and write the end date into your project plan. Odoo 17.0 standard support ended in September 2026, Odoo 18.0 is scheduled to end in September 2027, Odoo 19.0 in September 2028, and Odoo 20.0 in September 2029. Upgrading is harder than it looks. Custom modules and third-party apps must keep pace with core changes, so each one needs a compatibility review, code changes where core APIs or views have moved, and tests against a copy of the real data. Hosting also constrains the options: only the Custom plan can run on Odoo.sh or on-premise, and extended support is limited to Odoo.sh for select versions and to on-premise, so confirm which options your edition and hosting model actually allow before you commit to a path. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years according to Odoo's upgrade documentation. An upgrade across several versions is a project, not a patch. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database that you must test before production. On-premise use of that service requires an Enterprise subscription, and Community users do not have access to it. Ask your partner or internal team to confirm the upgrade path, the subscription status and the list of custom and third-party modules that need porting before you agree on a date. The practical decision is whether to upgrade now, to a version still in standard support, or to take on a paid extended support arrangement where one is available for your setup. Confirm the availability and terms of any extended support option with Odoo for your exact version and hosting model, and write down the risk of running unpatched in the meantime. Reduce that exposure with controls you can apply immediately, such as limiting network access to the instance and reviewing user accounts, while the upgrade is scheduled.

Support windows, editions and hosting models that set the deadline

An Odoo version's end of support depends on several things at once: the release date, the edition, where the database is hosted and how often the instance is upgraded. Each one changes when security patches stop, so check them together for every database you run.

Standard support end date per major version

Standard support covers the first three years after a major release, including security updates and bug fixes, on Odoo Online, Odoo.sh and on-premise. The published end dates differ by version, for example September 2029 for 20.0 and September 2027 for 18.0. Confirm the current dates on Odoo's standard and extended support page before setting a plan, because the end date is the deadline for patches.

Community or Enterprise edition

The edition decides which upgrade and support services are available. Enterprise on-premise databases need a subscription, and the upgrade service requires an Enterprise subscription for on-premise use. Community has no access to the upgrade service, so an older Community database must be moved to a supported version by the team that runs it. Confirm the edition of every database in your inventory.

Hosting model: Online, Odoo.sh or on-premise

Odoo Online, Odoo.sh and on-premise follow different rules for extended support. Paid extended support is limited to Odoo.sh for select versions and to on-premise, so a database on Odoo Online has no extended path. Odoo's pricing page states that only the Custom plan can run on Odoo.sh or on-premise. Record the hosting model for each database because it decides your options after standard support ends.

SaaS release cadence and mandatory upgrades

SaaS versions are released every two to three months and cannot use extended support, so a SaaS database must keep moving with the release train. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years according to Odoo's upgrade documentation. Plan these upgrades into your calendar rather than waiting for the end-of-support date to force them.

Custom modules and third-party apps

Custom modules and third-party apps have their own compatibility with each major version and may need porting before an upgrade can succeed. They can block an upgrade even when the core version is still supported. Keep an inventory of every custom and third-party module, its source, its owner and the versions it has been tested against.

The database and its upgrade path

The database itself carries the upgrade risk: its size, its data quality and any direct changes made in the database. Odoo's upgrade service works through an upgraded test database that should be tested before production, so allow time for that test cycle. Confirm with the vendor how long a copy of your production data takes to upgrade and test in your own environment.

Upgrade now, buy extended support or run unsupported: the trade-offs

This table compares the three paths open to an organization whose Odoo version has left standard support: upgrade, buy extended support, or run unsupported with compensating controls. Read each row against your own version, edition and hosting model, because eligibility decides which columns are open to you. The main takeaway is that extended support is a narrow option that must be confirmed with Odoo before you rely on it.

Decision factor	Upgrade to a supported version	Extended support (Odoo.sh select versions or on-premise)	Run unsupported with compensating controls
When it fits	Your version is still within standard support or you can move to a currently supported major version	Upgrade cannot happen in the near term and your version and hosting are eligible	Short bridge period while a migration is underway, with the risk formally accepted by the business owner
Security patches	Patches and bug fixes continue under standard support	Paid extended support is the only route to patches after standard support ends, for eligible versions only	No vendor security patches; exposure grows with each published vulnerability in the version
Custom module effort	Custom modules are ported to the target version, which is the main cost of an upgrade	Custom modules stay on the old version, so porting is deferred but not removed	Custom modules age further from the core, making any later upgrade larger
Hosting and edition limits	Works with Odoo Online, Odoo.sh or on-premise, subject to your plan and edition	Available only for Odoo.sh on select versions and for on-premise, not for SaaS versions	Depends on what your current hosting allows, with no vendor support behind it
Lock-in to an old platform	Lowest, because you move to a version that receives updates	Moderate, since the decision extends the life of a version you must eventually leave	High, because skills, third-party modules and integrations increasingly target newer versions
Who must confirm eligibility	Confirm the target version and upgrade path with Odoo and your partner before planning	Confirm with Odoo whether your specific version, edition and hosting qualify, and the terms, before deciding	Your own risk owner and security team confirm the controls; Odoo does not extend coverage
Compensating controls needed	Standard test and cutover controls, plus a tested upgraded database before production	Keep the patch process, access control and backups active while the extension runs	Network restriction, reverse proxy hardening, access review, backups and monitoring, documented as accepted risk
Main cost driver to ask about	Custom module porting, data validation and retesting of integrations	Extended support terms and duration, plus the upgrade work that is still due later	Ongoing security monitoring and incident response effort, which recurs for as long as the version runs

How to plan an upgrade path from an out-of-support version

This sequence turns an out-of-support Odoo database into a dated, tested upgrade plan with a known target version, a rehearsed path through each hop, and a cutover window with a rollback point agreed before production is touched.

Inventory the running installation
Record the exact Odoo version, edition (Community or Enterprise), hosting model (Odoo Online, Odoo.sh or on-premise), database size, and the installed core apps. List every third-party and custom module with its version, source and owner, and note any module that was copied in by hand or patched in place. The IT lead and the Odoo administrator sign this inventory off. It is done when every installed module appears on the list with an owner and a source, and no module is recorded as unknown.
Confirm support status and extended options
Check the version's standard support end date against Odoo's published standard and extended support documentation, and confirm with Odoo whether extended support is available for your version and hosting model. Odoo's documentation states that extended support is limited to Odoo.sh for select versions and on-premise, and that security patches come only during standard support. Ask Odoo in writing what your organization is entitled to under your subscription. It is done when a written answer on eligibility and patch coverage is on file.
Map custom modules and integrations to the target
For each custom module, third-party module and external integration, identify the target version it must run on, whether a maintained release exists for that version, and who will port it. Include API consumers, scheduled actions, reports, and any changes to the database made outside Odoo. The output is a table with one row per component showing its status (ports cleanly, needs rework, replace, or retire) and an owner. It is done when every row has a status and a named owner.
Decide the target version and any intermediate hops
Choose the target version that is inside its standard support window at go-live and will remain supported for the period your organization needs. Check Odoo's upgrade documentation to confirm whether a direct upgrade is supported from your starting version or whether intermediate major versions must be passed through. Record the decision, the hops, the reasons and the rejected alternatives in a written decision record approved by the business owner. It is done when the decision record is signed.
Run test upgrades and log every failure
Create a test database from a recent production copy, with outgoing mail, payment and integration endpoints disabled or pointed at sandboxes. Run the upgrade through each planned hop using Odoo's upgrade service or your chosen upgrade method, and log every error, warning, failed module and data anomaly in a shared register with a reproduction step. Repeat from a fresh copy after each fix so results are repeatable. It is done when a test upgrade to the target version completes and the failure register is complete, even if some entries remain open.
Fix custom code and retest
Work through the failure register with developers, porting custom modules and changing integrations to match the target version's APIs and views. Run the functional test scripts for each business process (quotes to invoices, stock moves, payroll exports, and so on) against the upgraded test database, and have process owners confirm the results. Keep each fix in version control so it can be reapplied during cutover. It is done when every high-severity item is closed and each business process passes the owner's sign-off.
Agree the cutover window and rollback point
Agree with the business a cutover window that covers the full upgrade time measured in the final rehearsal, plus time for validation and user communication. Define the rollback point as a verified backup taken immediately before the upgrade, and document the steps and the decision owner for reverting to it. Confirm who may approve a rollback and what evidence triggers it. It is done when the window, rollback point and decision owner are written into a cutover runbook that every participant has read.
Rehearse cutover and confirm go-live readiness
Perform one full dress rehearsal from backup restore through upgrade, validation and reopening, using the runbook exactly as written and timing each step. Record any deviation and update the runbook before go-live. Ask the business owner to sign a go-live readiness checklist covering the inventory, decision record, failure register and test results. It is done when the rehearsal completes inside the agreed window and the readiness checklist is signed.

What drives the cost of moving off an old Odoo version

This table lists the factors that raise or lower the effort of moving an Odoo database off a version that has left standard support. Read each row as a lever: the driver, why it changes the work, and what you can do before requesting a written quote. The main takeaway is that custom code, third-party modules and the number of version steps usually matter more than database size.

Driver	Why it changes the effort	How to keep it down
Custom and third-party modules	Each custom or third-party module must be ported and retested at every major version step, and vendor modules may lag behind a new release.	Remove unused modules, confirm which third-party modules have a version for the target release, and move logic into configuration where practical.
Number of versions between current and target	Each major release is a separate upgrade step with its own test cycle, so a database several versions behind requires several passes.	Plan the path early and ask the quote to state each intermediate version. Confirm the upgrade service options for each step.
Integrations and their vendors	Each connected system (eCommerce, banking, logistics) may need its connector updated, and some vendors must certify or update their side before go-live.	Consolidate integrations, retire unused connections and ask each vendor for its supported Odoo version and API status.
Data volume and attachment size	Larger databases and filestores lengthen upgrade runs, test copies and backup verification, and increase hosting needs during testing.	Archive closed records and old attachments before the upgrade, and agree in writing what history must be retained.
Number of environments	Development, test, staging and production each need the upgraded database and a retest, so more environments mean more cycles.	Keep the environment count to what the test plan needs and reuse neutralized database copies for test runs.
Users, companies and access rules	More companies, record rules and access groups increase test cases and the reconciliation needed to show data is correct after the move.	Simplify access groups and company structure where the business allows, and document the expected results for key roles.
Compliance evidence per step	Regulated organizations often need change records, test results and sign-off for each upgrade step, which adds documentation work.	Agree the evidence list up front, such as test scripts, reconciliation reports and approval records, and ask whether it is produced per step or once.
Hosting and extended support terms	Extended support and hosting costs depend on the edition, hosting model and version, and are paid to the vendor or hosting provider, not to the implementation partner.	Confirm with Odoo which extended support options apply to your version and hosting model, and ask the quote to separate vendor fees from services.

Extended support on Odoo.sh, on-premise and SaaS

Odoo.sh can offer paid extended support for select versions after standard support ends. Whether a particular version qualifies is decided by Odoo, so you should not assume that a version you are running is covered. Standard support on Odoo.sh covers the first three years after a major release, including security updates and bug fixes. Once that window closes, security patches are only provided during standard support, so an uncovered version carries open exposure.

What changes for the upgrade path

Major version upgrades are mandatory every two years on Odoo.sh, so extended support does not remove the need to move forward.
Test the upgraded database before cutover, since custom modules are often the longest part of the move.
Plan the upgrade inside the standard support window where possible, not after it closes.

What your team controls

The timing of upgrade projects within the mandatory cycle.
Custom code, third-party modules and the compatibility review before each move.
Whether to request extended support for a specific version, once Odoo confirms availability.

What to confirm with Odoo

Which versions are currently eligible for paid extended support on Odoo.sh, and for how long.
The price and contract terms for extended support, and whether it requires a particular plan.
The date by which the version must be moved, if extended support is not renewed.

Reducing exposure while a version is out of support

Once an Odoo version leaves standard support, it no longer receives security patches, so the controls around it carry the load. The cards below cover the compensating controls that reduce exposure on an on-premise or Odoo.sh database, and each one is a decision to confirm, not a substitute for patching.

Restrict administrative and database manager access

The Odoo database manager and master password are high-value targets on an unpatched version. Confirm that the database manager is disabled or reachable only from administrator networks, that the master password is long and stored outside the configuration file in a secrets vault, and that the list of users with administrator rights is short and reviewed on a schedule. Record who can change these settings and who approves changes.

Terminate TLS at a reverse proxy

Place Odoo behind a reverse proxy that handles TLS, so the application server is not exposed directly to users or the internet. Check that only supported TLS versions and strong cipher suites are enabled, that the Odoo web port is not reachable from outside the proxy, and that the proxy is patched on its own schedule. Confirm the proxy settings with your security team before the first change.

Limit inbound exposure to required networks

Restrict network paths to Odoo and PostgreSQL to the address ranges that need them, such as office networks, VPN users and the reverse proxy. The database port should never accept connections from user networks. Review firewall rules and cloud security groups at least once a quarter and after any change to the hosting environment, and record each rule's owner.

Review third-party modules before any change

Community and vendor modules added to an unsupported version can carry known weaknesses that no Odoo patch will fix. Build an inventory of every installed module with its source, version and owner, then check each one against vendor advisories and public vulnerability databases. Require this review before any module is installed, updated or removed, and retire modules that have no active maintainer.

Control sign-in with documented methods

Odoo documents sign-in through LDAP, with optional user creation on first login from a template, as well as Google Sign-In, Microsoft Azure OAuth, Facebook sign-in and two-factor authentication. Use a directory-backed method where your organization already manages identities, enable two-factor authentication for administrators at minimum, and disable local password logins for accounts that no longer need them. Confirm each method's behavior on your exact version in the Odoo documentation.

Keep tested backups available

Backups are the recovery path if a compensated control fails. Confirm that database and filestore backups run on schedule, are stored off the Odoo host, and are encrypted in transit and at rest. Restore a copy to a separate environment at a regular interval and check that the application starts and that the data matches expectations. A backup that has never been restored is not evidence of recovery.

How to prove the upgraded database works before cutover

Before an upgraded Odoo database replaces production, the team needs written evidence that it behaves like the source system for the business processes that matter. The upgrade service moves a database to a newer supported version through an upgraded test database, and Odoo's documentation expects that test database to be tested before production is touched. Treat that test database as the candidate for cutover, and agree in advance what evidence will show it is ready. The checks below apply to every edition and hosting model covered in this section, though the tooling differs between Odoo Online, Odoo.sh and on-premise installations.

Start with data reconciliation. Compare record counts for each model that carries business value, including partners, products, open sales orders, open purchase orders, invoices, journal entries, stock moves and employee records. Then compare key totals: receivables and payables balances by account, inventory valuation by warehouse, and open order values. Export the same reports from source and target using the same filters and date ranges, and record every difference. A difference is not automatically a failure, but each one needs a named cause, such as a rounding change, a changed default or a module that now computes a field differently. Ask the partner or internal team to document the reconciliation query or report used, so the check can be repeated on the final cutover copy.

Custom modules and integrations are the most likely point of failure, so exercise each one on a test copy. List every custom module, third-party module and external API connection, then run the business transactions they support from start to finish. For example, if a custom module adds a approval workflow to purchase orders, create, approve and post a test order and confirm the resulting journal entries. Check each integration's inbound and outbound messages against the test scenarios. Confirm that scheduled actions and automated rules behave as expected in the new version. Record which modules were ported, which were disabled and which were replaced by core functionality, since that list also feeds the rollback decision.

Test copies of production must be neutralized before anyone logs in. Odoo documents database duplication with neutralization for test copies, and the neutralization step disables scheduled actions and outgoing mail servers, among other things. Confirm this step was applied to every test copy, and do not rely on memory or a checklist alone. A test copy that still holds live payment gateway credentials, active email servers or connections to real bank, logistics or eCommerce endpoints can send real emails, charge real customers, post real transactions or update live stock. Check outgoing mail, payment providers, webhooks, API keys and scheduled jobs directly in the test database, and block external network egress where your environment allows it.

Sign-in and access rights need their own test pass. For each user group, sign in with a representative test user, confirm the menus, records and actions visible match the design, and confirm that record rules and field-level restrictions behave as expected. If you use LDAP, Google Sign-In, Microsoft Azure OAuth or two-factor authentication, test each path on the test copy, since identity settings are part of what the upgrade must preserve. Finally, define the failure criteria and the rollback point before cutover. Examples include any unexplained financial total difference, any integration that sends a live message from the test copy, or any access rule that exposes data beyond its group. Agree who can call a stop, and record the last point at which production can be restored unchanged.

Can we stay on an Odoo version after standard support ends?

Can we keep running an Odoo version after standard support ends?

Yes, the software keeps running, but the version stops receiving security patches once standard support ends, except where a paid extended support option applies. Odoo's documentation says security patches are only provided during standard support, so the risk grows as known vulnerabilities in that version become public. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise. Before deciding to stay, confirm with Odoo which versions and hosting types still have extended support, what that contract includes, and how long you would be exposed without patches. Document the decision and the compensating controls you put in place, such as network restrictions and a tighter reverse proxy configuration, so the risk owner can sign off on it.

What does Odoo extended support cover and where is it offered?

Extended support is a paid option that Odoo offers after standard support ends, and per its documentation it is limited to Odoo.sh for select versions and to on-premise deployments. It is not available for Odoo Online, and Odoo's SaaS versions, which are released every two to three months, cannot use it. Security patches are not part of the extended period according to Odoo's documentation, so treat extended support as a way to keep receiving some level of vendor service, not as a patch guarantee. Ask Odoo for the written list of covered versions, the scope of fixes, the price and the end date before you plan around it. Your partner can help you compare that scope with your upgrade timeline.

Do we need a partner to upgrade an out-of-support Odoo database?

A partner is not strictly required, but an upgrade from an old version usually involves work beyond the database conversion itself. Odoo's upgrade service moves a database to a newer supported version and produces an upgraded test database that you should test before production. For on-premise systems, that service requires an Enterprise subscription. The harder work is often custom and third-party module porting, data validation, integration checks and user acceptance testing. If your module inventory is small and your team has done Odoo upgrades before, you may handle it internally. If you have many custom modules or several skipped versions, a partner can take responsibility for the plan, the build and the test evidence under a written scope.

Can we use the Odoo upgrade service with the Community edition?

No. Odoo's documentation states that the Community edition has no access to the upgrade service, and on-premise use of the service requires an Enterprise subscription. If you run Community and want Odoo's upgrade path, you need to move to Enterprise first, which involves subscription activation, checking the installed modules and testing the migrated database. Alternatively, you can plan a manual upgrade using your own scripts, migration tools and a full test cycle, which takes more internal effort and more ongoing ownership. Compare the subscription cost with the internal or partner effort for each route. The Community to Enterprise migration and the upgrade path should be decided together, because a switch changes what you can use for each future upgrade.

What drives the cost and time of an Odoo version upgrade?

The main drivers are the number of major versions you must cross, the number and depth of custom modules, the use of third-party apps, the size and age of the data, and the number of integrations that depend on the database. Each custom module that inherits core models or views may need porting at every version, and each integration may need its own test cases. Testing cycles, user acceptance testing with business staff and the hosting environments you need for test and production also add time. Ask any provider for a fixed-scope quote that lists the modules to port, the versions covered, the test cycles, the environments and the cutover plan. A quote that does not list those items cannot be compared on a like-for-like basis.

What does our team need to provide for an Odoo upgrade project?

Your team provides the decisions and access that the upgrade cannot proceed without. Typically this includes:

A module inventory listing core apps, custom modules, third-party modules and their versions
A named decision owner who approves scope, cutover timing and acceptance
A test copy of the production database, duplicated and neutralized so no live emails or payments are triggered
Access to the source code, hosting environments and integration endpoints
Business users who can run user acceptance tests against the upgraded test database

Confirm each item in writing at the start of the engagement. Missing inventory or late access to test data are common causes of schedule slippage, so agree on who owns each item and by what date it is due.

Can our own team upgrade an out-of-support Odoo instance?

Your team can upgrade an instance if it has working knowledge of Python, PostgreSQL and the Odoo framework, time to run full test cycles, and access to the upgrade documentation and tools. The deciding factors are the amount of custom code, the number of skipped versions and whether the upgrade service is available to you. Start with an assessment: inventory every module, run the upgraded test database, and record every error and manual fix. If the list is short and the business accepts a longer test period, an internal upgrade can work. If the list is long, or if the same people are also responsible for daily operations, a fixed-scope engagement with DeployOpen or another partner can take on the upgrade while your team keeps the system running and supplies the business knowledge.

How often must Odoo major versions be upgraded on Odoo.sh?

According to Odoo's upgrade documentation, major version upgrades are mandatory every two years on Odoo Online and Odoo.sh. That requirement shapes the budget and planning cycle for those hosting types, because you cannot postpone the upgrade indefinitely and expect the platform to keep working as before. For on-premise systems, Odoo's standard support window is the key timing signal, and you should plan the next upgrade before the current version's standard support ends. Put the upgrade date into your change calendar, decide which environment will be the first test target, and make sure the custom code and integrations are reviewed before each cycle begins. Confirm the exact dates for each version in Odoo's current support documentation.

Official Odoo sources for support dates and upgrades

Before you decide what to do about an Odoo version that is leaving standard support, check the dates and terms against Odoo's own documentation, not against a summary or an old internal wiki page. The standard and extended support page is the first source to read. It sets out which versions receive security updates and bug fixes, how long standard support runs after a major release, and whether extended support is offered for your deployment type. Confirm the exact end date for your version there, and note that security patches are only provided during standard support.

The upgrade documentation is the second source. Read it for the mechanics of moving a database to a newer supported version, including the upgraded test database that should be tested before production cutover. Check the statement that major version upgrades are mandatory every two years on Odoo Online and Odoo.sh, and confirm with Odoo whether the same cadence applies to your hosting model. Also confirm what the upgrade service requires in terms of subscription, since access depends on your edition.

The on-premise documentation tells you what your self-hosted deployment needs to stay supported. Check how Enterprise databases are activated with a subscription code, how packaged installers and source installations differ, and how database duplication with neutralization is used to create test copies. The source installation page is the place to confirm your installation path, since the steps you take to install, patch and test a self-hosted version depend on it. Treat any gap between your current installation method and the documented one as a item for the upgrade plan.

The pricing page is where you confirm plan limits that decide your options. Check which plans allow Odoo.sh or on-premise hosting, and which include custom modules, Odoo Studio and external API access. A version path that works on one plan may not be available on another, so confirm your current plan against the page before you commit to a hosting model. Pricing changes over time, so ask for the current terms in writing as part of the quote.

Finally, the Odoo GitHub repository documents the Community edition license, which is LGPL-3.0. Check the license file and the repository's release branches if you run Community code, and confirm whether your database or modules depend on any Enterprise-only code. Enterprise source is not publicly available, so any Enterprise dependency has to be verified against your subscription, not the public repository.

How DeployOpen scopes, upgrades and supports Odoo off old versions

DeployOpen plans, implements and supports self-hosted Odoo inside the client's own infrastructure, including databases that have left standard support. We start by confirming which version and edition are in use and what the upgrade path to a supported release requires, then agree the work in writing before any build starts.

How we scope

Confirm the installed Odoo version, edition, hosting model and the date standard support ended for it.
Inventory custom modules, third-party apps and integrations, since each one must be checked against the target version.
Agree a fixed-scope document covering deliverables, test cycles, cutover steps and the target version before work starts.

How we build

Restore a copy of the production database to a test environment and run the upgrade on that copy first.
Port custom modules and configuration to the target version, then test business processes against the upgraded copy.
Record each change, test result and open issue so the client can reproduce the upgrade on later cycles.

How we hand over

Deliver runbooks for the upgrade, rollback, backup verification and post-cutover checks.
Document the final version, edition, module list, custom code locations and known limitations.
Walk the client's administrators through the upgraded system and the operating procedures before closing the engagement.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the project closes.
Plan the next major version upgrade early so it can be scheduled within the vendor's support window.
Confirm with the vendor which extended support options apply to the hosting model and version in use.

Odoo end-of-support versions and extended support