Most ERP sales conversations focus on features: dashboards, automation, reporting. Almost none of them spend real time on data migration. Then three weeks before go-live, someone asks where the historical invoices, the open purchase orders, and the current stock levels are supposed to come from, and the project stalls.
In our experience, data migration is the single most underestimated piece of an Odoo implementation. It is not glamorous, it does not show up in a demo, and it is usually the reason go-live dates slip.
Why It Gets Underestimated
Migration looks simple on paper: export from the old system, import into the new one. In practice, the data sitting in spreadsheets and legacy software is rarely clean. Customer records are duplicated under slightly different names, product codes were reused for different items over the years, and historical transactions don't map cleanly to a new chart of accounts. None of this is visible until someone actually tries to load the data.
- Duplicate or inconsistent customer and supplier records
- Product references that changed meaning over time
- Stock quantities that don't match physical counts
- Years of accounting history with no consistent categorization
- Data spread across multiple tools that were never connected
What Actually Needs to Move
Not everything needs to migrate, and treating all data as equally important is a common mistake. We typically separate data into three buckets: what must be live on day one, what should be available for reference, and what can stay archived in the old system.
- Master data: customers, suppliers, products, chart of accounts — must be clean and complete before go-live
- Open transactions: unpaid invoices, active purchase orders, current stock — must migrate accurately
- Historical records: closed invoices, old projects — usually summarized or kept in a read-only archive instead of fully migrated
Trying to migrate ten years of granular transaction history into a new system is rarely worth the effort. A summarized opening balance, with the legacy system kept accessible for lookups, gets you live faster and avoids importing years of inconsistent data into a clean new database.
The Real Timeline
Data cleansing and migration usually take longer than the configuration work itself, simply because cleaning data requires decisions from people across the business, not just from the implementation team. A purchasing manager has to confirm which supplier records are actually active. A controller has to approve how historical balances get summarized. This coordination is slow, and it should be scheduled early, not squeezed into the final weeks before go-live.
Clean data takes longer to prepare than the software takes to configure. Plan the migration timeline around the data, not the other way around.
How to Reduce the Risk
A few practices consistently make migration less painful. None of them are complicated, but they require discipline early in the project rather than late.
- Run a data audit before the kickoff, not during it, so cleanup work starts in parallel with configuration
- Assign a business owner — not just IT — to approve master data accuracy
- Migrate in stages: test imports, validate, fix, re-import — never go live on a first-pass import
- Keep the old system accessible read-only for a defined period instead of forcing full historical migration
- Budget time for reconciliation: matching opening balances against the legacy system before go-live
If your team hasn't talked about data migration yet, it's worth raising before the project plan is finalized. Book a discovery call if you want to explore whether this applies to your business.