Migrations/SQL Server → Snowflake
SQL Server to Snowflake Migration
Moving a SQL Server data warehouse to Snowflake is the migration we've run most. Our founders led exactly this at Vivint Smart Home — a full SQL Server → Snowflake modernization serving 200+ internal data consumers — and it's the template for how we de-risk every warehouse move: parallel runs, automated reconciliation, and staged cutover.
Why teams migrate
The triggers we hear most
- 01SQL Server licensing and hardware costs are scaling faster than the value the platform returns
- 02Concurrent analytical workloads are hitting performance ceilings the box can't grow past
- 03Every new data request has quietly become a multi-week engineering project
- 04You want elastic compute and separation of storage and compute, not a fixed server
- 05The real ETL logic lives in stored procedures and SSIS packages nobody fully understands anymore
What makes it tricky
Where SQL Server-to-Snowflake migrations go wrong.
T-SQL is not Snowflake SQL
Stored procedures, T-SQL-only functions, MERGE semantics, and temp-table patterns don't port one-to-one. We translate the business logic, not the syntax — into version-controlled dbt/SQL — and validate every output against the source.
The orchestration is the iceberg
The warehouse's real logic usually lives in SSIS packages and SQL Agent jobs, not the schema. Cataloging and re-homing that orchestration to Airflow/dbt is the bulk of the work, and the part most plans underestimate.
Types and collations bite silently
IDENTITY columns, DATETIME precision, and SQL Server collations have Snowflake equivalents with subtle differences that corrupt joins and aggregates without throwing an error. Row counts won't catch it — distribution checks will.
How we run it
Parallel-run, reconciliation-gated, reversible.
The same migration discipline our founders ran inside enterprise data teams — the evidence decides each cutover, not the calendar.
- 1
Catalog the SQL Server estate — schemas, stored procs, SSIS packages, Agent jobs, and every downstream consumer — into a verified dependency map.
- 2
Stand up Snowflake with the target model, translating T-SQL logic into dbt/SQL with clustering and cost controls designed in from day one.
- 3
Dual-load: pipe source data into both systems and run automated reconciliation on aggregates and distributions, not just row counts.
- 4
Migrate downstream reports and BI connections subject-area by subject-area, highest-pain first — each slice independently valuable.
- 5
Cut over each slice only after reconciliation holds clean for a full business cycle, with a scripted, rehearsed rollback ready.
A Snowflake platform with elastic compute and governance, and the SQL Server estate decommissioned — not running in parallel forever. At Vivint, the modernized platform expanded reliable data access to more than 200 internal consumers.
FAQ
Common questions
- How long does a SQL Server to Snowflake migration take?
- It depends on the estate, but it starts with a 2–3 week fixed-fee diagnostic that produces the dependency map and a costed, phased plan. Delivery then runs subject-area by subject-area, each independently valuable — you're never waiting on a single big-bang cutover.
- Will the migration cause downtime?
- No. We dual-load and run SQL Server and Snowflake in parallel with automated reconciliation, then cut over each subject area only when the numbers match to the penny — with a scripted rollback at every step.
- What happens to our SSIS packages and stored procedures?
- We catalog them, translate the business logic (not the raw syntax) into version-controlled dbt/SQL and Airflow orchestration, and validate every output against the SQL Server source before cutover.
→ Start a project
Planning a SQL Server to Snowflake migration?
Describe your current estate in three sentences. We'll come back with how we'd phase it, what it likely costs, and whether we're the right team — usually within two business days.