Ten ways Odoo migrations fail (and how to avoid each one)
Every rescue engagement we take on traces back to a handful of avoidable mistakes. Here are the ten we see most, and the specific guardrail that prevents each.
We get called in to rescue migrations that went wrong, and the post-mortems rhyme. The same ten mistakes account for nearly all of them. None are exotic. All are avoidable with one specific discipline each.
1. No test migration
The team ran the upgrade straight on production. Guardrail: every migration runs end-to-end on a replica first, as many times as it takes to come out clean.
2. Custom modules never audited
Nobody read the manifest or model files before kickoff, so surprises landed at UAT. Guardrail: inventory every custom module with last-modified dates before quoting the work. Dead modules get deleted, not migrated.
3. Studio customizations assumed safe
Studio configurations carry over differently between versions and silently change behavior. Guardrail: catalogue every Studio change and re-validate it on the target version.
4. Integrations tested last
XML-RPC/JSON-RPC callers assumed a field or method that moved, and broke after cutover. Guardrail: re-run every integration against the test database before go-live, not after.
5. No data-loss report on downgrades
Newer-version fields have no home on an older version, and the team discovered the losses during UAT. Guardrail: produce an explicit field-by-field data-loss report before any downgrade.
6. Skipping too many majors at once
A heavily customized database jumped four majors in one step and every transformation compounded. Guardrail: for customized databases, do not skip more than two majors per hop. Plan intermediate, testable stages.
7. Accounting close not validated
Finance found discrepancies after the books were already on the new version. Guardrail: run a full accounting close on the test database with the finance lead signing off before cutover.
8. No rehearsed rollback
Cutover went sideways and there was no tested way back. Guardrail: the rollback path is documented and rehearsed, with explicit go/no-go criteria.
9. Cutover window underestimated
The migration ran long and collided with a billing run or shipment. Guardrail: time the full rehearsal, then schedule the real cutover with margin and a clear validation checklist.
10. No hypercare after go-live
The team moved on the day after cutover and small issues festered. Guardrail: a hypercare window is on the calendar before launch, with someone owning it.
The pattern
Nine of the ten share a root cause: assuming instead of testing. A rehearsed migration on a replica, an audited module list, and a signed-off rollback plan prevent most of this list outright.
We packaged the full version of this into a migration readiness checklist you can download — it is the same one we run at the start of every Odoo migration engagement.