In this guide 6 sections
List every source system, name one owner for each data type, and clean and deduplicate records in a test environment before anything touches the live system. Rehearse the full move at least once. Rehearsal catches problems while the old system still runs as a safety net, long before a real customer or a real invoice is affected.
Inventory sources and define target data ownership
Find every data location. That includes the accounting package, the sales team’s CRM spreadsheet, a separate billing tool, price lists and the personal notes of whoever has been there longest. Plans that cover only the main system routinely miss data that matters after go-live, such as a credit limit kept in a salesperson’s notebook.
Decide the source of truth. For customers, items, open orders and historical transactions, name the one system that holds the master record and name the person who answers when it is wrong. Without that decision, migrated and newly entered data drift apart within weeks, and nobody knows which version to trust when a customer disputes a balance.
Clean, map, deduplicate and validate records
Say a regional retail chain is moving years of customer and billing history from an older desktop system into a new ERP. A rehearsal exposes duplicate customers. Trading names, abbreviations and typos split one buyer into three records, so the team merges them before any of them reaches the live system.
Map every field explicitly. Write down which old field feeds which new field, what transformation applies, and which values need translating, such as old tax codes, unit names and customer categories. Validate mandatory fields before the load. A record missing a required field either fails to import or arrives with a blank that somebody must chase down weeks later.
Plan permissions, secure transfer and reconciliation
Limit access during transit. Use a controlled transfer method such as an access-restricted shared folder or the vendor’s import tool, and stop passing customer and financial spreadsheets around by email between colleagues. Migration exposes sensitive data more than usual.
Reconcile after every batch. Compare record counts and key totals, such as outstanding receivables, stock quantities and open order values, between old and new systems before the next batch starts. Batch-level checks catch errors early. Otherwise a mismatch may stay hidden until everything has moved and the old system has been switched off, when fixing it costs far more.
Rehearse the migration and the rollback
Rehearse in a test environment. Use an actual copy of production data, not a sample, because problems that stay invisible in fifty records often appear reliably at the full volume of ten thousand.
Test the rollback as well. If the live run reveals a serious fault, you need a defined way back to the old system that does not lose whatever users entered during the gap. Do not improvise on cutover night.
Approve cutover and run post-migration checks
Get sign-off from every data owner. It should come from the finance lead, the sales manager and the warehouse supervisor who use the data daily, not only from IT or the implementation team. They confirm the rehearsal numbers look right.
Check records, not only totals. Open a sample of orders with partial deliveries, customers with credit notes and items with several units of measure, because totals can agree while individual records are wrong. Keep the old system in read-only mode for a defined window instead of switching it off the day the migration finishes, since week one surfaces what rehearsal missed.
Migration mapping and reconciliation sheet
One row per field. Columns hold source field, target field, the transformation rule applied, and a record-count and key-total comparison between old and new systems for every batch, giving a checkable trail.
Open a blank worksheet to printQuestions owners ask
Should all historical data be migrated?
Usually not all of it. Keep open orders, current stock and active customers live and editable, and move older history to a read-only archive export staff can still search.
How do we confirm nothing was lost?
Reconcile before you decommission. Compare record counts and key totals, such as the sum of outstanding balances, between old and new systems, then open complex records yourself instead of trusting totals alone.
Who should own the migration?
A single accountable owner. Pick someone from the business, not only from IT, who can approve mapping decisions, resolve duplicate records and stop the cutover if the reconciliation numbers disagree.