Most Odoo projects do not slip because the software was hard to configure. They slip because the data took three times longer to move than anyone estimated.

That gap is predictable, and it is almost always a planning failure rather than a technical one. Gartner puts the average annual cost of poor data quality to an organization at $12.9 million. A migration is the moment that cost becomes visible, because every shortcut taken in the old system has to be reckoned with before anything loads into the new one.

Here is how experienced consultants structure the work.

Step 1: Decide what actually moves

The first meeting is not about tooling. It is about deciding how much history is worth carrying.

Businesses tend to assume everything must come across. It rarely should. Ten years of closed sales orders add cost to every stage of the migration and value to almost none of them. A more defensible split usually looks like this:

• Master data — customers, vendors, products, chart of accounts, pricelists. This always moves, and it has to be right.
• Open transactions — unpaid invoices, open purchase orders, undelivered sales orders, current stock. This moves because the business cannot operate without it.
• Historical transactions — closed and reconciled records. Often better left in the legacy system as a read-only archive, or loaded as summary balances rather than line-level detail.

Settling this early changes the size of the project. Consultants push for it in week one because every later decision depends on it.

Step 2: Profile the data before committing to a timeline

Estimating migration effort without examining the actual data is guesswork, and it is where most optimistic timelines come from.

Profiling means running counts and checks against the legacy database: how many customer records exist, how many are duplicates under different spellings, how many products lack a unit of measure, how many invoices reference a vendor that no longer exists. The answers routinely surprise the client, which is the point of doing it before a date is promised rather than after.

Overspending on ERP projects is common enough to have been measured. In Panorama Consulting’s 2026 study of implementation outcomes, over 25% of organizations went past their planned budget, and the reason cited most often was technology requirements that nobody anticipated at the outset. Data problems found halfway through a build are a dependable route to exactly that.

Step 3: Map fields and resolve the relationship problem

Field mapping is the part everyone pictures: legacy column on the left, Odoo field on the right. The genuinely difficult part is relationships.

Records in Odoo reference each other. An invoice points to a customer. A product points to a category and a unit of measure. A sales order line points to both a product and an order. If those links are not reconstructed correctly, the import produces records that exist but do not connect to anything.

Odoo’s documentation on importing data sets out the mechanism: assign each record an External ID in the import file, then reference that identifier from any record that links to it. It also imposes an ordering constraint that shapes the whole load sequence — related records have to be imported before the records that point at them. Customers and products come first; invoices and orders come afterwards.

This is why a migration runs as a sequenced set of loads rather than a single file, and why consultants document the sequence before writing any import templates.

Step 4: Clean at the source, not in the spreadsheet

There is a strong temptation to fix data inside the import file. It is faster in the moment and it causes problems later, because the corrections are invisible and unrepeatable — the next trial load reintroduces every error.

Better practice is to clean in the legacy system where possible, or to script the transformations so they run identically every time. Anything that has to be repeated a dozen times across trial loads should not depend on someone remembering to repeat it.

Odoo also ships a Data Cleaning application for deduplication and formatting rules, which is useful for maintaining quality after go-live. It is not a substitute for cleaning before the load.

Step 5: Run trial loads, plural

A single rehearsal is not enough. Competent plans budget for three or more.

The first trial reveals structural failures — wrong formats, broken relationships, rejected records. The second tests whether the fixes held. The third measures how long a full load actually takes, which determines whether the cutover fits into the available window.

Each trial should run into a fresh database. Loading into an environment that already contains records from the previous attempt produces results that cannot be trusted.

Step 6: Reconcile before anyone signs off

The migration is not finished when the import completes without errors. It is finished when the numbers match.

Reconciliation means agreeing a small set of control totals in advance and checking them on both systems: total accounts receivable, total inventory value, customer record count, open order count. Finance should confirm these, not the technical team, because finance is the function that will notice a discrepancy six weeks later.

Records that legitimately did not migrate need to be documented too. An unexplained gap between two systems becomes an audit problem.

What still goes wrong

Even a well-planned migration has limits worth stating plainly.

Data cleanup is client work. A consultant can identify the four thousand duplicate contacts, but somebody inside the business has to decide which version of each is correct. Where that resource is not assigned, the timeline slips regardless of how good the plan was.

Decisions about history also tend to get reopened late. A stakeholder who agreed to archive old transactions in month one often asks for them in month three, once the reality of not having them lands. Locking that decision in writing early saves a difficult conversation later.

The question worth asking upfront

When reviewing a proposal for Odoo data migration, look for how many trial loads it includes and who owns data cleanup.

A plan that mentions neither is not a plan. It is an estimate that will be revised.