ERP Data Migration Guide: Profile, Cleanse, Rehearse, Reconcile

If ERP projects had a single most common cause of go-live pain, it would be data. Not the software, not the configuration — the customer records, product data, stock quantities and balances moved from the old system into the new one.

This guide describes a migration approach that works, based on what we've seen go right and wrong.

Decide the scope first

Not everything should move. A typical scope:

Migrating detailed history is expensive and rarely used. An accessible archive — the old system in read-only mode or an export database — is usually enough.

Profile before you plan

Data profiling means measuring the quality of each dataset:

• Duplicate customers and suppliers
• Products without costs, weights or units
• Inconsistent units of measure
• Free-text fields where codes should exist
• Orphaned records referencing deleted items

Share profiling results with data owners. Numbers concentrate minds: “1,400 duplicate customer records” gets a different reaction than “some data issues.”

Cleanse at the source

Fix data in the old system where possible, so every extract is cleaner. Business owners decide how to resolve ambiguity — which of three duplicate customers is correct, which unit of measure applies. The migration team provides tools to apply decisions at scale.

Map every field

Document how each source field maps to the target, including transformations, default values and validation rules. Keep legacy identifiers on migrated records so everything can be traced back.

Script the loads

Manual spreadsheet imports cannot be repeated consistently. Script the full pipeline — extract, transform, validate, load — so each run is identical apart from deliberate improvements.

Respect load order: reference data first (currencies, taxes, accounts), then partners and products, then BOMs and price lists, then open transactions, and finally balances.

Rehearse, then rehearse again

A mock migration is a full run into a test environment, followed by reconciliation and user review. Plan at least two:

• Mock 1 finds structural problems.
• Mock 2 confirms fixes and measures timing for the cutover window.

Complex migrations need more.

Reconcile everything

After each run, compare source and target:

• Record counts per entity
• Stock quantity and value by location, lot and product
• Open order totals per customer and supplier
• Receivables and payables by partner
• Trial balance

Finance and operations sign off reconciliation reports. If numbers don't tie out, you don't go live.

Cutover

Cutover combines a transaction freeze, final extract, load and reconciliation in a defined window. A stock count close to cutover is strongly recommended. Communicate the freeze to staff, customers and suppliers in advance.

After go-live

Keep the old system accessible read-only for a period. Monitor data quality in the new system with exception reports, and fix root causes rather than symptoms.

Common mistakes

• Treating migration as a final-week task
• No migration owner on the business side
• One-shot manual imports
• Skipping reconciliation
• Migrating everything “just in case”

For the broader project, see the ERP implementation guide. For migration services, see ERP data migration.