Updated September 2026: the original 2021 post argued that data conversion is where many IT vendors fail, and that vendors should use a structured process, involve business experts, share capture templates and validate migrated data. I have expanded it into a practical guide to data migration for a new business application.
Data migration is often the least glamorous part of an implementation and the one most likely to delay go-live. Vendors focus on configuring the new system, and data is left until late, when problems in the old data surface all at once. A structured approach avoids most of that.
What are the stages of a data migration?
- Scope: decide which data moves: master data, open transactions, history, documents.
- Mapping: map each field in the old system to the new one, including code values.
- Cleansing: fix duplicates, gaps and outdated records before migrating, not after.
- Extraction and templates: capture data in agreed templates, often spreadsheets, from the old system.
- Loading: upload using the new system's tools or interfaces, in the right order.
- Validation: reconcile counts and totals, and have business users check samples.
Who should own each part?
The vendor owns the method, tools, templates and loading. The business owns the data: deciding what moves, cleansing it and signing off that it is correct. Migrations fail when business experts are not given time to cleanse and validate.
How much history should you migrate?
Less than people first want. Open transactions and a limited history, often one or two years, usually cover operational needs. Older history can stay in an archive or read-only copy of the old system, which is cheaper and reduces migration risk.
How do you validate migrated data?
Reconcile record counts and financial totals between old and new systems, then check a sample of records field by field. For finance, trial balances and open item totals must match exactly at cut-over. Record the checks and have business owners sign them off.
Why rehearse the migration?
Because the first full load always reveals problems: wrong mappings, missing dependencies, slow loads. Plan at least one full dress rehearsal with realistic data volumes, timed, before the real cut-over weekend.
No comments
Post a Comment