Certified Odoo Implementation Partner
Odoo Version Upgrade Services in Canada
The upgrade keeps getting postponed, and the reasons are good ones. Every time the newer Odoo version comes up, the same bad week plays out in advance: the custom module nobody documented, the provincial tax setup that took months to get right, the invoice layout your controller finally trusts.
Here is what usually gets left out. On Odoo Online the upgrade is mandatory, and doing nothing by the deadline means it runs automatically on a date Odoo picks. On Odoo.sh and on-premise the timing is a choice, and Odoo 17 standard support is set to end September 2026. Done properly, an upgrade is a cleanup: every customization gets challenged against what the new release already does on its own, and the ones it covers stop being yours to maintain.
- Certified
- Odoo Ready Partner
- Calgary, Alberta
- Serving Canadian businesses
- Discovery first
- Timeline confirmed by scope
By Aksh Raheja, Founder of Solvync.
Support lifecycle
Which Odoo version am I on, and is it still supported?
Odoo provides standard support for three years per major version, covering helpdesk, bug fixing and security updates. Beyond that, extended support carries a mandatory additional fee and covers helpdesk and bug fixes depending on feasibility. Upgrades can only target a supported version, and the most recent end-of-life version stays available as a target for six months past its end date.
| Version | Released | Standard support ends | Odoo Online | Odoo.sh | On-premise |
|---|---|---|---|---|---|
| Odoo SaaS 19.4 | July 2026 | Not published | Supported | Never released | Never released |
| Odoo SaaS 19.3 | May 2026 | Not published | Supported | Never released | Never released |
| Odoo SaaS 19.2 | March 2026 | Not published | Supported | Never released | Never released |
| Odoo SaaS 19.1 | January 2026 | Not published | Not supported | Never released | Never released |
| Odoo 19.0 | September 2025 | September 2028 (planned) | Supported | Supported | Supported |
| Odoo SaaS 18.4 | July 2025 | Not published | Not supported | Never released | Never released |
| Odoo SaaS 18.3 | May 2025 | Not published | Not supported | Never released | Never released |
| Odoo SaaS 18.2 | March 2025 | Not published | Not supported | Never released | Never released |
| Odoo 18.0 | October 2024 | September 2027 (planned) | Supported | Supported | Supported |
| Odoo 17.0 | November 2023 | September 2026 (planned) | Supported | Supported | Supported |
| Odoo 16.0 | October 2022 | September 2025 | Not supported | Extended (fee) | Extended (fee) |
| Odoo 15.0 | October 2021 | October 2024 | Not supported | Extended (fee) | Extended (fee) |
| Odoo 14.0 | Before 2021 | Before 2024 | Not supported | Extended (fee) | Extended (fee) |
| Older versions | Before 2021 | Before 2024 | Not supported | Not supported | Extended (fee) |
Intermediary online releases ship every two to three months, run on Odoo Online only, and are not eligible for extended support.
Readiness checker
Check where your database stands
Pick the current setup below. Everything it reports comes from the table above and the version requirements further down, so it surfaces nothing this page does not also state in full.
Odoo 16.0 has left standard support. Extended support carries a mandatory extra fee.
- Extended support onlyStandard support ended September 2025. Extended support covers helpdesk and bug fixes depending on feasibility. Security updates are not listed among what it covers.
- You have a defined windowOn Odoo.sh you get two further years after the initial three to complete the upgrade, and Odoo notifies you in the project when one is required.
- Database conversion is includedWith Odoo Enterprise the conversion itself is free, and you submit one request naming your target version. The platform steps through intermediate versions internally rather than asking you to run each one.
- Custom modules are outside the free upgradeModules with no maintenance contract are excluded, in-house and third-party alike, including those built by Odoo partners. Each one has to install cleanly on an empty database of the target version, then on your upgraded copy, before production can move.
- Canadian configuration needs revalidationOdoo notes that when upgrading to a version with additional modules, some modules may not install automatically. After the conversion, recheck the 14 default fiscal positions, the sales and purchase taxes, the EFT and CPA005 file format, and the cheque layouts.
- Validation stays with youOdoo's agreement puts verifying the upgraded database, analyzing the impact of changes, and adapting third-party extensions on the customer. That is the work an upgrade project actually consists of.
Several of these only resolve once someone opens the database: which custom modules actually still earn their place, which integrations break, and what your tax configuration does after the conversion.
Forty-five minutes, free, on your screen. No system access needed.
What you pay for
Is the Odoo upgrade free?
Upgrading to the most recent version is free with an Odoo Enterprise subscription, including support to correct discrepancies in the upgraded database. The free part is the technical conversion. It helps to be precise about where that ends.
Covered by the subscription
- All standard applications.
- Every customization built with Studio, while Studio stays installed and the subscription stays active.
- Any development covered by a maintenance of customizations subscription, which Odoo calls a Covered Extra Module.
Not included
- Cleaning pre-existing data and configuration during the upgrade.
- Modules with no maintenance contract, built in-house or by a third party, including those built by Odoo partners.
- Training people on the new version's features and workflows.
It is the responsibility of the Customer to verify and validate the upgraded database in order to detect Bugs, to analyze the impact of changes and new features implemented in the Target Version, and to convert and adapt for the Target Version any third-party extensions of the Software that were installed in the database before the upgrade.
That clause is the whole commercial picture in one sentence. Odoo converts the database. Verifying it, adapting anything custom and getting your team working again is the project, and it is the part worth planning properly. If custom code is the bulk of your risk, how custom modules are built and maintained decides how expensive every future upgrade is.
- Clarify the need
- Control the scope
- Plan the next step
Find out what your upgrade actually involves
Book an Odoo Upgrade Readiness Review. Forty-five minutes, free, screen-share only, and it ends with your support status confirmed, the version to target, and the custom modules and integrations that are at risk.
Enterprise and Community
Can you skip Odoo versions when you upgrade?
Yes, on Odoo Enterprise. One upgrade request names the target version, and Odoo's upgrade platform moves the database through each intermediate major version itself. The Odoo Enterprise Subscription Agreement, section 4.3, states that a customer may convert a database from any version of the Software to a more recent Covered Version. Internally the platform still steps through the versions in order, which is why a large gap takes longer even though it stays one request from your side.
Odoo Community works differently. Community databases have no access to Odoo's upgrade platform, and the community route is OpenUpgrade, a project maintained by the Odoo Community Association that publishes migration scripts between major versions. Those scripts are written for one major version step at a time, so an Odoo 15 to Odoo 19 Community upgrade runs as separate OpenUpgrade steps that an in-house developer or a partner sequences and validates manually.
Two limits apply to both editions. The target has to be a supported version, and custom modules are excluded from the automatic conversion in every case, so a database carrying custom code cannot be upgraded until those modules have a version built for the target release.
One thing an upgrade never covers is switching editions. Moving from Community to Enterprise is a separate change with its own procedure, and moving between hosting types is separate again. Where those come up together, sequence them deliberately instead of assuming one request handles all three.
Compatibility
What Python and PostgreSQL versions does each Odoo release need?
Odoo 19.0 raised the PostgreSQL minimum from 12 to 13. Odoo 20 raises Python from 3.10 to 3.12 and PostgreSQL from 13 to 16. For an on-premise database, crossing those floors is an infrastructure project that has to land before Odoo is touched.
| Odoo release | Minimum Python | Minimum PostgreSQL |
|---|---|---|
| Before Odoo 17 | 3.7 | 12 |
| Odoo 17.0 | 3.10 | 12 |
| Odoo 18.0 | 3.10 | 12 |
| Odoo 19.0 | 3.10 | 13 |
| Odoo 20 | 3.12 | 16 |
These are the floors for the major releases, which is what Odoo.sh and on-premise databases run. A database already on Odoo Online intermediary release 19.3 or 19.4 sits on the Python 3.12 and PostgreSQL 16 floors today.
By hosting type
How the upgrade actually runs
The sequence is the same everywhere: request an upgraded test database, bring custom module code up to the target version, test it thoroughly, report anything broken to Odoo, then plan and request the production upgrade. What differs is how you start it and what happens if it fails.
How an Odoo Online upgrade runs
You start from the database manager: select the database, click Manage, then Upgrade. You choose the target version, an email address to notify, and whether the purpose is Test or Production.
Odoo runs a silent test upgrade of every database that is due. If that test succeeds and finishes in under twenty minutes, you can trigger the upgrade yourself from inside the database.
Once you request the production upgrade the database is unavailable until it finishes, and reverting to the previous version is impossible. Request a test database first and spend real time in it.
How an Odoo.sh upgrade runs
Odoo.sh is wired into the upgrade platform directly. The latest production daily backup is sent up, and the branch then enters a special mode where every commit restores the upgraded backup and updates all custom modules, so you test your code against a pristine upgraded copy. The log lands in ~/logs/upgrade.log.
On production the upgrade triggers as soon as a new commit lands on the branch, which is what synchronizes the database conversion with the deployment of your upgraded module code. With no custom modules it starts immediately.
If anything fails the platform reverts automatically, and on success it keeps a backup taken before the upgrade. Confirm your staging upgrade reports success before going near production.
How an on-premise Odoo upgrade runs
Odoo documents a single command, run on the machine hosting the database. Swapping test for production runs the real one.
Two things catch people here. The script needs outbound TCP 443 and any random port between 32768 and 60999, which a restrictive corporate firewall will block. And the database is submitted without its filestore, so the returned copy has no filestore either and must be merged with production's before you can test under real conditions.
Only the person who submitted the request can download the result. Once you upload for a production run, any change made in production afterwards will be absent from the upgraded copy, so stop using it during the process.
python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>Before go-live
Testing an upgraded database
An upgraded test database is neutralized, which surprises people who expect it to behave like production. Scheduled actions are disabled, outgoing mail servers are archived and replaced with a fake one, payment providers and delivery carriers are reset to test, and bank synchronization is switched off.
Odoo publishes a starting checklist worth running literally: are there views deactivated in test but active in production, do the usual views still display correctly, do invoices and sales orders still generate, do website pages work, can records still be created and modified, are mail templates and saved translations intact, are the saved search filters still there, and does export still work.
Beyond that, run one product end to end. Buy it, receive it, check the receiving route matches production, sell it to a customer, ship it, validate the invoice, then credit the invoice and confirm the credit note behaves the way it did before. Taxes, currencies, bank accounts and the fiscal year are worth checking in the same pass.
The items most often skipped are the ones that hurt: integrations with external software over EDI and APIs, workflows that cross between apps, data exports, automated actions, and server actions triggered both from a form view and from a multi-record selection on a list view.
Odoo recommends fully rehearsing the upgrade the day before running it on production, and requesting a fresh test database periodically if the project runs long, because the upgrade scripts and the database both keep changing underneath a long project.
Custom code and Studio
Will my custom modules survive the upgrade?
Only if someone updates them. A database containing custom modules cannot be upgraded until a version of those modules exists for the target release, and that work sits with whoever maintains them.
Odoo's documented path has six steps. Freeze development, because anything still changing has to be re-upgraded and retested. Request an upgraded database to confirm the standard conversion works at all. Make each custom module install cleanly on an empty database of the target version. Then make it work on your upgraded copy. Test extensively and rehearse. Only then upgrade production.
The breakages are predictable: invalid module dependencies, changed asset declaration and OWL syntax, attrs that no longer work, references to fields, models and views that were renamed or removed, xpaths pointing at markup that moved, and methods that no longer exist.
The most valuable step is the one people skip. Before rewriting a customization for the new version, check whether the new version already does it. Odoo names reducing technical debt as one of the goals of upgrading, and removing redundancy between your custom code and now-standard functionality makes the upgrade easier and every future one cheaper. This is the same judgement that separates standard configuration from custom development in the first place.
Canadian localization
What happens to a Canadian tax configuration after an upgrade?
This is the part a partner outside Canada will not think to check. The conversion moves the data, and it does not confirm that provincial tax behaviour, payment file formats and cheque layouts still do what your accountant signed off on.
Recheck the fiscal positions
The Canadian localization ships fourteen default fiscal positions: Alberta, British Columbia, Manitoba, New Brunswick, Newfoundland and Labrador, Nova Scotia, Northwest Territories, Nunavut, Ontario, Prince Edward Islands, Quebec, Saskatchewan, Yukon, and International. Tax is determined by the province where delivery occurs, so an out-of-province delivery, a customer pickup and an international vendor each resolve differently. Confirm every one still maps the way your accountant signed off on.
Check that the localization modules actually installed
Odoo states directly that in some cases, such as when upgrading to a version with additional modules, modules may not be installed automatically. For a Canadian database that means confirming l10n_ca for base accounting, l10n_ca_reports for the Canadian reports, and l10n_ca_check_printing for cheque layouts are all present after the conversion. Nobody notices a missing localization module until a return is due.
Revalidate EFT files and cheque layouts
Electronic transfers in Canada run through the CPA005 file format, and cheque printing depends on a layout matched to pre-printed stock in one of three common formats. Both are configuration that a version change can disturb quietly, and both fail in ways your bank notices before you do. Generate one of each and compare against a known-good file from before the upgrade.
Reconcile the tax lines themselves
Sales and purchase taxes are created automatically when Accounting is installed, and rate accuracy remains the customer's responsibility to confirm with their accountant. If you run AvaTax, which Odoo supports for Canadian and US locations, revalidate the connection and run a sample calculation. Credentials do not always survive a version change.
If your accounting data itself is the concern rather than the version gap, the detail on opening balances, GST, HST and PST mapping and validation lives on our QuickBooks to Odoo migration page, and moving into Odoo from a different system entirely is a migration rather than an upgrade.
Scoping
What it costs and how long it takes
Anyone quoting an Odoo upgrade from a table is quoting the conversion, which is the part Odoo already does. The cost sits in everything around it, and it comes out of discovery.
Five things move the number more than anything else: how many custom modules exist and how much of what they do is now standard, how large the database is, how many integrations depend on it, how big the version gap is, and which hosting type you are on. An on-premise jump that crosses a PostgreSQL or Python floor adds infrastructure work before Odoo is touched at all.
Downtime is narrower than the project. The database is unavailable only while the conversion runs, which is why it gets scheduled when usage is lowest and rehearsed the day before. The weeks around it are testing and training.
Solvync scopes upgrades as a phased budget after discovery rather than a fixed package, because the module inventory is what decides the number and it is not knowable from outside the database. For broader budget context, what Odoo implementation costs in Canada covers how we frame scope and phasing generally.
The decision
Should you upgrade or reimplement?
Upgrade when
- The current configuration broadly works and people trust it.
- History has to stay continuous for reporting or audit.
- Customization is light, or most of it is Studio work.
- The version gap is small enough that the conversion is routine.
Reimplement when
- The configuration itself is the problem people complain about.
- Custom code has grown past what it is worth carrying forward.
- The business has changed enough that the old setup describes someone else.
- Nobody left can explain why the system does what it does.
If the honest answer is that the current build went wrong rather than simply got old, that is a different conversation and we treat it as one: Odoo project rescue starts with a second opinion rather than a migration plan. If you are weighing this against the September release specifically, the Odoo 20 readiness checklist covers what is changing and how to prepare for it.
Common Questions
Odoo upgrade questions, answered
It depends on where the database is hosted. On Odoo Online an upgrade is mandatory every two years on a major version, and a few weeks after the next release on an intermediary version. On Odoo.sh you get two further years after the initial three years of support, with notification in the project. On-premise you can stay on the same version indefinitely, although the smaller the version gap the easier the eventual upgrade.
The upgrade runs anyway. Odoo performs a silent test upgrade of every database that is due, and if no action is taken before the specified due date an automatic upgrade to the next version is triggered on a date Odoo sets. Until that deadline the timing is yours, which is the argument for requesting a test database early and working through it properly.
Extended support carries a mandatory additional fee and covers helpdesk support and bug fixes depending on feasibility. Security updates are not among the things Odoo lists for it, which is the practical reason to treat an end-of-support date as a real deadline. Extended support is available on Odoo.sh and on-premise. On Odoo Online, a version past standard support is simply unsupported.
Yes, by a different route. Odoo's upgrade platform is a service of the Enterprise subscription, so Community databases use OpenUpgrade, a project maintained by the Odoo Community Association that publishes migration scripts between major versions. Because those scripts are written one major version step at a time, a large version gap becomes several sequenced steps, each validated before the next.
OpenUpgrade is an Odoo Community Association project providing open-source migration scripts that convert the data, layout and structures of an Odoo database from one major version to the next. It is the standard route for Community edition databases, which cannot use Odoo's own upgrade platform, and it requires someone to run and validate each version step.
No. Odoo states that an upgrade does not cover switching editions, changing hosting type, downgrading to a previous version, or migrating from another ERP into Odoo. Moving from Community to Enterprise is a separate procedure with its own steps, and it is worth sequencing deliberately alongside an upgrade instead of assuming one request handles both.
Those are two separate pieces of work, because changing hosting type is outside what an upgrade covers. One constraint links them: Odoo.sh and on-premise do not run the intermediary online releases, so a database on an intermediary version has to reach the next major version before it can transfer. An Odoo Online database on 16.3, for example, would need to reach 17.0 first.
The production database is unavailable for as long as the conversion runs, which is why Odoo recommends scheduling it when usage is minimal and fully rehearsing the process the day before. On Odoo.sh a failed upgrade reverts automatically and a pre-upgrade backup is kept. On Odoo Online, once the production upgrade completes it is impossible to revert to the previous version.
Test databases are neutralized on purpose. Scheduled actions are disabled, outgoing mail servers are archived and replaced with a fake one, payment providers and delivery carriers are reset to their test environments, and bank synchronization is switched off. That is expected behaviour, and testing anything that depends on those systems needs sandbox credentials from the provider.
Yes. Customizations created with the Studio app are covered by the upgrade service, as long as Studio stays installed and the subscription stays active. The same applies to developments covered by a maintenance of customizations subscription. Modules with no maintenance contract sit outside that, whether they were built in-house or by a third party, including modules built by Odoo partners.
For an on-premise database, probably. Odoo 20 raises the minimum from Python 3.10 to 3.12 and from PostgreSQL 13 to PostgreSQL 16. Odoo 19.0 had already moved PostgreSQL from 12 to 13. Crossing two floors at once frequently means an operating system change underneath Odoo, so the infrastructure work belongs in the plan as its own stage before the database is touched.
Custom module code, and in predictable ways. Odoo documents the usual failures as invalid module dependencies, changed asset declaration and OWL syntax, attrs that no longer work, references to fields, models and views that were renamed or removed, xpaths pointing at markup that moved, and methods that no longer exist. Integrations over EDI and APIs, automated actions and server actions are the next most common, and they are the ones people forget to test.
- Clarify the need
- Control the scope
- Plan the next step
Still on an older Odoo version?
Book an Odoo Upgrade Readiness Review and leave with the support status confirmed, the target version to aim at, and a named list of the custom modules and integrations that need work before the move.