When a company budgets for an ERP project, the line items are predictable: licenses, implementation hours, training, maybe a contingency for scope changes. Data migration rarely gets its own line. It gets folded into "implementation" as if it were a formality, something the new system handles automatically once someone exports a few spreadsheets.
In our experience, that assumption is where a lot of Odoo projects lose their timeline. Migration isn't a technical step you do in the last two weeks before go-live. It's a discovery process that forces a company to confront what its data actually looks like — and that's usually messier than anyone expected.
Why it's harder than it looks
Legacy systems accumulate years of workarounds. A customer might exist three times under slightly different names because three different salespeople entered it independently. A chart of accounts might have categories nobody remembers the purpose of. Product references might be inconsistent between the accounting system and the spreadsheet the warehouse actually uses. None of this shows up as a problem until you try to map it into a structured system that enforces consistency.
- Duplicate or near-duplicate customer and vendor records
- Inconsistent product codes across departments
- Historical transactions with missing or invalid references
- Data spread across multiple disconnected tools (accounting software, Excel, email)
- Fields that were repurposed informally over time and no longer mean what their label says
Not everything needs to migrate
One of the most common mistakes is treating migration as an all-or-nothing export. Companies try to bring years of historical transactions into the new system when most of that data only needs to be archived and accessible, not live in Odoo generating reports. We typically separate data into three categories, and the distinction changes both cost and timeline significantly.
- Master data that must be clean and correct on day one: customers, vendors, products, chart of accounts
- Open transactions that need to carry forward: unpaid invoices, active projects, stock on hand
- Historical records that only need to be archived for reference, not re-entered as live data
Cleanse before you map, not after
Teams often want to migrate the data as-is and clean it up inside the new system later. This almost always backfires. Odoo enforces structure — required fields, relationships between records, validation rules — that legacy spreadsheets never did. Importing dirty data into a structured system just moves the mess somewhere harder to fix, and duplicate records or broken references tend to surface in the middle of daily operations, not during testing.
The better sequence is to cleanse the source data first: deduplicate customers and vendors, standardize product references, decide what an inactive record actually means, and agree on a single source of truth before anything gets mapped into import templates. This step is unglamorous and takes real calendar time, which is exactly why it gets skipped under deadline pressure.
The system doesn't fix bad data. It just makes bad data harder to hide.
Migration testing is not a single pass
A migration should be tested more than once, with real users checking real records against the source system before go-live. In our experience, the first import pass almost always surfaces mapping errors — a currency field misaligned, a tax code mismatched, an account type that doesn't map cleanly to Odoo's structure. Running one dry-run migration, having finance and operations verify a sample of records, then running a second and third pass is standard practice, not extra caution. The last thing a company wants is to discover a mapping error in the accounting module after go-live, when the old system may no longer be reliably updated.
Budgeting for this properly means treating data migration as its own workstream with its own timeline, not an afterthought squeezed into the final sprint. Companies that plan for it upfront go live with confidence in their numbers. Companies that don't spend the first month after go-live reconciling data instead of running their business.
If you're planning an ERP project and want a realistic view of what your data migration would actually involve, book a discovery call. We'll walk through what's worth carrying forward and what isn't.