Most ERP project plans give data migration a line item near the end: a week or two before go-live, sandwiched between training and cutover. In our experience, that's almost always the wrong sizing. Migration is not a mechanical export-import step — it's where every inconsistency your company has accumulated over years of spreadsheets, disconnected tools, and manual entry finally has to be resolved, because the new system won't tolerate ambiguity the way Excel did.
This is why data migration is the single most common reason go-live dates slip. Not because the technical transfer is hard, but because nobody scoped the cleanup work hiding underneath it.
Why it's harder than it looks
A spreadsheet or an old system will happily store a customer three different ways, let a product exist with no cost price, or carry an open invoice against a supplier that technically closed two years ago. None of that breaks anything in day-to-day use — it just sits there. An ERP won't accept it silently. Odoo, like any structured system, enforces relationships: a sales order needs a real customer record, a product needs a unit of measure and, usually, a cost, journal entries need to balance. Migration is the point where all of that latent mess surfaces at once.
- Duplicate or inconsistent customer and vendor records
- Products with missing or conflicting costing data
- Historical transactions that don't reconcile against current balances
- Multiple "sources of truth" for the same data across tools
- Custom fields or workflows in the old system with no clean equivalent
What actually needs to migrate
Not everything does, and deciding that early saves weeks. In our experience, most companies only need full historical detail for open items — unpaid invoices, active projects, current stock — and can bring closed history over as summarized balances or reference documents rather than live transactional records. Trying to migrate ten years of granular history into a new system usually isn't worth the effort and rarely gets used once the company is live.
- Master data: customers, vendors, products, chart of accounts
- Open balances: unpaid invoices, outstanding POs, current inventory counts
- Active records: ongoing projects, open contracts, in-progress orders
- Historical data for reference only: closed transactions, old documents
The cleanup is the real project
Cleaning and standardizing data before it moves is typically where most of the migration effort actually goes — not the technical transfer itself. This is also the point where it becomes clear how much manual reconciliation has been propping up the old system. A construction company might discover that job costs were tracked in three different spreadsheets with no shared numbering. A manufacturer might find that stock counts on paper haven't matched the system for over a year. Surfacing this before go-live, not after, is the whole point.
If your data was messy in the old system, migration doesn't fix that — it just makes the mess impossible to ignore.
How to plan for it realistically
Treat data migration as its own phase with its own timeline, not a task nested inside "technical setup." Start by auditing what data actually exists and in what condition, well before any import scripts get written. Assign an internal owner from each department who knows their data's history and can make judgment calls on what to keep, merge, or drop. And budget at least one full test migration with a dry run in a sandbox environment — you want to find broken records and reconciliation gaps while there's still time to fix them, not during cutover weekend.
If you're evaluating an ERP project and want a realistic read on what your migration actually involves, book a discovery call if you want to explore whether this applies to your business.