Most teams treat ERP data migration as a copy job. Old system on the left, new system on the right, move everything across. That framing is why so many go-lives slip. Migration isn't a copy job — it's an editorial decision about what your business actually needs to operate on day one. And the hardest part isn't moving data. It's deciding what not to move.
We've watched capable teams spend weeks arguing about fifteen-year-old customer records that nobody would have looked up if the old system had simply been unplugged. The argument is never really about the data. It's about fear: nobody wants to be the person who deleted the thing someone needed. So everything comes across, the mapping work triples, testing becomes unmanageable, and the new system launches full of garbage that quietly erodes trust in every report it produces.
A cut list fixes this. It's a written, owned, signed-off decision about each category of data — migrate, archive, or drop.
Start From the Process, Not the Tables
The instinct is to open the old database, list the tables, and work through them. That guarantees over-migration, because every table looks important when you're staring at it out of context.
Instead, start with the processes the new system has to run. Quoting. Order entry. Purchasing. Inventory counts. Invoicing. Collections. For each one, ask: what does someone need in front of them to do this job on Monday morning? That question produces a much shorter list than the table inventory does, and it produces it in business language your team can actually debate.
Open transactions almost always make the list. Active customers and vendors make the list. Current inventory, open POs, unpaid invoices, live contracts — all necessary. What follows is where the discipline is required.
Closed History Is an Archive Problem, Not a Migration Problem
The single biggest source of migration bloat is closed historical transactions: shipped orders, paid invoices, completed jobs going back a decade. Teams want them in the new ERP because that's where people will look.
But ask what they'll actually do with them. Usually it's three things: answer a customer question about an old order, satisfy an auditor, or run a trend report. None of those require the records to live inside your operational ERP.
There are cleaner ways to keep history available:
- Keep the legacy system running read-only for a defined window, with a named owner and a decommission date
- Export closed transactions into a reporting database or warehouse where analysts can query them
- Generate PDF or flat-file archives for documents with retention requirements
Summary balances often serve better than transaction detail. Opening balances per customer, per vendor, per item — clean, reconcilable, and dramatically less work to validate than a decade of line-level history.
Cleansing Needs an Owner and a Deadline
Every migration surfaces the same mess: duplicate customers, vendors with three spellings, part numbers with trailing spaces, addresses in the notes field. Migrating that mess into a new system doesn't launder it. It just moves your data quality problem to a more expensive platform.
Cleansing works when it's assigned to the people who own the records — sales owns customers, purchasing owns vendors, operations owns items — with a hard cutoff date. It fails when it's assigned to "IT" or to the implementation partner, because neither has the business context to know which of two similar customer records is the real one.
Build the cleansing window into the project plan as its own phase, before mapping. Not alongside testing, where it competes for the same people's attention.
Rehearse the Load, and Reconcile Every Time
A migration you've run once is a migration you haven't tested. Plan for multiple full dry runs into a staging environment, each one followed by reconciliation your finance team performs and signs off on — trial balance ties, AR and AP aging match, inventory quantities and values agree, record counts line up.
Those reconciliation reports are also your go-live gate. If the numbers don't tie in the rehearsal, they won't tie in production, and you'll spend your first month explaining variances instead of running the business.
Document every transformation rule as you go. Six months after go-live, when someone asks why a legacy field landed where it did, that document is the difference between a five-minute answer and a forensic investigation.
The Payoff of Deciding
A good cut list shrinks the scope, shortens the timeline, and — most importantly — gives your team a new system they trust from the first week. Trust is what drives adoption. Nobody adopts a platform whose reports they have to double-check.
If you're planning an ERP rollout and the migration conversation has stalled on what to keep, that's the right conversation to be having — and it goes faster with someone who's made those calls before. Reach out to Infraxio and let's walk through your data, process by process, and build the cut list together.