--- title: "What Is Cloud Migration? | Dawiso" description: "Cloud migration is the process of moving data, applications, and workloads to the cloud. Learn the strategies, the phases, and why lineage de-risks it." url: "https://www.dawiso.com/glossary/cloud-migration" language: "en" --- June 10, 2026 cloud migrationdata migration6 Rs of migrationlift and shiftdata lineagecloud computing # What Is Cloud Migration? **Cloud migration** is the process of moving an organization's data, applications, and workloads from on-premises systems (or one cloud) to a [cloud computing](https://www.dawiso.com/glossary/cloud-computing) environment such as AWS, Azure, or Google Cloud. For data teams specifically, it usually means migrating from a legacy on-prem warehouse to a cloud data platform like [Snowflake](https://www.dawiso.com/glossary/snowflake), [Databricks](https://www.dawiso.com/glossary/what-is-databricks-complete-guide-for-2025), or BigQuery - and rebuilding the pipelines, reports, and models that depend on it. It matters because migration is one of the highest-stakes projects a data organization undertakes: it touches every system, every pipeline, and every report at once, and it is notoriously prone to overrunning budget and timeline. The promise - elasticity, lower operational burden, modern analytics and AI - is real, but it is realised only if the migration preserves what made the old estate trustworthy: the meaning of the data, its quality, and the dependencies between systems. Migrations that move the data but lose its context simply rebuild the old chaos in a more expensive place. TL;DR **Cloud migration** moves data, applications, and workloads to the cloud. Strategies are often framed as the **"6 Rs"** - rehost, replatform, refactor, repurchase, retire, retain - trading effort against cloud-native benefit. A data migration runs in phases: *assess* (inventory what you have and how it connects), *plan*, *migrate*, and *validate*. Most failures trace to a single root cause: not knowing the dependencies before you move, so something downstream breaks silently. [Data lineage](https://www.dawiso.com/glossary/data-lineage) is the single most valuable asset in a migration - it shows what feeds what, so you can sequence the move and prove nothing was lost. A [catalog](https://www.dawiso.com/glossary/data-catalog) turns a risky big-bang into a mapped, staged project. ## Cloud Migration Defined Migration is not a single act but a transformation program. At minimum it moves data and compute to a new platform; at most it re-architects how the organization works with data entirely - adopting a [lakehouse](https://www.dawiso.com/glossary/data-lakehouse), a [data mesh](https://www.dawiso.com/glossary/data-mesh), or a modern ELT stack. The scope chosen determines both the value captured and the risk taken on. The reason migrations are hard is rarely the data movement itself - copying bytes is a solved problem. The difficulty is everything attached to the data: the hundreds of pipelines that transform it, the reports and models that consume it, the business logic encoded in legacy SQL, and the institutional knowledge of what each table actually means. A migration succeeds or fails on how well that web of dependencies is understood *before* the move. ## The Six Rs of Migration A widely used framework (originating with Gartner and popularised by AWS) classifies migration strategies by how much you change as you move. Each trades effort for cloud-native benefit: - **Rehost ("lift and shift").** Move as-is to cloud infrastructure. Fastest and lowest-risk, but captures little cloud-native value. - **Replatform ("lift and reshape").** Move with minor optimizations - e.g. swapping a self-managed database for a managed one. - **Refactor / re-architect.** Redesign for the cloud - adopting a lakehouse, ELT, serverless. Highest effort, highest reward. - **Repurchase.** Replace a system with a SaaS equivalent. - **Retire.** Decommission what is no longer needed - and a migration is the ideal moment to find it. - **Retain.** Deliberately keep some systems where they are (often for [sovereignty](https://www.dawiso.com/glossary/data-sovereignty) or cost reasons), producing a hybrid estate. Most real migrations apply several Rs across different systems. Choosing well requires knowing which systems matter and what depends on them. ## Data Migration Phases A disciplined data migration runs in four phases. The first is the one teams are tempted to rush - and the one that determines success: 1. **Assess.** Build a complete inventory of what you have, what it means, and - critically - how everything connects. This is where [lineage](https://www.dawiso.com/glossary/data-lineage) earns its keep: you cannot safely move a table without knowing which pipelines and reports depend on it. Assessment is also when you find the dead datasets to *retire* rather than pay to migrate. 2. **Plan.** Choose a strategy (the 6 Rs) per system and sequence the move into waves, ordered by dependency so nothing is migrated before what it relies on. 3. **Migrate.** Move the data and rebuild the pipelines, transformations, and reports on the new platform - ideally in waves, not a single big bang. 4. **Validate.** Reconcile the new estate against the old: do the numbers match, are the reports identical, did anything quietly break? Parity must be proven, not assumed. ## Where Migrations Fail Almost every painful migration shares the same root cause: **moving data without knowing what depends on it.** The symptoms are familiar - a dashboard that goes blank because a source table was migrated late, a downstream model trained on a column that was renamed in transit, a report that "still works" but is now subtly wrong because a transformation was rebuilt incorrectly. These are [schema-drift](https://www.dawiso.com/glossary/schema-drift) and dependency failures, and they are invisible until someone notices the numbers are off - usually after go-live. The second great failure is migrating the mess: lifting and shifting thousands of undocumented, low-quality, duplicated datasets into the cloud, where they cost more to store and remain just as untrustworthy. A migration is the rare opportunity to *not* bring the chaos along - but only if you can see what is worth keeping. ## How Dawiso De-Risks It Both failure modes are visibility problems, which is exactly what a governed [catalog](https://www.dawiso.com/glossary/data-catalog) solves. Dawiso gives a migration the two things it most needs. First, a complete, automatically discovered inventory of the source estate - so the *assess* phase produces a real map instead of a hopeful guess, and dead data can be retired rather than migrated. Second, interactive [data lineage](https://www.dawiso.com/product/interactive-data-lineage) that shows every dependency across systems - so you can sequence the migration by what feeds what, predict the blast radius of moving any asset, and at the end *prove* parity by comparing source and target lineage. The catalog and its business context also carry forward the meaning of the data, so the new platform inherits a documented, governed estate rather than a pile of unlabeled tables. Migration stops being a leap of faith and becomes a mapped, staged, verifiable project. ## Conclusion Cloud migration promises elasticity, lower operational burden, and modern analytics - but it delivers them only to teams that move deliberately. The strategy framework (the 6 Rs) and the phased approach (assess, plan, migrate, validate) matter, but the decisive factor is visibility: knowing what you have and what depends on it before you touch anything. Migrations fail in the dark and succeed in the light. Map the estate, trace the lineage, retire the dead weight, and validate against the source - and the move to the cloud becomes an upgrade rather than a gamble. [See it in action](https://www.dawiso.com/product/interactive-data-lineage) Interactive Data Lineage Visualizing how data moves, transforms, and connects across systems, applications, and reports. ### Table of contents Cloud Migration DefinedThe Six Rs of MigrationData Migration PhasesWhere Migrations FailHow Dawiso De-Risks It ## Related Terms ### [What Is Cloud Computing?](https://www.dawiso.com/glossary/cloud-computing) Cloud computing delivers computing resources - servers, storage, databases, analytics - on demand over the internet. Learn the service and deployment models. Read more → ### [What Is Data Lineage?](https://www.dawiso.com/glossary/data-lineage) Learn what data lineage is, why it matters for data governance and compliance, and how to implement it. Read more → ### [Unity Catalog vs Microsoft Purview](https://www.dawiso.com/glossary/unity-catalog-vs-microsoft-purview) Unity Catalog vs Microsoft Purview compared: scope, access control, lineage, and pricing, plus how Purview scans Unity Catalog when you run both. Read more → ### [What Is OpenMetadata? Open-Source Data Catalog Explained](https://www.dawiso.com/glossary/what-is-openmetadata) OpenMetadata is an open-source metadata platform for data cataloging, lineage, and governance. Learn how it works, its architecture, and where it fits. Read more → ### [What Is Data Provenance?](https://www.dawiso.com/glossary/provenance) Data provenance is the documented origin and history of data - where it came from, how it changed, and who did it. Learn how it differs from lineage and why it matters. Read more → ### [What Is a Data Pipeline?](https://www.dawiso.com/glossary/data-pipeline) A data pipeline is an automated sequence of processes that moves, transforms, and delivers data from source systems to consumers. Learn about pipeline architecture, types, governance, and observability. Read more →