What order should data be loaded into a new ERP?

Dependency order. Chart of accounts and currencies first, then tax codes, then customers and vendors, then items and units of measure, then bills of materials, then open balances for receivables and payables, then open sales orders and purchase orders, then inventory quantities, and historical summaries last. Loading out of order creates orphan records that have to be deleted and reloaded.

How much history should you migrate into an ERP?

Usually far less than people first ask for. Open items and current master data have to move. Transaction history rarely does: keep the old system readable for a defined period, or migrate summary balances only. Migrating ten years of transactions multiplies the cleansing work and imports a decade of bad data into a clean system.

How do you know an ERP data migration worked?

It reconciles. Receivables tie to the aged listing, payables tie, inventory value ties to the general ledger, open order counts match, and the trial balance matches the old system on the cutover date. The reconciliation is signed by the person who owns that function, not by the IT team or the implementer.

ERP data migration checklist

The largest block of work in most implementations, and the one most often treated as a technical task. It is mostly a business decision task, taken a few thousand times.

Checklist · updated 2026-09-21

On this page

The rule that saves the most time
What to migrate, what to archive
The loading order
Cleansing, before you map anything
Trial loads
The reconciliations that have to tie
Cutover and the freeze
Five ways this goes wrong

The rule that saves the most time

Migrate what you need to operate and to answer questions. Nothing else.

Every project starts with someone asking for all of the history, because it feels safer. It is not safer. A decade of transactions multiplies the cleansing work, imports every historical error into a clean system, and delays go-live while people argue about records from three managers ago. The safe version is to keep the old system readable for a defined period and migrate only what the business runs on.

What to migrate, what to archive

Data	Decision	Usual cut
Chart of accounts	Migrate, redesigned	Not a copy of the old one
Customers and vendors	Migrate	Active, plus anyone with an open balance or a contract
Items and materials	Migrate	Active and sellable, plus anything on an open order
Bills of materials, routings	Migrate	Current revisions only
Open receivables and payables	Migrate	All open items, at document level
Open sales and purchase orders	Migrate	All, including partially shipped
Inventory quantities and values	Migrate	As counted at the freeze, not as recorded
Transaction history	Usually archive	Summary balances if anything
Closed orders, old quotes	Archive	Leave them in the old system
Attachments and documents	Decide deliberately	Often the biggest hidden volume

The loading order

Dependency order, not convenience order. Loading out of sequence creates orphan records that have to be deleted and reloaded, which is how a migration loses a week.

Foundations

01Entities, sites, warehouses
02Currencies
03Chart of accounts
04Fiscal calendar
05Tax codes
06Units of measure

Master data

07Customers
08Ship-to and bill-to
09Vendors and terms
10Items and materials
11Bills of materials
12Routings
13Price lists and contracts

Balances

14Opening trial balance
15Open receivables
16Open payables

Live transactions

17Open sales orders
18Open purchase orders
19Inventory by location, lot or serial

Dependency orderTop to bottom. Nothing in a layer can be loaded until every layer above it exists, because the records below point at the records above. Loading out of sequence creates orphans that have to be deleted and reloaded.

Company structure: entities, sites, warehouses, currencies
Chart of accounts, fiscal calendar, tax codes
Units of measure and conversions
Customers, then customer ship-to and bill-to addresses
Vendors, then purchasing terms
Items and materials, with their units and default costing
Bills of materials and routings
Price lists, discounts and contracts
Opening trial balance
Open receivables and payables, at document level
Open sales orders and purchase orders
Inventory quantities, by location and lot or serial
Anything historical you decided to keep, last

Cleansing, before you map anything

Cleansing is not a step in the middle. It runs ahead of everything and it has to be owned by the business, not by whoever is writing the load scripts.

Give every master list one owner. A named person who decides what is correct. Without this, cleansing stalls at the first disagreement and never restarts.
Agree the naming standard first, then apply it. One format for company names, one for item codes, one for addresses. Write it down before anybody starts editing.
De-duplicate on a rule, not on judgement. Same tax number, same domain, same address. Judgement calls do not survive four people doing them in parallel.
Flag inactive rather than deleting. You will want to know why a record was left behind.
Fix the source where you can. Cleansing the export while the old system keeps producing dirty records means doing it twice.
Count everything before and after. Row counts, sums and distinct values. Every transformation gets a before and after number.

The most underestimated taskDeciding which of four spellings of a customer is the real one. It looks clerical, it is a business decision, and it has to be made a few thousand times. Budget for it as a workstream with a named owner, not as a task in someone's spare afternoon.

Trial loads

Plan for at least three, and treat the first one as a discovery exercise rather than a failure.

Trial one proves the pipeline works and surfaces the field mapping you got wrong. Expect it to be ugly.
Trial two is about quality: does the data make sense to the people who use it? Have the function owner look at fifty real records, not a report about them.
Trial three is the dress rehearsal, timed. If the full load takes eleven hours, you need to know that before the weekend you have allocated for cutover.

Every trial gets the same reconciliation pack as the real thing. A trial you do not reconcile has told you almost nothing.

The reconciliations that have to tie

This is the part that makes go-live defensible. Each one is signed by the person who owns that function.

Reconciliation	Ties to	Signed by
Trial balance at cutover	Old system, same date	Finance
Receivables total and ageing	Aged listing from the old system	Finance
Payables total and ageing	Aged listing from the old system	Finance
Inventory value	General ledger inventory account	Finance and operations
Inventory quantity by location	The physical count at the freeze	Operations
Open sales orders, count and value	Old system report	Sales
Open purchase orders, count and value	Old system report	Purchasing
Active customer and vendor counts	Cleansed source list	The list owner

If one of them does not tie, do not go live and plan to fix it later. An unreconciled balance at go-live is the single most reliable cause of the shadow spreadsheets coming back, because the first person who spots the discrepancy tells everyone the new system is wrong.

Cutover and the freeze

Announce the freeze window early, and say exactly what people cannot do during it.
Count inventory physically at the freeze. Migrate the count, not the recorded quantity.
Decide in advance how transactions that arrive during the freeze are captured and entered afterwards.
Keep the old system readable, and read-only, from the moment the final extract is taken.
Agree the rollback point before you start, including who is allowed to call it.

Five ways this goes wrong

Migration treated as an IT task. The decisions are about the business, so the business has to make them. IT moves the bytes.
Cleansing deferred until after the load. Now you are cleansing in the new system, in front of users, while they lose confidence in it.
Everything migrated because nobody would decide. The default answer to “should we keep this?” becomes yes, and the project doubles.
One trial load, run late. The timing surprise arrives on cutover weekend.
No named owner per list. Four people cleanse the same file to four different standards.

Where this sitsData migration is stage four of six. The stages before it decide what you are loading into and why. See the six stages of erpification.