Data Migration is the controlled movement of data from one storage system, application, platform, schema or computing environment to another. It commonly occurs during application replacement, database modernisation, cloud adoption, organisational restructuring, platform consolidation, mergers, infrastructure changes or retirement of legacy systems. Migration differs from ordinary data copying because the destination frequently has different structural, technical or semantic requirements.
Records may need to be converted, cleaned, reconciled, deduplicated, mapped to new identifiers or reorganised before they can be accepted by the target system. A migration is normally associated with a defined transition from an existing state to a target state, although some programmes maintain synchronisation between old and new environments temporarily during the transition.
Migration projects can involve several distinct types of movement, including database-to-database migration, application migration, storage migration, cloud migration and platform migration. A database migration might move tables from one database management system to another, while an application migration can require data to be reshaped to fit a completely different application model. Cloud migration may involve moving large datasets from on-premises infrastructure into cloud storage or managed databases. Migrations can also be classified by how the transition is executed. A big-bang migration moves the relevant population during a concentrated cutover, whereas phased migration moves groups, domains or workloads incrementally. Parallel operation can allow old and new systems to coexist temporarily, reducing some transition risks but increasing operational complexity.
A typical Data Migration lifecycle includes discovery, profiling, mapping, extraction, transformation, loading, validation, reconciliation, testing, cutover and post-migration verification. Source profiling establishes what data actually exists rather than relying exclusively on documentation. Mapping defines how source fields and records correspond to destination structures. Transformation converts values into required formats and semantics, while loading inserts or otherwise establishes the data in the target. Validation tests technical and business correctness, and reconciliation compares source and target populations, totals or other control measures. Cutover is the point at which operational use transitions to the destination system, and post-migration monitoring confirms that applications and users can operate correctly against the migrated information.
Data mapping is one of the most consequential activities in Data Migration. A source database may contain fields that have no direct destination equivalent, while a destination may require information that did not exist explicitly in the source. One source field can sometimes need to be split into several destination fields, and several source fields may need to be combined into one destination value.
Enumerated values can also change, such as a legacy status represented by numeric codes being replaced by descriptive destination values. Identifier changes are particularly important because relationships between records must survive the migration. Referential integrity can be damaged if parent and child records are transformed independently without preserving their relationships. Detailed mapping specifications and deterministic transformation rules therefore provide an essential basis for repeatable migration execution.
Data quality problems become particularly visible during Data Migration because the project forces legacy information to meet destination requirements. Typical issues include duplicates, orphaned records, invalid dates, obsolete classifications, missing mandatory fields and inconsistent representations. Migration teams must decide whether such records should be corrected, transformed, excluded, archived or explicitly flagged. These decisions should be based on documented business rules rather than arbitrary deletion. Data cleansing can improve the destination dataset but can also introduce risk if legitimate historical differences are mistaken for errors. Maintaining migration logs, exception reports and provenance information allows questionable records to be reviewed and provides evidence of what happened during processing.
Testing is critical because a migration can appear technically successful while still producing operationally incorrect information. Structural testing verifies that destination tables, fields and constraints behave correctly; reconciliation checks whether expected records and values arrived; application testing determines whether business workflows operate correctly; and performance testing examines whether the destination can handle realistic workloads. User acceptance testing can identify semantic problems that automated validation does not detect. Multiple rehearsal migrations are often valuable because they expose transformation errors and provide measurements for extraction, processing and loading durations. A final cutover may require a freeze period or controlled synchronisation so that changes made after the last rehearsal are not lost.
Data Migration has a different risk profile from ongoing Data Integration because errors may permanently affect a new system while the source environment is being retired or altered. Important controls include complete backups, tested rollback procedures, migration checkpoints, reconciliation criteria, access controls, audit logging and explicit cutover decisions. Depending on the architecture, a rollback may mean returning to the source system, restoring a target snapshot or reversing an incremental change process.
Regulatory retention obligations can also complicate migration because some historical information may need to remain accessible even when the original application is decommissioned. Migration planning must therefore address not only the movement of active records but also historical data, archives, metadata, permissions and operational dependencies.
Successful Data Migration is measured by more than whether a destination database contains approximately the expected number of records. The migrated information must retain its intended meaning, relationships, history and usability, while the destination system must support the required operational and analytical processes. Common causes of failure include inadequate source discovery, undocumented transformations, insufficient testing, unrealistic cutover windows, poor stakeholder ownership and treating data cleansing as an exclusively technical task.
A disciplined migration treats data as an asset requiring explicit ownership and acceptance criteria. When properly planned, migration enables modernisation and consolidation without unnecessarily sacrificing historical information; when poorly controlled, it can create silent data corruption that may remain undetected long after the original system has been retired.
