Every ERP project hits the day when someone asks, "How much history are we bringing over?" The room goes quiet, and then somebody says "all of it" — because nobody wants to be the person who threw away the past. That one sentence quietly adds weeks to the timeline, invites a decade of bad records into a brand-new system, and turns your go-live weekend into an archaeology dig.
The better move is to stop treating "data migration" as one task. It's three tasks with three different standards of care.
Three Buckets, Three Different Rules
Split everything in your current system into these categories before you write a single mapping spreadsheet:
- Master data — customers, vendors, items, bills of material, price lists, chart of accounts, employees. This is the stuff your new system uses every day. It has to be clean, deduplicated, and standardized.
- Open items — unpaid invoices, unreceived purchase orders, unshipped sales orders, work in process, on-hand inventory, open balances. This is what keeps the business running on Monday morning. It has to be exact and it has to tie to your trial balance.
- History — closed transactions, old quotes, archived tickets, years of posted journal entries. This is reference material. It needs to be accessible, not necessarily resident in the ERP.
Most of the pain in a migration comes from treating all three as if they were the second category. They aren't. Open items deserve forensic precision. History deserves a plan, not a port.
Master Data Is a Cleanup Project, Not a Copy Job
If you move your customer list as-is, you move three spellings of the same company, vendors nobody has paid in years, and item numbers that encode a warehouse layout from two moves ago. The new system will faithfully reproduce every bit of it, and your team will conclude that the ERP is the problem.
Treat master data cleanup as its own workstream that starts early and runs in parallel with configuration. Decide the dedupe rules in advance — what makes two customer records the same entity, how you handle parent companies and ship-to locations, which naming convention wins. Decide what gets archived rather than migrated: inactive records with no activity in a defined window, items you no longer sell, vendors you no longer buy from.
Critically, this is not an IT job. The controller owns the chart of accounts. Sales ops owns the customer file. Purchasing owns vendors. Operations owns items and BOMs. Assign a named human to each data domain and give them authority to make deletion calls. Cleanup without decision rights becomes an endless loop of "let's keep it just in case."
History Belongs in a Reporting Layer
The fear behind "bring everything" is legitimate: people need to answer customer questions about old orders, auditors ask for records, and year-over-year comparisons matter. But none of that requires every historical transaction to live inside the operational ERP, where it slows searches, complicates upgrades, and pollutes reports with records that were never structured the way the new system expects.
The usual answer is summary plus access. Bring summarized balances into the ERP so your financials are complete and comparable. Keep detailed history in a read-only archive, a data warehouse, or the legacy system kept alive in a locked-down state for a defined period. Write down who can access it, how, and for how long. Then the "what if we need it" fear has a concrete answer instead of a vague one.
Reconcile Like an Auditor — At Least Three Times
A migration is not done when the load script finishes. It's done when the numbers tie. Build a reconciliation pack before your first trial load: trial balance, AR aging by customer, AP aging by vendor, inventory quantity and valuation, open order counts and values. Run it against the legacy system, run it against the new one, and explain every variance — not just the big ones.
Do this at least three times: an early dry run to find structural problems, a dress rehearsal on near-final data with real timing, and the live cutover itself. Teams that skip the rehearsal discover during go-live weekend that a load takes six hours longer than anyone assumed.
Who Signs
Before cutover, each data owner signs off on their domain against the reconciliation pack. Not "it looks fine" — a signature against specific numbers. That single step converts a vague collective anxiety into clear accountability, and it dramatically changes how carefully people review during the rehearsals.
Migration scope is one of the highest-leverage decisions in an ERP project, and it's usually made casually, in a hallway, by whoever speaks first. If you're heading into an implementation — or recovering from one that brought too much baggage along — we'd be glad to talk through how to scope it. Reach out to Infraxio and let's look at your data together.