Not all data migrations are the same problem. The term gets used to describe everything from moving a single SQL Server database to a new host to consolidating CRM, ERP, and operational data from a dozen systems into a unified data lake on AWS, often with a full redesign of how the business accesses and governs that data. Treating these as the same kind of project leads to the wrong approach, the wrong tooling, and timelines that blow past their original estimates.
Understanding the types of data migration, what each one involves, when it applies, and what risks are specific to it, is the foundation of a realistic migration plan. As we covered in our guide to matching tools to projects, the right choices at each stage of a migration depend entirely on what type of migration you are running. This guide covers the main categories, by what moves, and by how it moves.
Table of Contents
Part 1: Types of Data Migration by What Moves
The first dimension of any migration is the subject: what category of data or system is being relocated? Each carries its own technical complexity, business risk, and validation requirements.
Storage Migration
Storage migration moves data between physical or virtual storage systems from on-premises NAS or SAN environments to cloud object storage (AWS S3, Azure Blob, GCP Cloud Storage), or between storage tiers within a cloud environment. It’s often the first step in a broader infrastructure modernization effort and the type most likely to be underestimated.
The common assumption is that storage migration is a simple bulk transfer. In practice, data integrity verification at scale requires robust checksums and reconciliation to confirm that what arrived matches what left, particularly when files span petabytes and include both structured data and unstructured content like images, documents, and multimedia. Retention policy and legal hold configurations must also carry forward correctly; storage migration that doesn’t account for these creates compliance gaps that only surface during an audit.
Database Migration
Database migration — moving structured data between database platforms — is the most technically demanding type of migration and the one most likely to surface complexity that wasn’t visible until the work began. Moves such as SQL Server to PostgreSQL or on‑premises Oracle to AWS RDS all involve schema mapping, source-to-target mapping for every table and column, and often significant SQL dialect conversion work that must be understood before a migration plan can be realistic.
At dbSeer, our approach to database migration follows the same four-phase methodology we’ve applied to PostgreSQL upgrades in AWS environments: Discovery and Assessment first, then a parallel environment for validation, then production cutover only after we’ve confirmed everything works; followed by hypercare to catch what production load always reveals that testing doesn’t. The order matters. By the time we execute a cutover, we’ve already seen the migration work in a parallel environment and resolved what needed resolving. That’s what makes the cutover predictable rather than a gamble.
Application Migration
Application migration moves a software system, and the data it manages, from one environment to another. This might mean migrating a legacy on-premises application to a cloud-hosted equivalent, switching from one SaaS vendor to another, or consolidating multiple applications post-merger. It’s broader than database migration because the application’s business logic, integrations, and API dependencies must all migrate alongside the data itself.
The distinction between application migration and data integration is worth flagging here: migration is a one-time move with a defined end state; integration is ongoing connectivity between systems. Many organizations conflate the two and design migration projects that should have been integration projects, or vice versa. Getting this distinction right early is one of the core questions in a foundation-first assessment.
Cloud Migration
Cloud migration moves workloads, data, or entire systems from on-premises infrastructure to a cloud provider or between cloud providers in a cloud‑to‑cloud migration. It’s currently the most common migration trigger organizations face, and the category with the widest range of complexity.
Cloud migration doesn’t describe a single approach, it’s a category that encompasses all the migration strategies covered below. What makes cloud migration distinctive is the set of concerns that apply regardless of strategy: IAM configuration and least privilege access controls, encryption in transit and at rest, data governance and data lineage continuity, compliance with GDPR, HIPAA, or SOX depending on the industry, and cost management (for a detailed breakdown of what cloud migration actually costs, see our guide to data migration costs).
Platform and ERP/CRM Migration
Platform migration (which includes ERP migrations, CRM migrations and BI platform consolidations) represents some of the highest-stakes migration work organizations undertake. These systems are deeply embedded in business operations, and their data carries decades of accumulated business logic that isn’t always documented.
The validation challenge here is KPI parity: ensuring that the reports and dashboards leadership uses to run the organization produce identical results against migrated data. A field that migrates structurally intact can still carry the wrong business meaning if the semantic layer defining how it’s calculated isn’t rebuilt correctly in the target platform. BI regression testing against a known-good baseline is not optional for these migrations — it’s how you prove the migration is complete.
Part 2: Types of Data Migration by How It Moves
The second dimension is strategy: once you know what’s moving, how does it move? These aren’t mutually exclusive, many migrations combine approaches across different workstreams, but each carries a distinct risk profile and set of operational requirements.
Big-Bang Migration
A big-bang migration moves everything in a single cutover event. The source system goes offline, data transfers, and the target system goes live. It’s the fastest approach in calendar time and the highest-risk one in operational terms.
Big-bang works when the migration scope is bounded and the organization can tolerate a planned downtime window. It breaks down when data volumes are large, when the source system supports live business operations that can’t pause, or when the team hasn’t built and tested a credible rollback plan. Recovery Point Objective (RPO) and Recovery Time Objective (RTO) targets should be defined and tested before a single production record moves.
For a structured view of the risks specific to this approach, our data migration risks and mitigation guide covers failure modes in detail.
Lift-and-Shift Migration
Lift-and-shift — also called rehosting — moves a system from one environment to another without redesigning it. The architecture, schema, and data model come along unchanged. It’s the fastest path to a new environment and the approach that leaves the most value on the table.
Lift-and-shift is genuinely the right choice when speed matters more than optimization, when the source architecture is sound and the target environment is compatible, or when the migration is a first step toward eventual modernization rather than the end state. What it isn’t is a shortcut: the data integration and data validation work is the same regardless of whether the schema changes. Skipping data profiling because you’re not transforming anything is how lift-and-shift migrations produce environments that are structurally identical to the source but carry all its data quality problems into the new platform.
Phased Migration
A phased migration breaks the work into discrete stages with validation and stabilization between each phase before the next begins. It’s the most common approach for large, complex migrations precisely because it distributes risk: if something goes wrong in phase two, phases three through six aren’t already in flight.
The trade-off is coordination overhead. Each phase requires its own cutover planning, its own rollback plan, and its own validation pass. Data replication or CDC (Change Data Capture) is often needed to keep earlier-phase data in sync while later phases complete. The observability and data lineage infrastructure to track what’s live where becomes more important as phases accumulate. Done well, phased migration is the approach with the best risk-adjusted outcome for enterprise-scale work.
Trickle Migration (CDC-Based)
Trickle migration — sometimes called live migration or parallel migration — uses change data capture to continuously replicate changes from the source system to the target while both environments operate simultaneously. When the target has caught up to the source and validation confirms parity, the cutover happens with minimal or zero downtime.
CDC‑based approaches are often the right choice when the source system cannot tolerate downtime. For example, high‑availability transactional databases, customer‑facing applications, or real‑time data pipelines. They require more architectural work upfront: CDC infrastructure must be built and tested, idempotency in the replication pipeline must be verified (so replaying events doesn’t produce duplicate records), and the parallel run period has to be long enough to validate that the target is accumulating changes correctly. The complexity is real, but so is the outcome: a production cutover that business users don’t notice.
Hybrid Migration
Most enterprise migrations aren’t cleanly one type. A hybrid migration combines approaches: a big-bang cutover for one system, phased migration for another, CDC replication for the components that can’t tolerate downtime. The right combination depends on what each workload requires not a single methodology applied uniformly because it’s simpler to explain.
This is where the foundation-first assessment pays its clearest dividend. Understanding which systems require zero downtime, which can accept a planned window, which have the data quality to move cleanly, and which need remediation first: that analysis is what produces a migration strategy that fits the actual situation rather than the average situation.
How dbSeer Approaches Migration Type Selection
The most common mistake we see in migration projects is the approach being decided before the situation is understood. Teams default to lift-and-shift because it’s fast, or to big-bang because it’s simple to explain, without asking whether either choice actually fits the workload, the risk tolerance, and the data quality reality they’re starting from.
dbSeer’s foundation-first methodology begins with the assessment work that makes those decisions explicit. Our data assessment process maps source systems, profiles data quality, identifies governance and compliance requirements, and evaluates the target architecture options — before any migration strategy is committed to. That work is what allows us to recommend a phased approach for one client and a CDC-based trickle migration for another and explain why the difference matters in terms of ROI and operational risk.
If you’re trying to understand which migration type fits your situation or why a project you’re inheriting is harder than it should be working with an experienced data migration consultant who asks the right questions before recommending an approach is the place to start. Get in touch and we’ll tell you what we see.
