In brief Odoo 17 left support in September 2026: no more security patches or standard assistance. The right strategy is to prepare the inventory and scoping work in November, then go live in December or January, once the migration script for the target version has been sufficiently tested. Waiting a few extra weeks costs little; running a migration twice costs a great deal.
An IT manager called us in October. His database was running on Odoo 17, everything looked fine and he wanted to migrate "before the end of the year". We asked him one question: "Have you checked the status of the migration script for the target version?" Long silence. Odoo 17 is out of support: wait for the version 20 migration script before setting a go-live date. That is what we explained to him.
What end of support actually means
Odoo provides three years of standard support for each major version: bug fixes and security updates. For version 17, that support ended in September 2026, when Odoo 20 was released. Version 18 remains covered until September 2027, version 19 until September 2028 and version 20 until September 2029.
Beyond standard support, an extended support option exists, but it is paid, unavailable on Odoo Online and limited to fixes that are technically feasible. On Odoo.sh, staying on an unsupported version is simply not possible. On-premise, it is technically doable, but without any security patches.
The urgency is therefore about security, not about a migration deadline: Odoo allows you to migrate from any version to a version that is still supported. No path closes on the tool's side.
Why the migration script drives the timeline
Think of the migration script as the kitchen brigade of a restaurant that has just opened. The dining room may be ready and guests seated, but if the brigade has not yet refined its recipes, service falls apart. A migration script transforms real data into a new structure, from accounting entries and stock valuations to taxes and document histories. Its quality determines the quality of the entire project.
A script published alongside a major version is a young script. Early feedback from integrators reveals uncovered cases: atypical charts of accounts, multi-company setups, multiple currencies, old data. A well-managed Odoo migration requires a stable script, not one that is still being corrected.
Working on an unstable script has three direct consequences. First, every test run must be repeated if the script changes between two rounds of user acceptance testing. Second, users check their balances and stock levels during testing: if the script changes afterwards, their work has to be done again. Third, a successful test on an unstable script can give false reassurance and hide an issue that the next script correction would have uncovered.
The cost of waiting a few weeks is low, since the version 17 database keeps working. The cost of running a migration twice is very real.
What should not wait
Waiting for the script does not mean sitting still. All the work that does not depend on the script can move forward now and it often represents half of the total effort.
- Inventory of installed modules, customisations, connectors and bespoke reports.
- A decision for each development: keep it, replace it with standard functionality or drop it.
- Checking the availability of each third-party module in version 19 or 20.
- Data cleansing: duplicates, obsolete accounts, dormant products.
- Choosing the target version: 19 or 20.
This scoping work happens in November, before year-end activity picks up. In our experience, the process review carried out at this stage almost always uncovers forgotten customisations or ones inherited from a previous provider with no documentation. That is the real workload.
Why you should not wait indefinitely either
Every month without security patches adds exposure. Four concrete risks accumulate: no security updates outside a paid option, third-party modules that stop being maintained for version 17, technical debt that grows with each skipped version and electronic invoicing compliance.
On that last point, receiving electronic invoices has been mandatory for all businesses since 1 September 2026 and issuing them will be mandatory for SMEs from 1 September 2027. A tool that is out of support does not guarantee compliance with these flows. For more information on the requirements currently in force, see our page on electronic invoicing with Odoo.
That is why we target December or January and not the spring.
19 or 20: how to choose
Version 19 is mature, covered until September 2028 and its migration script is well tested. Third-party modules are widely available for it. It is the cautious choice and there is nothing wrong with that.
Version 20, released in September 2026, brings genuine improvements to data entry, usage-based licensing and automation. It also integrates AI in a particularly advanced way: the Enterprise 20 edition includes 52 AI modules compared to 15 in version 19, with active agents covering sales, purchasing, inventory, project management and helpdesk. Its support runs until September 2029. By December, its script will have three months of real-world feedback behind it, which is sufficient for a client whose critical modules are available.
If an essential module does not yet exist in version 20, we choose version 19 without hesitation and prepare the next upgrade calmly. The target always follows from the inventory, never from novelty for its own sake.
The timeline we recommend
November: scoping. Inventory, decisions on developments, data cleansing and checking module availability in the target version.
Late November and early December: test migrations on a copy of the database, user acceptance testing on their own processes. If an issue appears, it is flagged and resolved before go-live. A rollback plan is prepared and tested.
December or January: go-live. December suits businesses whose activity slows at year end: services, manufacturing and associations. January suits retail and distribution, which do not touch anything during the holiday period. The switch then coincides with the start of the new financial year.
February and March: buffer to absorb the unexpected. After March, every month without security patches becomes a risk that is increasingly difficult to justify.
With Odoo Enterprise, the upgrade to the latest version is included in the subscription. Many businesses come out of it with fewer custom developments than before and a cleaner system. The Odoo licence is offered by the publisher at €35.90 per user per month in the first year, then €44.90 from the second year onwards, all applications included.
We are currently supporting several upgrades from version 16 and from version 17. The same pattern keeps repeating: data migrates cleanly, undocumented customisations cause problems. Start with the inventory this week: note the exact version of your database, list your third-party modules and identify the processes that must never be interrupted. We offer a complimentary situation audit to establish this diagnosis before setting a date.
The timeline always follows from the audit, never the other way around. Spend 30 minutes with a consultant to get a clear picture before November is over.
Frequently asked questions
Can you stay on Odoo 17 without migrating?
On Odoo.sh, this is not possible once the version is out of support. On-premise, it is technically feasible but without any security patches. Every additional month of exposure increases the risk.
Why not migrate as soon as the version 20 migration script is released?
A script published alongside a major version is still young. The first months of integrator feedback reveal uncovered cases. Working on an unstable script means having to redo user acceptance testing and can hide issues that are only fixed by a later script correction.
Is it better to target Odoo 19 or Odoo 20?
If your critical modules are available in version 20 and your database is relatively standard, aim for version 20 with a go-live in December or January. Otherwise, version 19 is a solid choice, covered until September 2028 with a well-tested script.
What should you do if you have specific customisations or third-party modules?
Start by checking the availability of each third-party module in the target version. For custom developments, decide whether to keep them, replace them with standard functionality or drop them. That is the real workload of a migration.
How long does an Odoo migration take in practice?
Between 2 and 9 months depending on the complexity of the database and the number of customisations. For a database that has stayed close to the standard, an upgrade can be completed in a single day.