An Odoo migration can look like a technical project. In practice, it is usually a debate about operational discipline: which data helps people sell, buy, collect and deliver better, and which data only adds noise. My thesis is straightforward: you should not migrate years of useless data just because it exists. The more “complete” the copy, the more likely you are to carry forward errors, duplicates and process debt that the new system merely hides under a nicer interface.
The real risk is not losing data. It is keeping the wrong data.
The real scene: when the dashboard lies
Picture a mid-sized company with 40 employees, several product lines and an admin team living between spreadsheets and internal email threads. On the dashboard, everything looks acceptable: orders are moving, stock is visible, customers are “in the system”. But the real workflow lives elsewhere: sticky notes, WhatsApp messages, duplicate records and documents that “will be reviewed later”.
That is the friction a migration to Odoo can reveal or hide. If you only look at the dashboard, you see activity. If you look at actual work, you see exceptions. And exceptions are what consume time.
The right question is not how many records you have, but how many records are alive, closed or dead. A two-year-old open order is not an asset; it is often an anomaly that pollutes reports, search results and expectations.
What to clean, archive and reconcile
Before moving anything, split the data into four groups:
- What must travel because it is still active and affects daily operations.
- What should be archived because it has legal, historical or traceability value, but should not mix with current work.
- What must be reconciled because the same data exists in two places and does not match.
- What can be left out because it no longer drives decisions or compliance, even if people are used to seeing it.
This is where the first uncomfortable mistake appears: treating the archive like a trash bin. It is not. Archiving means preserving without getting in the way. For leadership, that matters because a system full of dead records slows searches, confuses teams and creates a false sense of precision.
Odoo’s documentation makes two points that matter here. First, an upgrade is not the same as migrating another ERP into Odoo. Second, if you have custom modules, their compatibility must be ready before the upgrade can be completed. Odoo also recommends requesting an upgraded test database first and spending time testing it, because the process is easier when the version gap is smaller. (odoo.com)
The expensive mistake: calling cleanup a delay
Many teams postpone data cleanup because they fear that “reviewing data” will slow the project down. Sometimes it will. But that delay is usually cheaper than discovering later that the new ERP simply reproduces the same problems with a more modern screen.
The practical rule is this: if a record cannot be explained in two sentences, it is probably not ready to migrate as-is. That applies to customer references, order states, legacy price conditions, old product catalogs and addresses nobody has used for years.
A common scenario: sales wants to keep everything “just in case”, finance asks for rigor, and operations only wants the system to stop blocking orders. That conflict is not solved by adding more fields or promising to clean things up later. It is solved with visible criteria:
- Is it used in a weekly decision?
- Does it have a clear owner?
- Can it be validated against a reliable source?
- Does it affect cash, delivery or compliance?
If the answer is no to three out of four, it is not ready to move as live data.
A reversible experiment before the big change
You do not need a giant program to start well. A small reversible test often tells you more than twenty meetings.
The experiment I recommend is simple: choose one data family, such as customers or products, and build three lists before the pilot migration: active, archive and manual review. Then check what percentage fails reconciliation, which fields are missing and how long the team needs to resolve doubts.
That exercise teaches something important: this is not about “migrating better”, but about operating with less uncertainty. If the pilot reduces internal calls, manual corrections and rework, you already have a useful signal. If not, the problem is not the tool; it is the quality of the decision made before the move.
In a realistic mini-case, a company discovers that 12% of its customer records are duplicates. It does not need a big transformation to start; it needs to decide who owns each record and which version of the data wins. That decision, more than the software, is what brings order.
What leadership should actually take away
An Odoo migration should not be judged by how clean the system looks on day one, but by whether the team stops relying on workarounds to operate. A new ERP does not fix a misaligned organization on its own. But it does force hidden problems into the open.
If the company uses the migration to remove dead data, archive with discipline and test with a small case first, it wins twice: less technical risk and better operations from the start.
Three realistic actions for this week:
- Review one critical table and mark which fields are not used in any decision.
- Ask the team to identify three record types that should be archived, not migrated as active.
- Choose a small data set for a reconciliation test and measure how long it takes to resolve mismatches.
At Codefuente, that is usually where the useful conversation begins: deciding which data deserves to stay alive, and which data is just taking up space.