What Is Data Migration? A Practitioner's Definition
A data migration is the planned movement of data from one environment to another with the goal of making that data fully usable in the new environment. The phrase “fully usable” is doing the work. Most migration failures are not about moving bytes; they are about the assumptions, validations, and downstream changes that should have happened alongside the move. This page explains what data migration actually involves.
Snowflake, Databricks, Azure, AWS fluent
HQ Atlanta, serving US, Canada, Europe
- Data migration is the planned transfer of data from a source environment to a target environment, including the validation, transformation, and reconciliation work required to make the data usable in the target.
- Types include storage, database, application, cloud, and business process migration.
- Timelines vary widely based on data volume, complexity, downtime tolerance, and source system documentation.
What is data migration?
Data migration is the planned movement of data from a source system or environment to a target system, including the work required to make that data usable, accurate, and trusted in the new environment. The technical transfer is the smallest part. Mapping, transformation, validation, reconciliation, cutover orchestration, and decommissioning of the source are where most of the effort goes.
Migrations happen because the business has decided the target is better suited to its needs than the source: lower cost, better performance, modern capabilities, regulatory fit, or because the source is being retired by the vendor. The driver shapes the migration. A cost-driven migration tolerates a longer timeline; a vendor-end-of-life migration does not.
A migration is not the same as a transformation. A migration moves what exists. A transformation reshapes what exists. Many engagements blend both, but the distinction matters for planning and budgeting.
- Migration moves data from source to target with full validation, not just transfer.
- Major types: storage, database, application, cloud, and business process migrations.
- Drivers: cost, performance, modernization, regulatory fit, vendor end-of-life.
- Timelines vary by volume, complexity, downtime tolerance, and source documentation.
- Validation and reconciliation typically consume more time than the move itself.
- Decommissioning the source is part of the migration, not an afterthought.
What are the main types of data migration?
Storage migration.
Moving data from one storage medium or system to another (on-premises array to cloud object storage, for example). The structure and schema do not change. The most common driver is cost or capacity.
Database migration.
Moving data between database platforms (Oracle to PostgreSQL, on-premises SQL Server to Azure SQL, legacy data warehouse to Snowflake or Databricks). Schema, performance characteristics, and tooling change. Application compatibility becomes a consideration.
Application migration.
Moving the data behind an application from one system to another, often as part of an application replacement (ERP, CRM, EHR, financial systems). The most complex type because business processes change alongside data.
Cloud migration.
Moving data and workloads from on-premises infrastructure to cloud (AWS, Azure, GCP), or between clouds. Frequently combined with database or storage migration. Cost models, security, and operating practices all shift.
Business process migration.
Moving the data supporting a business process when the process itself changes (an M&A integration, a regulatory restructuring). The least technical and most political.
The categories are not always staffed separately, but they are always present. Underinvesting in any one of them creates fragility in the others.
Why companies migrate data
Cost is the most cited driver and the most often misunderstood. Cloud platforms reduce certain costs (capacity headroom, hardware refresh cycles, datacenter overhead) and increase others (egress, ongoing compute, specialized skill). A migration sold on raw cost reduction without modeling the full picture often disappoints.
Modernization is the second driver. Legacy platforms cannot support the analytics, performance, or integration capabilities the business now needs. The migration unlocks capability rather than reducing cost.
Vendor end-of-life is the third. The current platform is being deprecated by its vendor; the migration is not optional, only the destination is.
Regulatory and data residency requirements drive a smaller but growing share of migrations, particularly for organizations operating across jurisdictions.
M&A is the fifth common driver. An acquisition consolidates two data environments into one. The migration is a precondition for getting value from the deal.
What actually happens during a data migration
The phases run in a recognizable sequence: assessment of the source environment, design of the target, migration execution, validation, cutover, and decommissioning. The work inside each phase is where the variability sits.
Assessment is where most migrations are under-scoped. Source systems are rarely as well-documented as everyone believes. Data quality issues that were tolerable in the source become blockers in the target. Integration touchpoints surface during assessment that nobody remembered existed.
Design is where the target environment, mapping rules, and transformation logic get specified. Decisions made here drive most of the execution cost. Skipping design to “move fast” reliably extends the overall timeline.
Execution moves the data, often in waves. Validation and reconciliation prove the data in the target matches the source according to defined criteria. This is the phase most often compressed and most often the source of post-go-live pain.
Cutover and decommissioning end the migration. The source is retired (immediately or in phases), the new environment becomes the system of record, and the operational team takes over.
How DI Squared sequences a data migration: Discover, Map, Navigate, Adjust
- Discover. Discover assesses the current pipelines, platform, models, and operating practices, plus the team’s skill and capacity.
- Map. Map documents the target state, the sequencing, and the platform decisions, ending in a plan the team and the CFO can both work from.
- Navigate. Navigate is the build. We prioritize the most valuable first wins (often a pipeline modernization or a finance data mart), deliver them, and run alongside the internal team through change management.
- Adjust. Adjust is the long horizon, where we tune the platform, retire technical debt, and adapt the architecture as the business evolves.
Data Migration Guide, answered.
Q: How long does a typical data migration take?
A: Timelines vary widely. A storage migration of a well-documented environment can run weeks. A complex database or application migration runs months to over a year. Volume, complexity, downtime tolerance, source documentation quality, and downstream integration count are the main drivers. We give honest ranges with stated assumptions rather than universal numbers.
Q: What is the difference between data migration and data integration?
A: Migration is a one-time, planned movement that ends with the source being retired or repurposed. Integration is the ongoing connection of two or more systems that continue to operate in parallel. Many migrations require temporary integration during cutover.
Q: What is ETL and how is it related to migration?
A: ETL (extract, transform, load) and its modern cousin ELT are the patterns used to move and reshape data. They are tools used inside a migration. The migration is the engagement; ETL/ELT is one technique applied during it.
Q: How do we minimize downtime during a migration?
A: Strategies include phased migration (waves), parallel running with dual writes, change data capture for ongoing sync, and tightly orchestrated cutover windows. The right approach depends on business tolerance for downtime and the technical characteristics of the source and target.
Q: What can go wrong in a migration?
A: The frequent issues: under-discovered source complexity, unaddressed data quality, integration touchpoints missed during assessment, validation criteria defined too late, rollback plan untested, and operational handoff rushed. Most failures are scoping and validation problems, not transfer problems.
Q: Should we migrate everything or only what we use?
A: Usually only what we use, plus what we are required to retain. Migrating dormant data inflates cost and risk. We help define the retain, archive, and decommission decisions during assessment.
Scoping a migration and want an honest read?
We have run migrations across utilities, healthcare, manufacturing, retail, and financial services since 2008. Tell us what you are moving and where you are stuck.