Odoo 18 to 19 upgrade

The 18.0 deadline is the first date to write into the upgrade plan. Odoo 18.0 was released in October 2024, and its standard support runs until September 2027. Standard support covers the first three years after a major release, including security updates and bug fixes. Security patches are only provided during standard support, so an 18.0 database that is not covered by another support path will stop receiving them after that date. Work backward from September 2027 through the test database, the rehearsal and the production cutover, and confirm the date your change calendar must respect.

Extended support is not a safe fallback unless Odoo confirms it in writing. Paid extended support is limited to Odoo.sh for select versions and to on-premise deployments. Whether 18.0 is listed for your hosting type is a question for Odoo, and the answer should be in your file before you plan around it. Do not assume an extension that is not on the published list. Odoo Online databases cannot use extended support at all. Odoo.sh and Odoo Online also require major version upgrades every two years, so the 18.0 window is not the only upgrade your team will face on those platforms.

Hosting type changes how much time you have. Odoo SaaS versions are released every two to three months, and Odoo Online cannot use extended support, so an Online database follows a faster release cycle than a self-managed one. Check which plan and hosting type each database runs on. On the pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. If a database uses custom modules or the external API, it is almost certainly on a hosting type that depends on the support rules above, so confirm that before setting the date.

The choice is between moving to 19.0 now and jumping to 20.0. Odoo 19.0 was released in September 2025, and its standard support runs until September 2028. Odoo 20.0 was released in September 2026, with standard support planned until September 2029. Jumping to 20.0 gives a longer standard support window but adds the 20.0 changes to the project, and it depends on whether your team can test that version in time. Compare the two paths using the trade-offs on the Odoo 19 to 20 upgrade page, and decide before the module porting and test database requests begin, because that decision changes the scope of both.

A test pass should show that the upgraded Odoo 19 database produces the same business results as the 18 database for the processes your organization runs. Scope the pass before anyone starts testing. Accounting reconciliation comes first: bank statement matching, open invoice and payment reconciliation, aged receivables and payables, and period-end reports should be compared line by line against 18 figures taken from the same source data. Tax results need their own check. Rerun a representative set of customer invoices, vendor bills and credit notes under each fiscal position your business uses, and compare the computed tax lines with the 18 results. Where the fiscal position tax mapping differs, record every change and get the tax owner's written sign-off on each one. The second part of the pass covers workflow approvals, scheduled actions, email and document templates, reports, and every external integration call. Approval paths should be walked through with real role holders in the test copy, including the rejection and escalation branches. Confirm which scheduled actions are active on the test database and which should stay disabled. Templates should be rendered and checked for layout, language and merged fields. Integrations need the most care. Payment providers, shipping carriers, banks, identity providers and any custom code calling the external API, including calls that move to the JSON-2 external API, should be tested against sandbox endpoints. Confirm with your partner what the neutralization step disables in the test copy, so no live emails, payments or bank files leave the test environment. Rollback depends on one rule: keep the 18 database and filestore untouched until the 19 cutover has been accepted. Do not run the migration against the only copy of production data. Work from a copy, and keep the original in its current state with its backups verified and restorable. Before cutover, write the go or no-go criteria down. Typical criteria include zero unexplained differences in bank reconciliation and tax reports beyond a tolerance the finance lead has agreed, every approval path completing, every integration returning the expected responses, and named owners signing the test results. Decide who can make the call. A single decision owner, usually the executive sponsor, should hold the authority to proceed or roll back, with the finance lead and the IT lead giving written input. Agree in advance what triggers a rollback decision and how long the team has to reach one. Rolling back after users have posted new transactions on 19 is not a simple restore. Any invoice, payment, stock move or attachment created on 19 would be missing from 18 after a restore, so a reconciliation plan is required before that point arrives. The plan should list how post-cutover transactions are exported from 19, how they are replayed or re-entered into 18, and how the team checks that balances, open items and filestore attachments match afterward. Decide the cutoff point in advance and write it into the runbook. Most teams pick the moment the production 19 database opens for posting, or a short freeze window agreed with the finance lead. Confirm the exact steps and effort with your partner before cutover, because the reconciliation work grows with every hour that users keep posting on 19.