Ask a team what data they want in the new ERP and the answer is almost always "everything." It feels safe. It is the single most reliable way to turn a go-live into a three-week forensic exercise where nobody trusts the numbers on either system.
The better question isn't what data do we have. It's what decisions does the new system need to make on day one? Almost everything else is history, and history has cheaper homes than a production ERP.
The "Bring Everything" Instinct Is Expensive
Every record you migrate has to be mapped, cleaned, loaded, validated, and reconciled. A customer record isn't one field — it's a billing address, a ship-to, payment terms, a tax configuration, a credit limit, a salesperson assignment, and whatever got typed into the notes field over a decade. Multiply that by inventory items, vendors, open orders, and transaction lines, and the migration quietly becomes the largest work stream in the project.
It also becomes the largest risk. Legacy systems accumulate duplicates, inactive records, discontinued SKUs, and customers who haven't ordered since two owners ago. Load all of it, and your new ERP launches with a search box that returns four versions of the same account. That's not a data problem anymore — it's an adoption problem, because people stop trusting the system in week one.
Sort Everything Into Three Buckets
Before anyone builds a mapping spreadsheet, force the business into a decision on three categories:
- Open items. Unpaid invoices, open purchase orders, unfulfilled sales orders, work in progress, current inventory quantities and valuations. These must move. The business cannot operate without them, and they have to tie out to the penny.
- Balances. Trial balance, AR and AP aging, fixed assets. You're migrating positions, not the transactions that created them. Most companies bring in summary balances as of the cutover date rather than replaying years of journal entries.
- History. Closed orders, paid invoices, old quotes, legacy general ledger detail. This is where the argument happens, and it's the bucket where "everything" does the most damage.
The discipline is simple: open items and balances get migrated and reconciled. History gets a retrieval path, not a live record.
History Needs Access, Not Residency
When someone insists on five years of transaction history in the new ERP, they rarely need it inside the ERP. They need to answer a question: what did we charge this customer last year, what did that part cost, what did we promise on that contract.
Those questions are answered just as well by a read-only archive — the legacy system kept running in a locked state, a reporting database, or an exported dataset in your warehouse or Business Hub. The cost difference is enormous, because an archive doesn't need to conform to the new system's data model, validation rules, or chart of accounts.
What the archive does need is a documented retrieval path. Who can get to it, how long it stays available, how a request gets fulfilled, and what the legal and tax retention requirements actually are. Write that down and circulate it. Most history requests disappear once people know there's a reliable way to answer them.
Clean at the Source, and Name an Owner
Cleansing done inside the migration tooling is cleansing nobody else can see. Do it in the legacy system, or in a staging extract the business team can review, so the people who know the customers are the ones deciding which duplicate survives.
That means naming owners before extraction: one person accountable for the customer master, one for vendors, one for items, one for the chart of accounts. Not a committee. A name. Their job is to approve the final list and to sign off that inactive records stay behind.
This is also the moment to fix the structural stuff — numbering conventions, unit-of-measure standards, item categories, the chart of accounts you've wanted to simplify for years. Changing it during migration is work. Changing it after go-live is a project.
Prove the Cutover Before You Run It
A migration you've executed once, on go-live weekend, is a hypothesis. Run it as a full dry rehearsal at least twice, against production-volume data, with the clock running. You're testing three things: that the load completes in the window you have, that the reconciliation ties, and that your team can actually do the steps under pressure.
Reconciliation deserves its own checklist, agreed in advance with whoever signs the financials. Trial balance matches. AR and AP aging totals and bucket distribution match. Inventory quantity and value match. Open order counts match. Define what variance is acceptable and who approves it, before anyone is tired and the warehouse is waiting to ship.
Then define the freeze: when transactions stop in the old system, who has permission to enter anything, and how you handle the inevitable order that arrives mid-cutover.
Decide Early, Not Under Pressure
Migration scope is a business decision wearing technical clothing. Made deliberately in planning, it's a short series of conversations. Made by default, it gets made at 2 a.m. on a Saturday by whoever is still on the call.
If you're scoping an ERP implementation and the data conversation hasn't happened yet, that's the conversation to have first. We'd be glad to walk through it with you — get in touch and we'll help you draw the line between what moves and what gets archived.