Every Odoo instance that has been live for a couple of years is carrying changes nobody remembers asking for. A field added for a report that mattered to one manager who has since left. A validation rule written for one difficult supplier. An automated email going to a list of three people, two of whom filter it into a folder they never open. None of it is broken, so none of it gets looked at, and the pile grows quietly until an upgrade forces the conversation.
That pile is customization debt. It is not a sign the implementation went badly, and it is not anyone's fault. It is the normal result of a system used by real people who kept asking for real things. The only question is whether you review it on your own schedule or wait for it to send you a bill.
Why the pile costs you even when nothing is broken
- Upgrades. Every customization is something that has to be checked against the new Odoo version. Fifteen changes is an afternoon of work. Eighty is a project with a budget and a steering call.
- Onboarding. A new finance hire learns your Odoo, not Odoo. Every deviation from standard behavior is one more thing they cannot look up in the documentation and have to be told by a colleague.
- Debugging. When a posting goes wrong, the fault has to be traced through whatever custom logic sits between the button the user pressed and the row that landed in the database. More layers, slower answers.
- Standard features catching up. Odoo ships new capability every year. Some of what you paid to build two versions ago is now in the box, better maintained than your version of it and free to you already.
Sort what you have into four buckets
Take the list of everything custom in your instance and put each item in exactly one of these:
- Load-bearing. A person or a process would stop today without it. Your ZATCA or ETA invoice numbering, the pricing logic your sales team quotes from, the integration that feeds your warehouse. These stay, and they are the ones worth testing first at upgrade time.
- Habitual. Someone uses it, but the underlying need has changed. A custom stage that exists because approvals used to run through two committees and now run through one. Worth a conversation, not an automatic keep.
- Orphaned. Nobody uses it. The requester left, the customer it was built for churned, the report it fed was replaced by a dashboard. This is where most of the debt lives.
- Superseded. Standard Odoo now does it, usually better. Moving to the standard feature costs you a migration of habits and sometimes of data, and it buys you a customization you never have to test again.
How to actually find the orphans
No platform will hand you this list. Nothing in Odoo, or in any hosting product including ours, watches your custom fields and tells you which ones stopped being useful. Usage is a business judgment, and finding it is manual work, but it is not hard work:
- Sit with each department head for twenty minutes with the list of custom items that touch their area. Ask, item by item, what breaks if it disappears. The honest answer is often "nothing, we stopped doing that."
- Look at whether the data behind a custom field is still arriving. A field that has been blank on every record created this year is not in use, whatever anyone tells you.
- Check who actually receives your automated emails and custom reports, then ask two of them what they do with the last one they got.
- Read your own request history. If a change was built for a specific customer, project or regulation, confirm that customer, project or regulation still exists.
Retiring is a change, not a deletion
The mistake is treating removal as cleanup that does not need the same care as building. It does. A retirement is a change to a production system and deserves the same path as any other: a written description of what is being removed and what happens to the data behind it, a preview environment where the affected screens and reports are opened and checked, and then production.
Two practical rules make this safe. First, hide before you delete. Remove a field from the views, leave the column and the history in place, and give it a quarter. If nobody notices, it was genuinely orphaned. If someone shouts in week two, you have lost nothing. Second, never retire during the same window as an upgrade. You want to know which change caused a surprise.
On Plemo, a removal goes through the same flow as an addition. You describe what you want gone in chat, the request comes back as a written spec you approve before any work starts, and the result appears in a sandbox copy of your database so you can open the real screens with your real data before anything reaches production. Reviewing a removal in a sandbox is more valuable than reviewing an addition, because what you are checking for is the thing you forgot depended on it.
Put it on the calendar once a year
A yearly review, scheduled a month or two before your upgrade window, is enough. It takes a few hours across a few conversations, it usually retires somewhere between a fifth and a third of what has accumulated, and every item it removes is one fewer thing to test on the next version. If you would rather have someone run the review with you and hand you a defensible list, that is part of what our team does under custom development.
The goal is not a minimal instance. It is an instance where every custom thing in it can be justified out loud by someone who still works there.