The complete guide to Odoo database migration (2026 edition)

An Odoo migration is rarely “just the database.” It is the records themselves, the code you have added, the Studio customizations your team depends on, the integrations that connect to the rest of your business. This guide covers what a real migration takes — in the shapes we run most often — and the checklist we apply before we touch production.

The five shapes of Odoo migration

Most conversations about migration assume upgrade — moving forward to a newer version. But there are five distinct shapes, and picking the right one changes the whole engagement.

1. Upgrade — move a production database (and its code) to a newer major version. The default case.
2. Downgrade — move back to an older version. Rare but not impossible; specific patterns apply.
3. Database split — turn one multi-company database into several, or extract one company.
4. Database merge — consolidate two or more databases, usually after an acquisition.
5. Currency migration — change the functional currency of a company, which Odoo does not support natively and which requires a new company with migrated monetary fields.

We have written separate deep-dives on each — see the related services under Odoo migration.

Picking a target version

Three heuristics cover most cases:

• Jump to the latest LTS when you are more than two majors behind. The support envelope is the main driver.
• Jump to the version your biggest third-party dependency supports. If a key module has not shipped support for the newest Odoo, that becomes the ceiling.
• For heavily customized databases, do not skip more than two majors in one step. Plan intermediate hops — each transformation is bounded and testable.

The risks that blow up migrations

Every migration-gone-wrong we have seen on a rescue engagement came from one of these:

1. No test migration. The team jumped straight to production. Always test first.
2. Custom modules not audited. Nobody read the odoo.py / __manifest__.py before kicking off. Surprises at UAT.
3. Silent assumptions about Studio. Studio configurations carry over differently between versions and frequently need adjustment on the new version.
4. No data-loss report on downgrades. Newer fields have no home on the older version; the team found out during UAT.
5. No rehearsed rollback. Cutover went sideways and there was no tested way back.

The checklist we run on every engagement

• Source inventory: record counts per model, list of all custom modules with last-modified date, Studio customizations catalogued, integrations mapped.
• Target environment provisioned.
• First test migration run end-to-end on a replica.
• Issues triaged and fixed; re-run until clean.
• UAT per functional area with your leads signing off.
• Cutover plan documented: timing, checklist, validation, go/no-go criteria, rollback path.
• Hypercare window on the calendar.

What good looks like after go-live

• No unplanned rollback.
• No invoice, shipment, or payroll missed in the cutover window.
• No data reconciliation issues in week 1.
• Your team confident enough to use the new version from day one.

We have built a migration readiness checklist you can download — it is the same one we walk through at the start of every engagement.