Odoo migration: custom, OCA and third-party modules

When someone asks me how long it takes to migrate an Odoo, the first thing I ask back is what is installed beyond the standard. The version barely matters in that math.

In a real implementation, Odoo is rarely just Odoo. Underneath it there are four layers, and each one migrates differently.

The four layers

Odoo’s core. The standard apps: sales, inventory, accounting, purchase. It is the best-served layer. On Enterprise, the official upgrade handles it together with whatever was built in Studio. On Community, OpenUpgrade covers most of it, as I explained in the previous post.

OCA modules. The community modules, including the Brazilian fiscal localization. Each one is maintained by whoever develops it and has to be ported and migrated on its own. Odoo’s official upgrade doesn’t cover this layer.

Third-party modules. The ones the company bought on the Odoo app store or from another vendor. This is where the surprise shows up: the vendor may not have released the module for the new version yet, or may charge for it again.

Custom modules. What was developed only for your company. It is the least predictable layer, because everything depends on how the code was written.

What Odoo itself says

The upgrade documentation is direct. The service migrates the standard apps and leaves out modules created in-house or by third parties, including Odoo partners, unless they are covered by a maintenance contract. And it carries a warning that sums up the problem: a database with a custom module cannot be upgraded until a version of that module exists for the target version.

In plain terms: the official upgrade converts the database, and the code is still on you. Without a new version of the custom module, the migration stops there.

Studio looks safe, and it takes work

Customizations made in Studio are included in the official upgrade, as long as the subscription is active. In practice, they tend to take more work than they seem to. Fields, views and reports built in Studio rely on the structure of the version they were born in, and when that structure changes, part of the work has to be redone. There is a user report of someone who lost a good share of their Studio changes when moving to 17.

It is also one of the reasons why a database with lots of Studio work has a more expensive migration.

What separates code that migrates from code that gets stuck

For custom modules, the dividing line is code quality. A module written the right way, one that inherits standard behavior instead of changing native code, has tests and doesn’t run raw SQL against the database, migrates with predictable effort. A module that edits native files, runs raw SQL or has no tests becomes a risk with every new version.

Before migrating, we look at the health of the modules. Sometimes it pays to clean up the code first and migrate afterwards, and that cleanup also makes the next migration cheaper.

Next post

Once you know what migrates, you still need to make sure nothing got lost along the way: attachments, reports, invoices. The next post is about how to test a migration before the cutover.

Mapping the four layers of your database is exactly what KMEE’s migration assessment does, free of charge.