Clean Data, Clean Start: Why Quality Matters in Odoo Setup

Data migration is the part of an Odoo implementation most likely to be underestimated and most likely to damage trust in the new system. Not because moving records is hard, but because the records you are moving are usually worse than anyone thinks. Clean them before the build, not during it.

This page covers what bad data actually costs once it is inside Odoo, how to decide what comes across, the order the work has to happen in, and who should own it.

What does bad data cost after go-live?

It costs adoption, which is the expensive one.

A user who searches for a customer and finds three versions of them stops trusting the system within a week. They go back to the spreadsheet they were told to abandon, and they are right to, because the spreadsheet is the one they can rely on. Once that happens in one team it spreads, and no amount of training reverses it.

The visible costs come later:

• Reporting that cannot be defended. Margin by product is meaningless if the same product exists four times under four codes.
• Stock that does not reconcile. Opening balances loaded without checking against the old system leave a variance nobody can explain six months on.
• Duplicated effort. Someone maintains the clean list on the side, which is the exact situation the project was meant to end.

Odoo does not create these problems and it does not fix them. It makes them visible to more people at once.

What should come across, and what should not?

Less than you think. Ten years of dead contacts and obsolete SKUs is not history, it is weight.

A workable default for an Australian SME moving off Xero, MYOB or a stack of point tools:

• Customers and suppliers: those transacted with in the last 24 to 36 months. Archive the rest rather than deleting them.
• Products: those sold or purchased in the last 12 to 24 months, plus anything under warranty or service obligation.
• Open transactions: unpaid invoices, open purchase orders, open sales orders. All of them, in full.
• Opening balances: trial balance, stock on hand by value, aged receivables and payables as at the cutover date.
• Historical transactions: usually summarised rather than loaded line by line. Keep the old system readable for a year instead.

The argument for loading everything is that someone might need it. The argument against is that everything you load, you own: it appears in searches, it appears in reports, and it has to be corrected when it is wrong.

What does cleaning actually involve?

Four passes, in this order. Doing them out of order means doing them twice.

1. Deduplicate. Same customer under a trading name and an entity name. Same product under a supplier code and an internal code. This has to happen before anything is mapped, because a merge after mapping breaks the mapping.
2. Standardise. One format for ABNs, phone numbers, addresses and units of measure. Decide whether a unit is each, box or carton, and apply it to the whole catalogue rather than per product.
3. Complete. Fill the fields the new processes depend on. If pricing is going to run off a customer price list, every customer needs the field that decides which list they are on.
4. Classify. Product categories, customer segments and account mappings. This is where the reporting you asked for is either made possible or quietly made impossible.

Classification is the pass most often skipped, and the one that determines whether the first board report comes out of Odoo or out of a spreadsheet built from Odoo.

Who should own the data?

Someone inside the business, named, with time allocated.

This is not work an implementation partner can do alone, and a partner who offers to is telling you they will guess. Only the business knows that two customer records are the same company, that a product line was discontinued, or that a price has not been charged since 2023.

What works in practice is a split: the partner produces the extracts, finds the duplicates and flags the gaps; the business decides. Ooda Consulting builds the comparison files and sits with the people who know the answers rather than emailing a spreadsheet and waiting.

For businesses where this keeps recurring after go-live, the problem is usually ownership rather than cleaning. See Data Governance for how that gets settled.

When does the cleaning happen?

Before the build, in parallel with scoping, and it carries on through the project.

The sequence that works:

• Extract early, in week one, before anyone has configured anything. The extract tells you how bad it is, and that changes the project plan.
• Clean in the source system where you can, so the old system stays usable until cutover.
• Load into a copy of the new system, never into live.
• Reconcile on the copy: trial balance, stock on hand by value, open invoices, open purchase orders. They match or you go back a step.
• Cut over only after the numbers reconcile.

Done this way, migration is the least dramatic part of the job. Done as one load on go-live weekend, it is the reason the project is remembered badly. More on that in Why do most Odoo and ERP projects blow out?

Does Odoo help with any of this?

Yes, once the data is inside it.

Import templates validate on the way in, so a malformed record is rejected rather than stored. Required fields can be enforced per model. Duplicate detection runs on contacts. Archiving keeps a record searchable without it appearing in everyday lists, which is the right answer for most of what you were going to delete.

What Odoo will not do is tell you which of two customer records is the real one. That decision belongs to the business and always will.

How we work

Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. The Australian team scopes the work and supports it afterwards, with a dedicated senior developer doing the build.

See Odoo ERP Implementation for how a build is scoped and staged, or Is Odoo the Right ERP for Your Business? if you are still deciding on the platform.

Frequently asked questions