Migration
Amazon Redshift to Snowflake migration: a practical guide
How to migrate Amazon Redshift to Snowflake: SQL and stored procedure conversion, identifier case and VARCHAR length gotchas, DISTKEY and SORTKEY, WLM to warehouses, Spectrum, loading via S3 and reconciliation.
Hemant Walchale
· 2 min read
Teams move from Amazon Redshift to Snowflake for separation of storage and compute, simpler workload isolation, less tuning and stronger data sharing. Both platforms speak similar SQL and can sit in the same AWS region, so the data move is easy. The surprises are a few semantic differences that change results.
This is the approach we recommend.
1. Inventory
List schemas, tables, views, materialized views, stored procedures, user-defined functions, scheduled queries and external (Spectrum) tables, plus the jobs that load them and the BI tools that read them. Redshift’s system tables (STL_QUERY, SVL_QUERY_SUMMARY and similar) show what is queried. Archive what isn’t.
2. Know the differences
| Redshift | Snowflake | What to watch |
|---|---|---|
| Unquoted identifiers fold to lowercase | Unquoted identifiers fold to uppercase | Quoted lowercase names ("customer_id") in tools and code break; avoid quoting or normalize names. |
VARCHAR(n) length in bytes |
VARCHAR(n) length in characters |
Multi-byte data may fit differently; review long text columns. |
DISTKEY, SORTKEY, DISTSTYLE |
Micro-partitions, optional clustering keys | Drop physical design; cluster only where measured. |
VACUUM, ANALYZE |
Not needed | Remove from maintenance jobs. |
SUPER type and PartiQL |
VARIANT with : path notation and FLATTEN |
Rewrite semi-structured queries. |
| PL/pgSQL stored procedures | Snowflake Scripting or JavaScript/Python procedures | Rewrite and test. |
| WLM queues and concurrency scaling | Separate warehouses, multi-cluster warehouses | Design per workload. |
| Spectrum external tables | External tables or Iceberg tables on S3 | Re-create definitions. |
UNLOAD, COPY |
COPY INTO (both directions) |
Similar concepts. |
Conversion tooling, including SnowConvert where it supports your source, handles much of the SQL.
3. Move data through S3
UNLOAD each table to S3 as Parquet, create an external stage in Snowflake on that bucket (same region avoids transfer costs), and COPY INTO the target tables. Then keep the two in sync for the parallel run.
4. Reconcile and cut over
Compare every table by domain: row counts, totals and row-level differences. Most mismatches trace back to case, VARCHAR length and date function differences. Repoint BI tools domain by domain once owners sign off.
5. Shut down clusters
Pause, then delete Redshift clusters as domains move, and cancel reserved instances at their end dates.
The short version
Inventory from system tables, move data through S3, handle identifier case and VARCHAR semantics deliberately, drop distribution and sort keys, replace WLM with separate warehouses, rewrite procedures, reconcile and retire clusters by domain.
Browse all migration guides, compare platforms with the platform chooser, or estimate Snowflake costs with the cost calculator.
Not sure where your own platform stands? Take the free 3-minute data platform scorecard, or see how we work on Snowflake. Unfamiliar terms are explained in the data engineering glossary.