Odoo migration: upgrading without breaking what works

Why migrate

An Odoo migration is not a calendar whim. Odoo releases one major version a year and only supports recent ones. Staying on an old version means losing security fixes, being cut off from new modules, and making each future migration a little heavier every year.

Many companies nonetheless postpone, often for the same reason: they do not know what their installation actually contains. Migration then becomes a leap into the unknown, which makes it more frightening than it is.

What makes a migration easy or hard

Data volume is almost never the problem. The problem is the specific development accumulated over the years.

A module written through inheritance, adding its behaviour without touching the core, carries across versions with measurable effort. A module that directly modified standard code has to be redone, because the code it relied on has changed.

That is why the quality of the initial development is paid for, or repaid, years later. A clean installation migrates. A patched-together one strands the company.

The stages of a migration

• The audit: inventory installed modules, separating standard, community and specific development. This step nearly always reveals modules nobody uses any more.
• The sort: decide what is carried over, what is dropped and what is replaced by a function that became standard in the meantime. A migration is a good chance to lighten the load.
• Porting the code: adapt the retained modules to the new version.
• Data migration: transform the database to the new schema, then check accounting totals, stock levels and customer balances.
• Business testing: have teams replay their everyday operations on the new version, before the switch and not after.
• Go-live: switch over in a short window, with a prepared rollback.

The most common pitfalls

Migrating without sorting. Carrying over modules that became useless is expensive and weighs down the next migration. The audit is there to discard as much as to port.

Testing internally only. Discrepancies surface in real cases, the ones teams meet at month end. One test run by users beats ten technical ones.

Skipping versions blindly. Going from a very old version to the latest can be done, but through the intermediate steps, not in one jump.

Forgetting integrations. Connections with your other tools, your e-invoicing or your business platform must be checked like everything else.

The right moment

Migration should be planned away from closing periods and peak activity. The best window is when the company has room to absorb a few days of adjustment, which rules out the end of the financial year.

A well-prepared migration is a predictable piece of work. One postponed three years running becomes a rebuild project, with a budget that bears no relation to the original.