Cloud DW migrations succeed or fail in the discovery and decisions phases by the time execution starts, the project shape is already decided. A working migration runs seven phases discovery, key decisions, plan, execute, validate, cutover, decommission with disciplined parallel-run and refactor choices. This page is the checklist and the decision framework.
The Seven Phases
|
Phase |
Outcome |
|
Discovery |
Full inventory of workloads, dependencies, data |
|
Key decisions |
Target platform, refactor depth, parallel-run scope |
|
Migration plan |
Sequenced waves with owners and dates |
|
Execute |
Schemas, pipelines, transformations migrated |
|
Validate |
Output parity vs source-of-truth |
|
Cutover |
Move consumers to new platform |
|
Decommission |
Retire legacy environment safely |
Create a Scalable Data Warehouse
Phase 1 Discovery
Inventory: tables, ETL jobs, BI reports, consumers, downstream applications, lineage. Tag by business criticality. Discovery often finds 30%+ of legacy workloads aren’t used those can be archived, not migrated.
Phase 2 Key Decisions
Target platform (see Snowflake vs Databricks vs BigQuery, which is right for you). Refactor depth: lift-and-shift, lift-and-improve, or rebuild. Parallel-run scope: how much overlap, for how long. These decisions shape budget, timeline, and outcome more than execution does.
Phase 3 Migration Plan
Sequence into waves usually starting with low-risk, low-dependency workloads and ending with high-criticality, high-dependency ones. Each wave has scope, owners, parallel-run plan, validation criteria, and rollback. Plan in waves, not big-bang.
Phase 4 Execute
Migrate schemas; rewrite pipelines (or migrate as-is); rewrite transformations (often into dbt); migrate BI reports; integrate observability. (See dbt implementation guide transforming data engineering workflows.)
Phase 5 Validate
Compare new-platform outputs against legacy-platform outputs row-by-row, metric-by-metric, for the parallel-run period. Reconcile differences honestly; some will be legacy bugs you’re fixing on the way through.
Phase 6 Cutover
Move consumers to the new platform in the same wave sequence. Communicate aggressively; maintain rollback discipline. Cutover is when the parallel-run investment pays back.
Phase 7 Decommission
Archive legacy data per retention policy; turn off legacy systems; reclaim licenses. Often forgotten and legacy systems can sit running for years after cutover if discipline lapses.
Best Practices and Common Pitfalls
Best practices: invest in discovery (find what to NOT migrate); plan refactor into the budget (lift-and-shift produces poor cloud economics); parallel-run for long enough to validate; use dbt for transformation rewrites; treat observability as foundational. Pitfalls: underestimating effort, BI rework, and security / access-control reimplementation; rushing cutover; skipping decommission. A data governance framework is what prevents access-control and quality issues from slipping through during cutover. Centric runs cloud DW migrations through its data engineering and warehousing service.
Frequently Asked Questions
How long does a cloud DW migration take?
Typically a year or more for enterprise scale, depending on workload count, refactor depth, parallel-run length, and dependencies. Smaller programs can migrate in quarters.
Should we lift-and-shift?
Rarely the right answer. Lift-and-shift typically produces worse cloud economics than legacy. Plan to refactor into cloud-native patterns.
How long should we parallel-run?
Long enough to validate output parity through a full business cycle (often a month or a quarter, longer for finance close cycles). Don’t cut over without validation.
Where do migrations fail?
In discovery (didn't find what to leave behind), in decisions (chose lift-and-shift), or in cutover discipline. The Azure migration and modernization playbook breaks down how to avoid all three in a structured wave approach. Execution failures are usually downstream of those.
Conclusion
A working cloud DW migration is mostly decided before execution starts. Invest disproportionately in discovery and decisions; plan in waves; parallel-run with discipline; decommission with intent. The migration that pays back is the deliberate one done by a team that has done it before. At Centric, cloud DW migrations are a core delivery discovery-first, refactor-planned, decommission-included.
