Most companies budget time for choosing an ERP, configuring modules, and training staff. Almost none budget enough time for moving their existing data into the new system. In our experience, data migration is the phase most likely to blow a project timeline — not because it's technically exotic, but because nobody scoped it properly at the start.
The assumption is usually that migration means exporting a few spreadsheets and importing them into Odoo. It rarely is. Real migration means reconciling years of inconsistent record-keeping, deciding what history is worth carrying forward, and making sure the numbers in the new system actually match the numbers in the old one on day one.
What Actually Gets Migrated
A typical migration touches far more than customer and product lists. Depending on the business, the scope usually includes:
- Customer and vendor master data, often duplicated across Excel, email, and an old system
- Chart of accounts and opening balances
- Open invoices, unpaid bills, and outstanding purchase orders
- Current stock levels and valuation, by location and lot when relevant
- Bills of materials and routings for manufacturers
- Active contracts, projects, and timesheets for services firms
Each of these has a different level of urgency and a different risk if it's wrong. Getting opening stock valuation wrong distorts margins for months. Missing an open invoice means a customer gets billed twice — or not at all.
Why It's Harder Than It Looks
The technical part of moving data — writing an import script, mapping fields — is usually the easy part. The hard part is that the source data is rarely clean. We typically find duplicate customer records under slightly different names, product codes that were reused for different items over the years, and historical transactions that don't reconcile against the accounting system anymore. None of that shows up until someone actually tries to migrate it.
This is also where scope creep quietly enters. A migration that starts as "bring over the last two years of data" can turn into a full audit of a decade of records if nobody sets a boundary early.
A Practical Approach
The projects that go smoothly treat migration as its own workstream, with its own timeline, not an afterthought squeezed in before go-live. A few practices that consistently help:
- Audit the source data before scoping the migration, not during it — you need to know what's actually dirty before you can estimate cleanup time
- Clean data in the old system first where possible, rather than trying to fix it during import
- Decide explicitly what historical data is worth migrating versus archiving as read-only reference — not everything needs to live in the new ERP
- Migrate and test in phases: master data first, then open transactions, then historical records
- Run the old and new systems in parallel for a short window and reconcile key totals before fully cutting over
The businesses that struggle most after go-live are rarely the ones with the most complex processes — they're the ones that went live with data nobody had actually verified.
None of this is unique to Odoo — it's the same discipline any ERP migration requires. What differs is how much of it can be scripted versus done by hand, and that's a scoping conversation worth having before a contract is signed, not after.
If you're evaluating an ERP switch and want an honest read on what your data migration would actually involve, book a discovery call if you want to explore whether this applies to your business.