A Technical Program Manager's walkthrough of how a cloud data-warehouse migration is actually run: eight business functions, thousands of users, one legacy platform retired — planned, governed, cut over, and adopted without breaking trust in the numbers.
Legacy SQL Server EDW at end-of-life — capacity-bound at peak, expensive to keep licensed, and nightly batch runs eating into business hours.
A wave-based hybrid Waterfall/Agile migration to Snowflake — rationalized scope, zero-tolerance reconciliation, and change management from day one.
Strategic context
Objective — modernize the enterprise data platform without breaking trust in a single reported number.
Stakeholder alignment
Every program has moments where competing priorities collide. These are two real ones from this migration — one with peers, one with executives above me.
Domain leads in Sales and Marketing wanted their functions prioritized immediately in the wave sequence — nobody wants to hear "you're Wave 3" when they think their number matters most.
I held the line on a strict dependency-first wave strategy, sequencing shared dimensions before the facts that depend on them, and pointed to the dependency matrix instead of arguing seniority.
Prevented upstream pipeline rework we'd have paid for twice, and gave Wave 1 a foundation the rest of the program could actually build on.
Executive sponsors wanted to waive a 0.003% rounding discrepancy in the historical variance reports to protect a quarter-end milestone.
I refused to pass the go/no-go gate until the transformation logic was patched, holding the zero-tolerance reconciliation standard I'd set at the start of the program.
Preserved absolute financial audit credibility — and the fix landed in 48 hours anyway, so the deadline was never really at risk.
The mental model
Strip away the tooling and every EDW cloud migration is these three jobs happening in parallel. Everything in the plan serves one of them — and the third is the one most teams underbuild.
01 · Move the data
Migrate ~1,200 objects from SQL Server to Snowflake so the numbers are provably identical — code converted, history loaded, integrity preserved where the target won't enforce it.
02 · Preserve the reports
Every dashboard and extract that the business relies on keeps working after cutover — re-pointed or rebuilt, and parity-tested old-vs-new before anyone switches.
03 · Drive adoption
~4,500 people trust and use the new platform. Change management runs the whole length of the program, not a training week bolted on at the end.
The lifecycle
The program moves through Waterfall phase gates — you can't cut over before you've built and reconciled — while build and test happen in Agile sprints inside each wave. Click into any phase.
How I mapped 1,200 objects, established governance, and built the wave migration strategy.
Translating legacy SQL to Snowflake and designing robust automated verification systems.
Managing 18 engineers across 5 migration waves while keeping legacy operations running.
Running zero-tolerance financial checks and managing executive sign-offs.
Transitioning 4,500 users, turning off legacy infrastructure, and controlling cloud cost creep.
The artifact library and the reusable principles behind running any migration.
How to read this
Rather than a tour of every object, this case study follows a single field — the Sales/Revenue close amount — through all five phases: how it's discovered, mapped, built, reconciled, cut over, and adopted. One thread makes an abstract lifecycle concrete.
The thread
dbo.FactOpportunity.CloseAmt → SALES.FACT_OPPORTUNITY.CLOSE_AMOUNT_USD
MONEY → NUMBER(19,4), normalized to USD. Owned by a Sales Finance SME. Watch for it in the green callouts on each phase page.