Version Upgrades / Nimex Solutions
Upgrade Odoo without losing the workflows your business depends on.
An upgrade is two migrations at once: the database through Odoo's upgrade service, and your custom code through ours. Nimex analyses every module, rehearses the upgrade in a disposable environment and regression-tests your real workflows before anything is switched.
- In our codeaccounting and e-document stack ported 18 → 19
- Odoo documentationcustom modules are the maintainer's responsibility; the upgrade service does not port them
Upgrade assessment
Twelve things we read before we quote an upgrade.
The assessment is a document, not a call. It lists what your instance is made of and what each part means for the upgrade, so the plan and the price rest on facts.
- 01Current version and edition
Major or SaaS version, Community or Enterprise, and where it sits in Odoo's support window.
- 02Hosting
Odoo.sh, cloud or on-premise: it decides how the upgrade service is reached and how the environments are built.
- 03Installed modules
Standard, Enterprise, community and custom, with the ones that no longer exist in the target version.
- 04Customisations and Studio
Custom modules, Studio fields and views, server actions: each is upgrade work.
- 05Integrations
APIs, EDI, e-documents, bank synchronisation: endpoints and payloads that the new version may change.
- 06Database size and history
Size and record counts drive the upgrade duration and the length of the cutover window.
- 07Enterprise dependencies
Enterprise modules the custom code depends on, and what replaces them if they changed.
- 08Localisation
Turkish chart of accounts, taxes and e-document modules: standard localisation and our extensions on top.
- 09Deprecated APIs
ORM methods, hooks and JavaScript APIs removed between the versions, found by reading the code, not by guessing.
- 10XML view changes
Every XPath in a custom view against the target version's view, so inherited views still apply.
- 11Security
Access groups, record rules and portal access re-checked on the target version.
- 12Reports and documents
QWeb reports, e-mail templates and labels that custom code changed.
Custom module compatibility
The upgrade service moves your data. Your code is on us.
Odoo's documentation is explicit: a database with custom modules cannot be upgraded until a version of those modules exists for the target, and making them compatible is the maintainer's job. That job is where our upgrade experience is.
- Python models and ORM calls: renamed hooks, changed signatures, removed helpers
- Views and XML: XPaths re-based on the target version's views, new required attributes
- Web client and OWL: components, fields and services that moved between versions
- Reports: QWeb templates re-based on the new layouts
- Dependencies and deprecated modules: what to replace, what to drop
- Data transformation: migration scripts for fields and records the module owns
Our own stack (Turkish e-document extensions, cheque management, import tools, helpers) was ported from Odoo 18 to 19 and runs on both; the catalogue lists each tool's versions. Modules for other versions are assessed per project; we do not claim support for a version we have not tested your code on.
Upgrade environments
Production is upgraded once. Everything before that happens on a copy.
Development, staging and production stay separate throughout. The migration environment is a disposable copy of production that is upgraded, tested and thrown away as often as needed; Odoo's documentation recommends requesting a fresh upgraded test database repeatedly and rehearsing the day before.
- Production backup
A dated dump and filestore; nothing is done on production itself.
- Disposable migration environment
The backup restored on a separate server or branch, isolated from users.
- Source upgrade
Custom modules ported on the development branch and committed.
- Database migration
The copy sent to Odoo's upgrade service in test mode; the upgraded dump comes back neutralised.
- Module testing
Ported modules installed on the upgraded copy; automated checks run.
- User acceptance
Process owners run the regression scripts on the staging copy.
- Cutover
Production upgraded in the agreed window; the pre-upgrade backup kept.
Developer instances with the ported modules; nothing from here reaches users.
Upgraded copies of production, replaced each time a new test database is requested; UAT happens here.
Untouched until the cutover window; unavailable while the upgrade runs, then live on the new version.
On Odoo.sh the migration environment is the staging branch in upgrade mode: each commit restores the upgraded backup and updates the custom modules, which is how we test ports on a pristine copy. On-premise, the upgrade is requested from the command line; the test database comes back without the production filestore and is merged before testing. Both per Odoo's upgrade documentation.
Regression tests
Your workflows, run again on the new version, by the people who own them.
Odoo's upgrade checklist covers views, reports, records and exports. We add your business: nine areas with scripts written from your real processes, including the custom modules and the integrations. One failed area blocks the cutover until it is fixed and run again.
- Scripts from your processesEach area's scripts are the steps your team runs today, with the expected result written down.
- Run on the migration environmentTest databases are neutralised by the upgrade service: no mails, no payments, no bank sync go out.
- Fix, deploy, re-testA fix is committed, a new build deployed to the migration environment, and the failed area run again.
- GateCutover is scheduled only when every area passed on the build that will go to production.
Risk and rollback
Downtime is planned, not promised away.
Odoo's documentation states that production is unavailable while its upgrade runs and that a completed upgrade cannot be reverted. We plan for both instead of promising that nothing will stop or that nothing can go wrong.
- 01Backups
A verified backup of database and filestore before the window, restore-tested on the migration environment.
How we work - 02Rollback strategy
If the production upgrade fails or acceptance in the window fails, the pre-upgrade backup is restored and the window is rescheduled. Data entered during the window is lost by design, so the window is a freeze.
How we work - 03Downtime window
Measured on the rehearsals: upgrade service duration plus module update plus verification, scheduled when the business is quietest.
How we work - 04Data changes
The upgrade report Odoo attaches to a completed upgrade is read with you: renamed fields, merged models, changed defaults.
Odoo documentation - 05Verification after cutover
Owners run the smoke scripts on production: a quotation, a delivery, an invoice and its e-Fatura, a bank line, before users are let in.
How we work - 06No completed upgrade is reverted
Once the production upgrade finishes, the only way back is the backup, which means losing what was entered since. We say so in the plan.
Odoo documentation
Versions
Where each version stands, from Odoo's own documentation.
Support dates and upgrade eligibility below are from Odoo's "Standard and extended support" and "Upgrade" pages, read on 15 October 2026. We re-check them for every assessment; Odoo's documentation is the source if anything differs.
- In our codetooling and extensions that exist in Nimex repositories
- How we workour method, shown on sample data; results depend on your project
- Odoo documentationverified in Odoo's official documentation
| Version | Released | End of standard support | Status on 15 Oct 2026 | Our delivery experience |
|---|---|---|---|---|
| Odoo 20.0 | September 2026 | September 2029 (planned) | Standard support newest major version | Assessed per project; not yet a delivery target for our module stack |
| Odoo 19.0 | September 2025 | September 2028 (planned) | Standard support | In our code projects delivered; accounting and e-document stack ported here |
| Odoo 18.0 | October 2024 | September 2027 (planned) | Standard support | In our code projects delivered; most of our stack originates here |
| Odoo 17.0 | November 2023 | September 2026 | Extended support additional fee, Odoo.sh and on-premise only; no security updates | Upgrade source: eligible to upgrade to a supported version |
| Odoo 16.0 | October 2022 | September 2025 | Extended support additional fee, Odoo.sh and on-premise only | Upgrade source |
| Odoo 15.0 | October 2021 | October 2024 | Extended support additional fee, on-premise | Upgrade source |
Per Odoo's documentation: each major version gets three years of standard support; a database can be upgraded from any version to any major version still under standard support, or that left standard support less than six months ago. Security updates are provided during standard support only. The target version of your upgrade is chosen in the assessment against these rules and your custom code.