Ask a team what's holding up their ERP go-live and the answer is almost never the software. It's the data. Specifically, it's the slow realization that nobody agreed on what "migrate our data" actually means — and that the default interpretation, bring everything over, is a project unto itself.
The good news is that data cutover is one of the most controllable parts of an ERP implementation. It gets hard when it's treated as a single monolithic task. It gets manageable when you break your data into categories that have genuinely different rules.
The trap: treating all data as equally urgent
When a company moves from QuickBooks or a patchwork of spreadsheets into a real ERP like Odoo, there's an instinct to preserve every record ever created. Ten years of closed invoices. Customers who last ordered in 2016. Product SKUs that were discontinued two systems ago.
That instinct is understandable and mostly wrong. Every record you migrate has to be mapped, cleaned, loaded, and reconciled. Bad data doesn't get better in a new system — it just becomes bad data your team no longer trusts, in a system they're already nervous about. And the volume buries the records that actually matter: the ones your business runs on tomorrow morning.
Sort your data into four buckets
Before anyone writes a mapping spreadsheet, get agreement on which bucket each dataset falls into:
- Master data — customers, vendors, products, chart of accounts, pricing, BOMs. This is the foundation. It must be clean.
- Open transactions — unpaid AR and AP, open sales orders, open purchase orders, work in progress, on-hand inventory. This is what keeps the business running through cutover.
- Balances — your trial balance as of the cutover date, brought in as opening entries rather than reconstructed transaction by transaction.
- History — everything closed and settled. Archive, don't migrate.
That single sorting exercise usually cuts the migration scope dramatically, and it turns a vague anxiety into four workstreams with different owners and different standards.
Master data is where the real work lives
This is the part teams underestimate. Master data isn't a technical transfer; it's a cleanup project with a technical step at the end.
You'll find the same customer entered three ways. Vendors with no payment terms. Products with inconsistent units of measure. A chart of accounts that grew by accretion, where someone added "Misc Expense 2" because the first one felt full.
Decide now: who owns deduplication for customers? Who signs off on the restructured chart of accounts? Who decides which of your SKUs are actually still active? These are business decisions, not IT decisions, and they need names attached. A new ERP is the rare, legitimate opportunity to retire the cruft — but only if someone is empowered to say delete it.
Open items need a frozen line
Pick a cutover date and treat it as a wall. Transactions that close before the date stay in the old system. Transactions still open on that date move across.
The complication is always the gray zone: partially shipped orders, partially paid invoices, POs received but not yet billed. Work through those scenarios explicitly before go-live weekend, not during it. Write down how each one gets represented in the new system, and have your accountant confirm the treatment. This is the detail that separates a smooth Monday from a month of reconciliation.
History: give people access, not a migration
Most of the demand for historical data isn't operational — it's lookup. Someone needs to answer a customer question about a 2019 order, or pull records for an audit.
Read-only access to the legacy system, or a clean export into a searchable archive, satisfies that need at a fraction of the cost and risk. Set an explicit retention plan and tell the team where to look. What you want to avoid is history dragged into the new system in a half-mapped state, where reports silently include records that were never properly reconciled.
Rehearse the load more than once
A data migration should never run for the first time on go-live weekend. Plan for multiple trial loads into a test environment — the first one to expose the mapping gaps, the second to validate the fixes, the third to prove the process and time it end to end.
Each trial produces a punch list. Each trial should be faster and cleaner than the last. By the final rehearsal, you should know roughly how many hours the real cutover takes and who needs to be awake for it.
Reconciliation is the gate, not the paperwork
Don't declare go-live when the data finishes loading. Declare it when the numbers tie out: AR aging matches, AP matches, inventory counts match, trial balance matches. Define those checks in advance, assign each one to a person, and make sign-off a condition of opening the doors.
If reconciliation fails, you still have the old system and a known-good starting point. That's the whole reason to keep the scope tight — a small migration is one you can actually verify, and one you can roll back.
The payoff
A disciplined cutover does more than reduce risk. It's the moment your team decides what your business actually tracks and who owns each piece of it. Companies that take it seriously come out with cleaner reporting and faster adoption, because people trust what they see on screen from day one.
If you're planning an Odoo or ERP implementation and the data question is where things keep stalling, we've run this playbook many times. Reach out to Infraxio and we'll help you scope the cutover before it scopes you.