Data Migration: Definition and Main Risks
What is data migration
Data migration is the process of moving information from one system to another: from an Access or Visual FoxPro database to SQL Server, from an old ERP to a new one, or from an in-house application to a modern platform. It is not about copying tables. It is about records meaning the same thing in the target system, with their keys, relationships and history, and being able to prove it.
In many modernization projects, data migration is the riskiest step. New code can be tested and fixed; a badly transformed record can go unnoticed for months.
How it's done: a data migration plan
A data migration plan usually includes these phases:
- Discovery and profiling. Record counts, types, character encoding, empty fields, out-of-range dates, duplicates and records flagged as deleted are examined.
- Target model and mapping rules. For each table, the source, the transformation of each field, the handling of nulls, dates and decimals, and which records are excluded and why are documented.
- Initial load and synchronization. If the project runs in phases, history is loaded and changes are synchronized until the new system takes over.
- Reconciliation. Source and target are compared before the migration is declared finished.
- Cutover. The moment the new system becomes the source of truth is set, with a plan to roll back if something fails.
The main data migration risks
- Hidden rules. A table that looks auxiliary may feed into a pricing calculation or into permissions.
- Unapproved cleanups. An old code may look invalid and still be needed to rebuild history.
- Weak keys and relationships. Systems without formal constraints carry orphaned and duplicate records.
- Two sources of truth. If both systems can change the same data while they coexist, conflicts end in manual corrections.
- "Close enough." Accepting a migration without checking it in financial or operational data.
How to check it went well
Reconciliation compares both sides: record counts by table and status, missing or duplicate keys, sums of amounts by period, samples of historical and recent records, relationships and attachments, and the results of critical reports. Each difference is classified as a migration error, an anomalous source record, an approved transformation or a retired rule.
ERP data migration: an example
A company replaces an old management application with a new ERP. Before migrating, it reviews which customers and items are still active and which old codes the history needs. It loads the data into a test environment, compares yearly billing totals with the old system and fixes the differences. Only then does it set the cutover date.
Data migration at DPI Systems
In Access and Visual FoxPro to .NET migration projects, DPI Systems starts with an assessment of the system, prepares the data migration to SQL Server and runs a progressive transition with testing and support.