Upgrade assessment
Confirm the current version, edition, hosting model, supported target, database size, custom modules, Studio work, integrations, reports, and localization dependencies.
Certified Odoo Implementation Partner
Odoo Version Upgrade Services in Canada
An Odoo version upgrade moves an existing Odoo database to a newer supported release. The project includes the technical conversion, custom module and integration assessment, testing, reconciliation, training, cutover planning, and post-launch stabilization.
Solvync helps Canadian businesses assess the target version, prepare custom work, validate Canadian accounting and localization, rehearse the move, and coordinate go-live. Moving from Odoo Online to Odoo.sh is assessed separately as a hosting migration, with an eligibility check for intermediary SaaS releases.
Current database
Custom work
Integrations
Validated target
Assess, test, reconcile, rehearse, and approve before production.
- Certified
- Odoo Ready Partner
- Calgary, Alberta
- Serving Canada
- Discovery first
- Timeline confirmed by scope
Upgrade delivery
What does an Odoo version upgrade service include?
A complete Odoo upgrade service manages the work around the database conversion: assessment, custom work, testing, reconciliation, rehearsal, cutover control, and stabilization. The exact route depends on the edition, hosting platform, current version, target version, and custom surface.
Custom module preparation
Classify each extension, test retained modules on the target release, adapt changed APIs and views, and remove custom code when supported standard functionality can replace it.
Validation and rehearsal
Test workflows on an upgraded copy, reconcile control totals, verify integrations and permissions, measure the cutover sequence, and record go or no-go criteria.
Cutover and stabilization
Coordinate the production window, backup and restore controls, technical conversion handoff, smoke tests, business acceptance, and focused support after launch.
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.sh | On-premise |
|---|---|---|---|---|
| Odoo 19.0 | September 2025 | September 2028 (planned) | Standard | Standard |
| Odoo 18.0 | October 2024 | September 2027 (planned) | Standard | Standard |
| Odoo 17.0 | November 2023 | September 2026 (planned) | Standard | Standard |
| Odoo 16.0 | October 2022 | September 2025 | Extended (fee) | Extended (fee) |
| Odoo 15.0 | October 2021 | October 2024 | Extended (fee) | Extended (fee) |
| Odoo 14.0 or older | Before 2021 | Before 2024 | Extended (fee) | Extended (fee) |
Odoo Online release path
This table deliberately lists major releases only. Odoo Online intermediary releases such as SaaS 19.2, 19.3, and 19.4 are not Odoo.sh or on-premise upgrade targets. Odoo manages those releases inside Odoo Online. Moving an Online database to Odoo.sh is a hosting migration, and a database on an intermediary release must first reach the next major release.
Readiness checker
Check where your database stands
Choose a major-version upgrade on Odoo.sh or on-premise, or assess the separate Odoo Online to Odoo.sh hosting migration path. Intermediary SaaS releases never appear as Odoo.sh upgrade targets.
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 includedThe Odoo Enterprise subscription includes the technical database conversion to a supported target. Testing, training, custom module adaptation, and project coordination still need their own scope.
- Custom modules need a separate workstreamModules without an applicable maintenance agreement need separate assessment and adaptation. Test each retained module on the target release and on an upgraded copy before production cutover.
- Canadian configuration needs revalidationAfter conversion, confirm the Canadian localization modules, province-specific fiscal positions, sales and purchase taxes, EFT and CPA005 files, and cheque layouts against approved results.
- 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.
Book an Odoo Upgrade Readiness Review
A focused screen-share to confirm the current setup and identify what needs deeper assessment. No system access is required.
What you pay for
Is the Odoo upgrade free?
For an eligible Odoo Enterprise database, the subscription includes the technical database conversion to a supported target. The project scope covers the assessment, uncovered custom work, testing, training, rehearsal, cutover coordination, and stabilization around that conversion.
Covered by the subscription
For an eligible Enterprise database, Odoo provides the technical conversion for standard applications and covered customizations to a supported target version.
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.
Scoped with Solvync
Solvync assesses risk, prepares retained custom work, plans validation, supports rehearsal, and coordinates the work around the conversion.
Module, Studio, integration, and report inventory. Canadian localization and accounting validation plan. Cutover, reconciliation, and stabilization controls.
Not included
The technical conversion does not replace client decisions, business acceptance, training, or remediation of uncovered custom work.
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.
Responsibility boundary
Odoo's Enterprise Subscription Agreement assigns the customer responsibility for validating the upgraded database, reviewing the effects of target-version changes, and adapting third-party extensions. Read the current terms in section 4.3 of the Odoo Enterprise Subscription Agreement.
The conversion and the upgrade project have different owners. Odoo handles the eligible platform conversion. Your team and its delivery partner produce the validation evidence, custom adaptations, business decisions, and cutover controls. 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 a focused Odoo Upgrade Readiness Review. We will confirm the current setup, discuss the supported path, and identify the areas that need a deeper module, integration, localization, or infrastructure assessment.
Enterprise and Community
Can you skip Odoo versions when you upgrade?
An Odoo Enterprise upgrade can move an eligible database from an older release to a supported target in one request. An Odoo Community upgrade follows the available OpenUpgrade path between major versions. Custom modules still need target-version code, while edition and hosting changes remain separate projects.
Odoo Enterprise upgrade
Yes. One upgrade request names the target version, and Odoo's upgrade platform moves the database through each intermediate major version itself. Section 4.3 of the Odoo Enterprise Subscription Agreement permits conversion from any version to a more recent Covered Version. A large gap can still take longer because the platform processes the releases in sequence.
Odoo Community upgrade
Community databases have no access to Odoo's Enterprise upgrade platform. OpenUpgrade is an established Odoo Community Association route that publishes migration work between major versions. Coverage varies by release and module, so the available scripts and gaps must be assessed before selecting a multi-version path.
What stays separate
Two limits apply to both editions. The target has to be a supported version, and retained third-party or in-house modules need code that runs on the target release. Odoo-covered extra modules and Studio customizations follow the subscription terms described above; other custom work needs its own preparation and validation workstream.
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 |
Infrastructure boundary
These are server floors for major releases used on Odoo.sh and on-premise. They are not a compatibility table for Odoo Online SaaS intermediary releases, whose infrastructure is managed by Odoo.
By hosting type
How the upgrade actually runs
Major-version upgrades on Odoo.sh and on-premise use Odoo's database conversion process. Moving from Odoo Online to Odoo.sh is a hosting migration with a separate sequence and an intermediary-version eligibility check.
How an Odoo Online to Odoo.sh migration runs
Moving from Odoo Online to Odoo.sh is a hosting migration. A database already on a supported major release can be downloaded from the Odoo Online database manager and imported into an Odoo.sh project on that same major release.
An intermediary SaaS release such as 19.2, 19.3, or 19.4 cannot run on Odoo.sh. Odoo requires that database to reach the next major release first. A database on SaaS 19.4 must therefore wait for and reach Odoo 20.0 before it can transfer. Odoo 19.0 is a previous release and is outside that forward path.
After the version is eligible, download the backup, import it into Odoo.sh, coordinate any subscription transfer with Odoo, and validate the restored database, mail, scheduled actions, integrations, domain, and Canadian configuration before cutover.
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 the Odoo.sh production upgrade process fails, the platform documents an automatic reversion. On success it keeps a backup taken before the upgrade. Confirm that the staging upgrade and rollback plan are proven before 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 upgrade testing
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.
Include the dependencies that sit outside the main transaction path: integrations over EDI and APIs, workflows that cross between apps, data exports, automated actions, and server actions triggered from both form and multi-record list views.
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.
Custom module upgrade path
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. Give every module one documented outcome: retain it with tests, adapt it for the target, replace it with supported standard Odoo, or retire it deliberately.
Canadian localization
What happens to a Canadian tax configuration after an upgrade?
The conversion moves data and code to the target release. Business acceptance still needs evidence that provincial tax behaviour, payment files, cheque layouts, accounting reports, and control totals match the approved Canadian configuration.
Recheck the fiscal positions
The Canadian localization includes province-specific and international fiscal positions. Tax treatment can depend on the delivery location, so test approved in-province, out-of-province, pickup, and international scenarios after conversion.
Check that the localization modules actually installed
Odoo notes that additional modules may not install automatically during some upgrades. Confirm l10n_ca for base accounting, l10n_ca_reports for Canadian reports, and l10n_ca_check_printing for cheque layouts before business acceptance.
Revalidate EFT files and cheque layouts
Canadian electronic transfers can use the CPA005 file format, and cheque printing depends on the configured layout and stock. Generate representative payment files and cheques, then compare them with approved pre-upgrade examples.
Reconcile the tax lines themselves
Sales and purchase tax configuration remains the customer's responsibility to validate with its accounting adviser. If the database uses AvaTax or another tax integration, reconnect the test environment as required and compare representative calculations with approved results.
Upgrade or migration
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
Upgrade effort depends on the current database rather than a universal package. A defensible estimate follows an inventory of custom modules, integrations, hosting, data volume, localization, test scope, and the target release.
Odoo upgrade cost and timeline
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.
Measure the production window in rehearsal. Depending on the hosting route, it can include the final backup, conversion, deployment or filestore work, startup, reconciliation, smoke testing, and the go or no-go decision. Testing and training happen before that window.
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.
For a broader planning range, use the ERP calculator to Estimate your cost. If you are still deciding whether the issue is an upgrade or a wider implementation, you can Book an Odoo Fit Audit.
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.
Decision boundary
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.
Evidence
Official sources and review
Support status, upgrade responsibilities, hosting procedures, technical requirements, and Canadian localization details were checked against Odoo's published documentation. Community migration guidance was checked against OCA OpenUpgrade.
Common Questions
Odoo upgrade questions, answered
It depends on where the database is hosted. Odoo.sh provides a defined upgrade window after standard support, with notification in the project. On-premise operators control their timing, although waiting increases the version gap and future work. Odoo manages the release path for Odoo Online. Moving from Online to Odoo.sh is a separate hosting migration and may require the Online database to reach the next major release first.
No. They are intermediary SaaS releases available only on Odoo Online. Odoo.sh and on-premise run major releases such as Odoo 18.0 and 19.0. If an Online database is on an intermediary release, Odoo requires it to reach the next major release before the database can be transferred to Odoo.sh or on-premise.
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 between major Odoo versions. It is an established route for Community databases that cannot use Odoo's Enterprise upgrade platform. Coverage varies by version and module, so the available scripts and any gaps must be assessed before the path is selected.
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.
Plan them as separate pieces of work. A version upgrade changes the database release, while an Odoo Online to Odoo.sh migration changes the hosting platform. A database already on a supported major release can transfer on that release. A database on an intermediary SaaS release must first reach the next major release, then its backup can be imported into Odoo.sh.
Measure downtime during rehearsal. A major-version production window can include the final backup, database conversion, module deployment, startup, reconciliation, smoke tests, and the go or no-go decision. An Odoo Online to Odoo.sh transfer has a separate window for backup export, import, environment validation, domain cutover, and business acceptance. Odoo.sh documents automatic reversion when its production upgrade process fails and keeps a pre-upgrade backup.
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.
Odoo includes Studio customizations in the technical conversion while Studio remains installed and the subscription stays active. That coverage does not remove functional testing. Validate the affected views, automations, reports, permissions, and workflows in the upgraded test database before acceptance.
Treat Odoo 20 as a readiness question until Odoo publishes and supports the final upgrade target. For an on-premise database, compare the published target requirements with the current Python, PostgreSQL, operating system, add-ons, and deployment method before scheduling infrastructure work. The dedicated Odoo 20 readiness checklist owns the release-specific details.
Common risk areas include custom module dependencies, changed assets and OWL code, removed fields or models, moved views and xpaths, changed method contracts, automated actions, reports, and integrations over APIs or EDI. The actual risk depends on the database inventory, so test every retained dependency against the target release.
- Clarify the need
- Control the scope
- Plan the next step
Still on an older Odoo version?
Book an Odoo Upgrade Readiness Review to confirm the current setup, discuss the supported path, and identify the module, integration, localization, infrastructure, and validation areas that need deeper assessment.