PlaybookEnterprise Data Warehouse Cloud Migration

Migrating an enterprise warehouse from SQL Server to Snowflake — end to end.

A Tech PM's walkthrough of how a cloud data-warehouse migration is actually run.

Case Study Snapshotproblem → solution · at a glance
The problem

Legacy SQL Server EDW at end-of-life — capacity-bound at peak, expensive to keep licensed, and nightly batch runs eating into business hours.

How I run it

A wave-based hybrid Waterfall/Agile migration to Snowflake — rationalized scope, zero-tolerance reconciliation, and change management from day one.

Program scope & impact

Objective — modernize the enterprise data platform without breaking trust in a single reported number.

Zero Variance
Financial Metric Accuracy
Enforced zero-tolerance reconciliation rules on all financial reports at go-live.
400 → 250
Reports Rationalized
Eliminated 37% of redundant legacy dashboards during the migration audit.
4 wks
Active End Users
Seamless platform adoption across cross-functional business teams.
~9 Months
Concept to Decommission
Full-lifecycle delivery from initial program charter to legacy cutover.
Program scope8 Business Functions · ~1,200 Schema Objects & Dependencies Scoped · 5 Delivery Waves · SQL Server → Snowflake

Conflict resolution & governance

Two conflicts this playbook is built to handle

Every program has moments where competing priorities collide. Here are two illustrative scenarios — one with peers, one with executives — the governance tool I reach for, and what it protects.

Friction · Peer conflict

Sales & Marketing domain leads demanded immediate Wave 1 prioritization for their functions.

Decision

Enforced dependency-first sequencing — shared dimensions before the facts that depend on them.

Governance tool

Dependency Matrix & RACI.

Outcome

Zero upstream rework; a foundational, stable Wave 1 the rest of the program built on.

Friction · Reconciliation break

Week 2 of the dual-run surfaced a trailing-12-month renewal discrepancy — a UTC/timezone offset between on-prem SQL Server and the cloud ingestion layer — on the critical path to a cutover set before quarter close.

Decision

Held the Go/No-Go gate, root-caused it in the transformation layer, patched the timezone handling, and re-ran the dual-run to exact parity before greenlight.

Governance tool

4-week dual-run reconciliation · ARR & renewal parity sign-off.

Outcome

Financial parity on ARR and renewals restored — and the planned cutover date held.

Master program decision log

Every ambiguous call gets logged once — context, stakeholders, who's accountable, the governing artifact, and the resolution — so nothing gets re-litigated when timelines tighten.

Artifact · Decision loglive · program governance
IDContextStakeholdersRACIGovernance artifactFinal resolution & impact
DEC-014Wave sequencingSales / Marketing leadsA: Program Lead · C: LeadsDependency MatrixSequencing logic enforced; prevented rework.
DEC-022Go/No-Go quality gateExecutive CommitteeA: Program Lead · I: ExecsZero-Tolerance StandardPatch deployed; audit integrity secured.

The frameworks I reach for

Beyond these two, conflict on a program this size is a signal of unaligned risk, ambiguous ownership, or resource contention. These are the plays I run, matched to the kind of conflict.

Framework · Conflict resolutionscenario → play
When the conflict is…The framework I useHow it plays out
Ambiguous authority or governanceRACI + Decision LogRoles fixed in the charter; every ambiguous call logged with context, options, and the signing exec — so nothing gets re-litigated when timelines tighten.
Data vs. opinion on scope or designObjective trade-off analysisI reframe from preference to cost, risk, and schedule — full scope with a slip vs. a phased MVP on time — and let business priorities pick.
Cross-team dependency or resource contentionRAID escalationLog the dependency and its impact, then escalate on metrics — "Team X's delay pushes Phase 2 by three weeks" — not on personal friction.
Competing executive agendas20-minute pre-conferencesAlign Legal, Finance, and Engineering one-on-one before the steering meeting, so the group sign-off is a formality, not a debate.

Go deeper on how I managed stakeholders, scored risk, and what I'd do differently — Stakeholder, Risk & Lessons Learned →

The mental model

A migration is three programs running at once

Strip away the tooling and every EDW cloud migration is three tracks running in parallel — data, reporting, and people. Here's each one, source to target.

01
Data EngineSQL Server → Snowflake · ~1,200 objects inventoried & mapped
1K+Objects scoped
SQL ServerTransform + ReconcileSnowflake
02
Reporting ContinuityTableau / GA4 schema patch · parity tested
250Reports
Legacy DashboardsRe-point + Parity TestTableau / GA4
03
People & Adoptioncompany-wide BI consumers · continuous enablement
4K+Users
AwarenessChampions + TrainingActive Adoption

The lifecycle

Five phases, delivered in waves

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 to read this

Follow one golden thread

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.