The short answer
Decide around your actual service
A successful data migration starts by deciding which data is genuinely needed in the new system, for which purpose and for how long. Inventory the sources, assign a business owner, define mappings and clean data before loading. Then rehearse the migration on representative datasets and validate volumes, totals and business cases before cutover.
Editorial review: · BINOV (opens in a new tab)
Inventory and reduce the scope
Catalogue sources, formats, volumes, periods, owners and quality levels. Separate active reference data, transactions, documents and history. For every dataset, record its future purpose, useful lifetime and the basis for processing it.
Do not migrate data merely because it exists. Some information may be archived with controlled access, aggregated or deleted according to applicable obligations. This decision reduces risk, cost and the number of anomalies to resolve.
Define mappings and clean the data
Create a dictionary that records each field’s source, target, format, transformation rule, default and validation. Preserve historical identifiers needed for reconciliation even if the new system creates its own keys.
Handle duplicates, missing values, encodings, dates, units, addresses and obsolete categories with business-approved rules. Every bulk correction should be traceable and repeatable; avoid manual edits that cannot be replayed.
Rehearse loads and reconcile results
Run several dry migrations on a controlled copy: extract, transform, load and reject report. Include common and difficult cases as well as relationships, such as products and prices, sites and tills, or customers and consent records.
Acceptance combines technical and business controls: record counts, checksums, financial totals, uniqueness, links, samples and target-application scenarios. Assign every discrepancy and set the threshold that blocks cutover.
Organize cutover and post-migration work
Document the change freeze, final extract, loading order, validations, communications and the decision to continue or fall back. Timings should have been measured in a rehearsal using a volume close to production.
After go-live, monitor rejects, total discrepancies, access and corrections. Retain acceptance evidence and plan the closure of legacy access, archival or deletion according to the obligations selected.
Compare the options
Scroll horizontally to read the full table.
| Step | Risky approach | Controlled approach |
|---|---|---|
| Scope | Move everything by default | Justified purpose, lifetime and owner |
| Cleaning | Manual edits in the final file | Repeatable, logged rules |
| Loading | One test just before cutover | Rehearsals on representative cases and volume |
| Validation | Check a few screens | Reconcile volumes, totals, links and scenarios |
| Cutover | Timeline without a fallback decision | Documented owners, thresholds and rollback |
Your checklist before choosing
- Inventory sources, formats, volumes, periods and owners.
- Justify which data is migrated, archived, aggregated or deleted.
- Create the mapping dictionary and validation rules.
- Clean with repeatable and traceable processing.
- Test relationships, edge cases and near-production volumes.
- Reconcile record counts, totals and business samples.
- Set decision thresholds, fallback plan and owners.
- Plan monitoring and the future of the legacy system.
Worth sharing
Could this guide help your team or network?
Send it to the relevant people to support your next decisions.