Odoo modules during migration: do we replace with the native, buy or migrate?
When we talk about Odoo migration, we often think of data. But the real issue is almost always the modules. A mature Odoo instance rarely contains only standard: it includes custom developments, modules purchased from the Odoo Marketplace, and old customizations of which we are no longer sure if they are still useful.
The good news is that Odoo evolves quickly. Part of what you had developed may no longer need to exist. Here’s how e3k analyzes each module and classifies it into one of three cases.
In short, before migrating a custom Odoo module, e3k analyzes it to determine if it falls into one of these 3 cases:
1. the need has become native → we abandon the custom.
2. a community module covers it → we buy and install the version compatible.
3. the development remains unique and relevant → we migrate it technically (adapting the code, views, data migration scripts, testing before switching to production).
Why are your modules the real issue of a migration?
Data, when clean, transposes relatively well from one version to another. The modules, however, require a real analysis. Each custom development is code that must be adapted to the new version - and each non-standard module is an element that may behave differently after migration.
That’s why, before any migration, we open an analysis budget: a developer reviews each of your modules to determine which case it falls into. This step prevents "carrying over old things" from one version to another and often saves you development time.
Case 1 - Your need is now covered by the native
This is the best scenario, and it is more common than one might think.
Odoo adds features with each version. What you had custom developed a few years ago may now be part of the standard. For example, we have already seen clients with heavy customizations on invoicing and subscriptions discover, between two versions, that the essence of their development had become native — to the point of being able to completely remove the large pieces of custom code.
The gain is twofold : you benefit from a feature maintained by Odoo (thus more robust and better integrated), and you have less code to migrate with each future version. Each customization removed means a lighter future migration. In this case, e3k's action is simple: we abandon the custom and switch you to the native, after validating with you that the standard function adequately covers your need.
Case 2 - A community module does it
Second case: the functionality is not native, but a community module exists to cover it — either a module purchased on the Odoo Marketplace or a module from the OCA community.
Here, the action is light. We buy the version compatible with the new version of Odoo, install it, and test it. Community modules are generally inexpensive, and installation often takes only a few minutes per module. It's mostly about purchasing and verification time.
The point of caution: one must ensure that a compatible version of the module indeed exists on the target version. This is not always immediate after the release of a new version of Odoo — some community modules take a little time to be updated. We check this point during the analysis to avoid unpleasant surprises.
Case 3 - Custom development needs to be migrated
Third case: the module corresponds to a specific need, still relevant, and without a native or community equivalent. It then needs to be migrated, meaning adapting (or sometimes rewriting) the code for the new version.
When it comes to modules developed by e3k, we handle the transfer — we know the code, so the migration is controlled: adapting to API changes, correcting XML views, and writing the necessary migration scripts (upgrade scripts) to preserve your data. For modules developed elsewhere, we assess the effort during the analysis.
It's also an opportunity to do some cleaning: remove the leftovers, clean up unnecessary code, and avoid carrying over things that are no longer useful into the new version. Before migrating a development, we always ask ourselves: will it still be relevant in three years, and will it be maintainable during the next version upgrade?
How we decide: the decision table
Here is how we classify each module.
| Module type | Question to ask | Action e3k | Effort / risk |
|---|---|---|---|
| Customization has become native | Does the function now exist as standard? | We abandon custom, we switch to native | Low — eases maintenance |
| Community module / Marketplace | Does a compatible version exist? | We buy and install the updated version | Low — mostly installation time |
| Custom development still useful | Is it still relevant in 3 years? | We migrate (or rewrite) the module | Variable — assessed during analysis |
Once we have confirmed that a module needs to be migrated (Case 3), here is how the migration of a custom module actually takes place:
- Module inventory : we identify the models, custom fields, views, access rules, and dependencies of the module, to precisely measure the scope of the work.
- Code update to the new version : we adapt the module to the target version's API (methods, fields, and views that have changed between the two versions of Odoo).
- View adaptation : XML views are often the most frequent source of errors after an upgrade — we fix them one by one.
- Data migration scripts : when a piece of data needs to be retained or transformed (e.g., a renamed field), we write a dedicated migration script to ensure nothing is lost in the process.
- Testing on a copy of your real data : the module must not only install but also work correctly with your data history.
- Switch to production, once the complete validation has been performed.
It is a precise engineering task, and it is precisely to avoid doing it "for nothing" that we always start by asking the question of Case 1 and Case 2.
Quick wins if you temporarily stay on your version
Sometimes a client may not be ready to migrate yet. In this case, we can often address a specific need with a small targeted development - a "quick win" that provides the desired service without waiting for the full migration. For example, adding to your online store the ability for certain visitors to see products in the catalog only, without logging in. These are small, easy, and quick additions that allow you to comfortably wait until migration.
That said, these features are often already native in recent versions - all the more reason to compare before developing.
A successful migration is not about transporting everything as is to the new version. It is about sorting: keeping what is valuable, adopting the native when it exists, relying on the community when it is relevant, and abandoning what is no longer useful. It is this sorting that makes your future migrations simpler and your ERP more efficient.
Your questions. Our answers
Here are some frequently asked questions about Odoo modules and migration.
It depends on each module. If the functionality has become native, it is better to abandon the custom. If it is specific and still useful, we migrate it. An analysis of the existing allows for a case-by-case decision.
We buy the version compatible with the new version of Odoo and install it. It is generally quick and inexpensive. The point to check is the availability of an updated version on the target version.
Because every custom development is code to maintain and migrate with each version. If the native now does the job, removing the custom lightens your future migrations and makes your system more robust.
Sometimes we can address a specific need with a small targeted development ("quick win") in the meantime. But we first check if the functionality is not already offered as standard in a more recent version.