Odoo 15 → 18 Upgrade
Three major versions behind and blocking every new integration. Migrated the core ERP from Odoo 15 to 18 with zero data loss and no disruption to live operations.
- My role
- Migration lead
- Team
- QA (lead) · Backend · Operations
- Stack
- Odoo · PostgreSQL · Python · Docker
15 → 18
Versions jumped
Three major upgrades in one project
0
Data loss
Across the full migration
−20%
Post-release defects
Regression automation
Zero
Downtime
For live operations teams
The Problem
Odoo 15 was three major versions behind, which meant every module customisation had to be re-verified against upstream changes before an upgrade could even be attempted. Newer integrations and vendor modules increasingly required Odoo 17+, so staying on 15 was quietly blocking the operations roadmap.
A straight version jump from 15 to 18 could not be done in one step — each major Odoo release changes its data model, so the migration had to pass through every intermediate version without corrupting live financial and inventory data.
- Three major versions of accumulated schema and module drift
- Custom modules with no guarantee of compatibility past v15
- Operations teams running live on the database being migrated
- No tolerance for data loss on financial and inventory records
The Architecture
The migration ran as a staged upgrade rather than a single cutover — each version hop validated independently before the next began, with a full regression pass at every stage.
- Sequential upgrade path (15 → 16 → 17 → 18) instead of a direct jump, isolating breakage to one version at a time.
- Staging environment mirroring production data for every hop, so failures surfaced before they reached live operations.
- Custom module audit at each version — patched, replaced, or deprecated based on upstream compatibility.
- Full database backups and rollback checkpoints before every stage.
- Regression suite run against core flows (invoicing, inventory, procurement) after each version.
| Stage | Focus | Gate |
|---|---|---|
| 15 → 16 | Module compatibility audit | Staging regression pass |
| 16 → 17 | Data model migration | Zero diff on financial totals |
| 17 → 18 | Final cutover rehearsal | Full regression + rollback tested |
The Execution
Each version hop followed the same rhythm: audit, migrate on staging, regress, then cut over — repeated three times rather than attempted as one high-risk leap.
- Audited every custom module for breaking changes before each upgrade, patching or replacing what upstream no longer supported.
- Ran the full migration on a staging clone of production first, comparing record counts and financial totals before and after.
- Built a regression checklist covering the operations team's daily flows, run manually and via automation after every hop.
- Scheduled the final cutover for a low-traffic window with a tested rollback path, so the live database was never at risk without a way back.
- Kept operations informed at each stage so the migration never surprised the people depending on the system daily.
The Impact
The upgrade cleared the version debt that was blocking new integrations, without a single record lost or a day of downtime for the teams running on Odoo daily.
- Migrated three major versions with zero data loss on financial and inventory records.
- Unblocked integrations and vendor modules that required Odoo 17+.
- No disruption to live operations — the cutover was invisible to daily users.
- Established a repeatable staged-upgrade playbook for future Odoo version jumps.
Why staged, not direct
- A direct 15 → 18 jump would have combined three versions' worth of data-model changes into one unverifiable step.
- Staging each hop meant any failure was traceable to a single version, not buried in a three-version diff.
Source: Résumé — Senior QA Engineer & Associate PM, Suplyd