Odoo 20 was released on 24 September 2026, and the first question we hear from finance teams is not about features. It is about timing: do we have to move, and when? The honest answer depends on which version you run today, how much custom code sits on top of it, and whether your e-invoicing integration is stable. This article sets out how we think about the decision and the test plan we use, written for the finance team that will sign off the result.
How long is each Odoo version supported?
Odoo supports each major version for three years. According to the Odoo 20 release notes and its published support policy, the planned end of standard support is September 2026 for 17.0, September 2027 for 18.0 and September 2028 for 19.0, which puts Odoo 20 at roughly September 2029. Community and Enterprise share one version number, so the calendar is the same for both, although what is included in each edition is not.
What should a company on Odoo 17 do?
Plan the upgrade now. September 2026 has arrived, and running a finance system outside standard support means fixes and upgrade assistance are no longer something you can count on. That does not mean upgrading next week. It means choosing a target version, booking the test window and freezing non-essential customisation so the scope stops moving. For most companies on 17, the target will be Odoo 20 rather than 18 or 19, because it buys the longest support horizon.
What about Odoo 18 and Odoo 19?
On 18, aim to upgrade within the next twelve months. Support is planned to run to September 2027, which leaves time for a calm project, but not for an indefinite delay that pushes the work into year-end. On 19, there is no deadline pressure until 2028. Upgrade when a specific Odoo 20 feature pays for itself, for example the inventory valuation changes or the duplicate detection on invoices and bills described in the release notes, and not simply because a new version exists.
Can you jump straight from 17 to 20?
On Enterprise, yes. Odoo’s upgrade service can take a database across several versions in one request, for example from 17 to 20. It saves calendar time, but skipping versions raises testing risk: data is transformed through several migration steps at once, and any difference you find is harder to attribute to a single change. If you skip versions, budget more testing, not less. Community databases and custom modules need their own migration route, which is a separate conversation about code.
What does a finance-first upgrade test plan cover?
Most upgrade tests check that screens open and buttons work. A finance-first test checks that the numbers did not move. We run the upgrade on a copy of production and test in this order:
- Trial balance tie-out: print the trial balance at the same date before and after, by account, and explain every difference to zero.
- Open items tie-out: compare open receivables, open payables and unreconciled bank lines, by partner and by document, before and after.
- Taxes: confirm every tax, tax grid and fiscal position survived, then rebuild the last filed VAT return from the upgraded database and compare.
- E-invoicing: re-test Egypt’s ETA or Saudi Arabia’s ZATCA integration in the authority’s sandbox or pre-production environment before go-live, including credit notes and rejected documents.
- Custom modules: list every custom module, decide to migrate, replace with standard features or retire, and test each one that touches accounting.
- Access rights: check that roles, approval limits and segregation of duties look the same after the upgrade as they did before it.
Expect some behaviour to change on purpose. According to the Odoo 20 release notes, journal entries that affect bank accounts must now originate from bank transactions, which stops manual entries that break bank consistency. If your team posts bank charges or transfers by manual journal entry today, that habit has to change, and the test should prove the replacement process works.
An upgrade is finished when the trial balance agrees, not when the login screen loads.
Why run a parallel close of one month?
Because a close exercises everything at once: reconciliations, accruals, depreciation, inventory valuation, tax and reporting. We close one recent month in the upgraded test database, following the same month-end close checklist the team uses in production, and compare the financial statements with the ones already approved. Differences found here cost an afternoon. Differences found after go-live cost a restatement.
How should cut-over and rollback work?
Pick a cut-over date right after a month is closed and locked, never in the middle of a period. Freeze posting, take a final backup, run the production upgrade, then repeat the trial balance and open items tie-out on the live result before users return. Agree the rollback rule in advance: who decides, by when, and what triggers it. If the tie-out fails and cannot be explained within the agreed window, you restore the backup and try again, rather than fixing the ledger by hand under pressure.
Who should own the decision?
The finance lead, with IT and the implementation partner in support. Our Odoo implementation and upgrade team at MFT starts every upgrade with the tie-out templates above, because the people who will defend the numbers to auditors should be the ones who accept them.