Ask any operator who has lived through an ERP go-live what went sideways, and you'll rarely hear "the software couldn't do it." You'll hear that customer addresses were wrong, that inventory counts didn't match the floor, that half the item numbers had two versions, that the AR aging in the new system didn't tie to the old one. Data is where ERP projects quietly lose weeks and credibility.
The good news: data migration is one of the most controllable parts of an implementation. It just has to be treated as its own workstream with its own owner, its own timeline, and its own definition of done — not as a task someone squeezes in during the last two weeks.
Three buckets, not one pile
The most useful first move is to stop talking about "our data" as a single thing. Sort it into three buckets, because each one gets handled differently.
- Master data — customers, vendors, items, price lists, chart of accounts, employees, bills of materials. This is the foundation and it must be clean before anything else lands on top of it.
- Open transactions — unpaid invoices, open purchase orders, current sales orders, on-hand inventory, work in progress. These need to move so the business can keep operating on day one.
- History — closed invoices, paid bills, years of past orders and journal entries. This is the bucket people assume must come across in full. Usually it shouldn't.
Once you separate these, the conversation changes from "how do we move everything?" to "what does the business actually need in the new system to run and to report?"
Clean before you map, not after
Migration mistakes usually trace back to cleaning data inside the new system instead of before it moves. That's backwards. Once bad records are in the ERP, they're attached to transactions, and unwinding them means touching live documents.
Do the cleanup in the source, or in a staging spreadsheet with clear rules. Decide, in writing, what makes a duplicate a duplicate. Decide what happens to a customer with no activity in three years — deactivate, don't import. Decide the naming convention for items and stick to it before anyone types a single record into the new environment. Decide who owns the chart of accounts and whether go-live is the moment to restructure it, because trying to redesign your financial reporting during a migration is how a six-week project becomes a six-month one.
This is also the moment to strip out fields nobody uses. Legacy systems accumulate columns that made sense to someone who left years ago. Migrating them costs mapping effort and clutters every screen afterward.
History belongs in an archive, not your general ledger
The instinct to bring ten years of transaction history into a new ERP is understandable and almost always expensive. Every year of history multiplies mapping complexity, testing effort, and the chance of a mismatch nobody can explain.
A cleaner pattern: bring in opening balances and open items, plus a limited window of transactional history if you genuinely need it for comparative reporting. Keep the legacy system available read-only for a defined period, or extract historical data into a warehouse or reporting layer where finance and support can query it without it living in your operational ledger. Auditors and long-tail customer questions get answered. Your new system stays fast and comprehensible.
Write down the retention decision and who approved it. "We only have three years of history in here" is a fine answer when everyone agreed to it in advance and a crisis when it's discovered in month two.
Practice the load more than once
A single migration attempt on cutover weekend is a gamble. Plan at least two or three full dry runs into a test environment, each one timed. The first run finds structural problems. The second finds edge cases. The third proves the runbook and tells you how many hours cutover will actually take — which is what lets you decide whether you can do it over a weekend or need a longer pause.
Each run ends in reconciliation, not a vibe check. Tie out the trial balance. Tie out AR and AP aging by bucket. Tie out inventory by quantity and value. Count records in and records out. Anything that doesn't match gets documented and resolved before the next run, not waved through.
Give every domain a human owner
The technical team can move data. Only the business can say whether it's right. Name a specific person for customers, for items, for finance, for inventory — someone who knows the real-world truth and will sign off before go-live. That signature is worth more than any validation script, because it puts judgment behind the numbers and it means the people who will use the system have already looked at their own data.
Migration done well is invisible: on Monday morning, people log in, find their customers, ship their orders, and stop thinking about the project. That outcome comes from triage, sequencing, and rehearsal — decisions made months before cutover.
If you're planning an Odoo or ERP move and staring at years of accumulated records wondering what to do with them, that's exactly the conversation worth having early. Reach out to Infraxio and we'll help you sort the buckets before they sort you.