3 October 2026 · 3 min · Custom Odoo
Migrating an Odoo module from version 18 to 19 and 20
Migrating Odoo to a new version means porting the code of every added module (Python, views, JavaScript) and transforming the database data, then testing everything on a copy of production before the cut-over; in Enterprise, Odoo migrates the standard part, in Community you rely on community tools. The key factor is your specific modules. Here is the method we apply, including to our own apps published for Odoo 18, 19 and 20.
Why migrate
- Support: Odoo maintains the last three major versions; beyond that, no more security fixes.
- New features and performance improvements in every version.
- Compliance: recent versions better integrate new obligations such as e-invoicing.
- Modules: publishers release first for recent versions.
The two sides of a migration
Code: every added module must be adapted — Python API changes, XML view structure, the JavaScript framework (OWL), renamed fields or methods. A well-known example: in version 18, list views changed from <tree> to <list>. Each version brings its own set of such changes.
Data: the database must be transformed — new fields, removed or renamed fields, restructured models. In Enterprise, Odoo’s upgrade service handles the standard modules. In Community, we use OpenUpgrade, the Odoo Community Association project, plus scripts for your modules. Data usually goes version by version (17 → 18 → 19), even when the goal is to skip several.
The 6-step method
- Inventory: list installed modules in three groups — standard, purchased or community (does the target version exist?), custom (who wrote them, are they still used?). It is a chance to clean up: a module built five years ago may be useless now that Odoo does the same.
- Port the code of each custom module: code, views, reports, JavaScript, and its automated tests.
- Test on a fresh database of the target version — the surest way to catch dependency issues.
- Migrate a recent copy of your real database, measure the duration and fix data errors.
- User acceptance tests: each team checks its processes — a quote, a delivery, an invoice, a credit note, the accounting export (see exporting Odoo entries to your accountant), customised PDF reports.
- Cut-over: a quiet slot, a verified full backup (see automatic Odoo backups), the final migration, a quick check. Keep the old database read-only for a while.
No-code customisations
Customisations made in developer mode (hand-edited views, x_ fields) are the most fragile: list and check them one by one. Those made with Studio or with an app that stores them as data, such as Ramira Studio, migrate with the database. See adding custom fields in Odoo and a Studio for Odoo Community.
Budget
The cost depends mainly on the number and complexity of custom modules. At Ramira, porting a module starts at €400 excl. VAT, tests included. See how much a custom Odoo module costs and our Odoo migration offer.
In short
Inventory, porting, tests on a fresh database, migration of a copy, acceptance tests, cut-over: a well-prepared migration happens without drama. We port our own apps every year — see our Odoo apps. A few versions behind? Let’s talk.
FAQ
Do I need to migrate every year?
No. Odoo supports the last three major versions. Many companies migrate every two or three years. Waiting too long makes the jump harder, because data must go through each intermediate version.
How long does a migration take?
For an SME with a few custom modules, two to six weeks from inventory to cut-over, a large share of it testing. The cut-over itself often happens over a weekend.
Will the modules I bought on the store be available?
Check that each publisher releases the target version. Our Ramira Studio apps, for example, are published for Odoo 18, 19 and 20.
Sources
Mohamed Rahmouni — founder of Ramira, app developer and Odoo consultant in Niort, France. More