Every Odoo customization you approve is something you agree to carry. Not only to build and use, but to test, fix, and move forward every time you move to a newer Odoo version. That is the part most teams price wrong. The build is quoted once. The carrying cost shows up years later, in an upgrade window that takes three weeks instead of three days.
This is not an argument against customizing Odoo. It is an argument for knowing what each change costs you later, so you can decide which ones are worth it.
Why upgrades get harder as customizations accumulate
When a new Odoo version is released, Odoo carries the standard modules forward. Sales, inventory, accounting, and the official localization modules move with the product. Your custom code does not. Anything written specifically for your business has to be reviewed against the new version, adjusted wherever the underlying model or view changed, and retested.
So the size of an upgrade is mostly a function of how much you changed and how deeply. A clean instance running standard Odoo with configuration only is a short project. The same company with forty custom behaviors spread across six modules is a different project entirely, even though both are described as moving from one version to the next.
Not every customization weighs the same
- Configuration. Pricelists, approval rules, user groups, report layouts, email templates. These carry forward at almost no upgrade cost. Always check whether standard configuration solves the problem before anyone writes code.
- Additive changes. A new field, a new report, a new menu, a new model that stands beside the standard ones. Usually low risk, because they add to Odoo rather than reaching into it.
- Behavioral overrides. Changing what happens when a sales order is confirmed, or how a stock move is valued. These touch logic that Odoo itself changes between versions, so they need real testing every time.
- Replaced flows. An entirely custom process sitting where a standard one used to be. Sometimes the highest value, always the highest carrying cost. Worth it when the process is genuinely your competitive difference. Hard to justify when it exists only because the standard flow was never explained to the team.
The useful discipline is knowing which category a request falls into before it gets built, not after.
What to decide before you build
Three questions kill more unnecessary custom code than any technical review.
- Does standard Odoo already do this, differently? Often the answer is yes, and the real request is training rather than development.
- Who benefits, and how often? A change that saves one person ten minutes a month is not worth carrying across three upgrades.
- Can this be narrower? Broad requests produce broad code. "Automate procurement" is an upgrade liability. "Create a purchase request automatically when stock for these twelve items drops below the reorder point" is a maintainable change.
This is one reason the flow on Plemo puts a written spec in front of development instead of after it. The chat asks clarifying questions and pushes back on requests that are too broad to build safely, and you approve the spec before any code is written. The immediate benefit is that you get what you actually meant. The long-term benefit is quieter: a year later that spec is the record of why the change exists, which is exactly what you need when someone asks whether it still deserves to be carried into the next version.
What to do at upgrade time
- Inventory first. List every customization with its owner and its purpose. Anything nobody can justify is a candidate for removal, and removing is far cheaper than migrating.
- Upgrade in a sandbox and test the customized paths specifically. The standard flows will mostly behave. Your overrides are where the surprises live, so budget the testing time there.
- Do not upgrade and redesign in the same window. If a process needs rethinking, do that before or after, with its own testing. Mixing the two makes every failure ambiguous: nobody can tell whether the new version broke it or the new design did.
- Let the people who use a customization test it, not only the people who built it. A change that passes technically and fails in daily use is still a failed upgrade.
- Check the localization modules separately. ZATCA, ETA, FTA and WPS behavior comes from Odoo's official localization modules, and those move on their own schedule. Confirm the version you are moving to still covers what you file.
The honest trade-off
Customization is not technical debt by default. A change that removes a daily two-hour reconciliation is worth carrying through every upgrade for the rest of that system's life. The problem is the other kind: code built for a person who has since left, for a customer you no longer serve, or for a process that was replaced two years ago and never removed.
Review that list once a year, not during an upgrade, when the pressure to keep everything is highest and nobody has time to argue. The best upgrade preparation is usually deletion.
If you are planning a move to a newer Odoo version and want an honest estimate of what your customizations will cost to carry, our version upgrade service starts with exactly that inventory.