Moving a legacy data warehouse to Snowflake is rarely hard because of Snowflake. It is hard because of what you are leaving: years of stored procedures, ETL jobs and reports that nobody fully documented. This guide sets out a five-step approach that keeps the business running while you move, and shows where Snowflake's own tooling now removes much of the manual work.
Why companies are moving now
Legacy appliances carry fixed capacity, high support costs and hardware refresh cycles. Snowflake separates storage from compute, so workloads scale independently and you pay for what runs. It also brings governed data sharing and AI features to the same platform, which matters as teams start building analytics and AI on shared data.
Step 1: Assess what you really have
Inventory every object: tables, views, stored procedures, functions, ETL jobs, schedules and BI reports. Classify each as migrate, rebuild or retire. Unused reports and duplicate tables are common, and retiring them is the cheapest migration of all.
Snowflake's free SnowConvert AI helps here. It produces conversion reports with conversion rates and a catalogue of issues, so you can size the effort before committing.
Step 2: Convert the code
SnowConvert AI converts SQL and procedural code to Snowflake. According to Snowflake, supported sources include Oracle, Microsoft SQL Server, Teradata, Amazon Redshift, Google BigQuery, Greenplum, Sybase, Synapse, Netezza, PostgreSQL and Databricks SQL, covering tables and views through complex stored procedures and user-defined functions.
It can also convert source tables such as Teradata directly into Snowflake-managed Iceberg tables where you need an open table format. Expect a share of objects to need manual work; the value of the tool is that your engineers spend their time on those exceptions rather than on routine rewrites.
| Source platform | Typical hard parts |
|---|---|
| Teradata | BTEQ scripts, macros, volatile tables |
| Oracle | PL/SQL packages, cursors, sequences |
| SQL Server | T-SQL procedures, SSIS packages |
| Netezza | Distribution keys, NZPLSQL procedures |
Step 3: Move the data
Load history in bulk first, then keep it current with incremental loads until cut-over. Plan the order around dependencies: reference data, then facts, then aggregates. Encrypt data in transit, restrict access to named roles and log every transfer; migrations are exactly when data is most exposed.
Step 4: Validate before anyone switches
Validation is where migrations earn trust. Compare row counts, sums and key business metrics between source and target for every object. SnowConvert AI now supports automated two-sided verification for some sources, running a source instance alongside Snowflake to compare results, as described by Data Reply. Where it is not available, build a validation harness of your own; do not skip this step.
Step 5: Repoint, run in parallel, retire
Repoint BI tools and pipelines to Snowflake, run both platforms in parallel for at least one business cycle (a month-end close is ideal), then decommission the legacy warehouse. Decommissioning is where the savings appear, so schedule it rather than leaving the old system running "just in case".
Controlling cost after go-live
Snowflake cost follows usage. Set warehouse sizes and auto-suspend per workload, tag warehouses by team, set resource monitors with alerts, and review the most expensive queries monthly. Snowflake reports customers such as Travelpass moving 30 TB and 134 pipelines in six weeks and halving costs, but results depend on your workloads and on this discipline after go-live.
Key takeaways
- Assess and retire first; the cheapest object to migrate is the one you delete.
- Use SnowConvert AI for routine conversion and focus engineers on exceptions.
- Validate every object before users switch, and run in parallel through a business cycle.
- Decommission on schedule and govern cost from day one.