Redshift to Snowflake migration: how to move warehouse tables without a reporting freeze

How do I migrate from Redshift to Snowflake?

Migrate in five phases: convert the schema to Snowflake types, backfill each table through a cloud stage, keep syncing changed rows so both warehouses stay in step, translate and re-run your SQL models against Snowflake until results match, then repoint BI tools and scheduled jobs table by table. Cut over gradually rather than all at once.

The schema conversion is mostly subtraction. Redshift DDL carries distribution style, distribution keys, sort keys, encodings, and compression settings, none of which Snowflake needs, because Snowflake manages micro-partitions itself. Strip them and you are left with column names, types, and constraints. Note that neither warehouse enforces primary keys, but Snowflake uses them as optimizer metadata, so declare them anyway and let your loads uphold uniqueness.

The backfill itself is straightforward: UNLOAD from Redshift to S3 in Parquet, then COPY INTO from an external stage in Snowflake. Chunk large tables by a date or id range so each unit is bounded and retriable. Load the biggest tables first, because they need the most time to catch up incrementally and they are the ones most likely to surface a type problem.

For the ongoing parallel period, the Redshift to Snowflake connector handles the watermark, the type casting, and the idempotent merges, which is the part teams do not want to build for a migration that runs for a few weeks and then stops.

How do Redshift data types map to Snowflake?

Redshift and Snowflake share ANSI SQL roots, so most types map directly. The ones that need a decision are SUPER (semi-structured, becomes VARIANT), VARCHAR length (Redshift counts bytes, Snowflake counts characters), and timestamps, where Redshift TIMESTAMP has no zone while TIMESTAMPTZ does.

The VARCHAR row is the one that quietly loses data. A Redshift VARCHAR(20) holds 20 bytes, which is only 20 characters for plain ASCII but far fewer for accented or non-Latin text. Copy the declared lengths across unchanged and any multibyte value that already fit in Redshift will still fit in Snowflake, since Snowflake counts characters, which is the more forgiving direction. The failure happens in reverse, so it is worth confirming rather than assuming.

What SQL differences break after moving from Redshift to Snowflake?

The breakages cluster in four places: identifier case, semi-structured access, date functions, and Redshift-specific syntax with no Snowflake equivalent. None are conceptually hard, but they surface as dozens of small model failures, which is why the SQL translation phase usually takes longer than the data copy.

Deal with case first because it is the widest blast radius. If your Redshift DDL created objects unquoted, they are lowercase, and any Snowflake object created unquoted is uppercase; a model that references "orders" in double quotes will not find ORDERS. The clean fix is to create everything in Snowflake unquoted and remove double quotes from your models, so both sides fold consistently and case stops being something anyone has to think about.

The maintenance row is the pleasant surprise. VACUUM and ANALYZE jobs, table-resize windows, and encoding tuning all disappear, which is real recurring engineering time you get back and worth counting when you justify the move.

Is Snowflake cheaper than Redshift?

It depends on how steady your workload is. Redshift provisioned clusters bill for nodes whether or not anyone queries them, so a steady round-the-clock workload can be cost-effective there. Snowflake bills per second of warehouse runtime with auto-suspend, so spiky or business-hours workloads usually cost less, and idle time costs almost nothing.

The variable that decides it is your utilization curve, not the list price. A cluster busy 20 percent of the day is paying for 80 percent idle; a Snowflake warehouse suspended after sixty seconds is not. Conversely a warehouse left running with a generous auto-suspend, or a team that sizes every warehouse large by default, erases the advantage quickly. Both platforms also offer serverless or elastic options that change the math further, so read your own bill rather than a comparison table.

Model it before you commit. Pull the last ninety days of query history from Redshift, work out the hours where anything actually ran, and size Snowflake warehouses against that profile; connecting the cloud spend read-only and watching it per workload after cutover is what stops a migration justified on cost from quietly becoming more expensive. The first month on a new warehouse is when consumption habits form.

How do I validate a Redshift to Snowflake migration?

Validate with parallel queries: run the same aggregate on both warehouses for the same time window and compare. Per table, check row count, a sum over every numeric column, distinct counts on key dimensions, and min plus max on the primary timestamp. If all four agree across every table, the copy is trustworthy.

Then validate the layer above the tables, which is where migrations actually go wrong. Run your top twenty dashboards and scheduled reports against both warehouses and diff the outputs, because a model can compile cleanly against Snowflake and still return different numbers thanks to a null-handling difference, a changed sort order, or a date function that rounds the other way at a boundary. A table that matches row for row while its downstream metric differs by 2 percent is the failure mode worth hunting.

Keep the parallel period long enough to cover a full reporting cycle, usually a month, so a monthly close runs on both sides before you decommission anything. That is also the window in which you repoint BI tools one at a time rather than in a single afternoon.

How long does a Redshift to Snowflake migration take?

For a typical warehouse of a few hundred tables and a few hundred models, plan six to twelve weeks end to end, with no reporting downtime if you run in parallel. The data copy is days; the SQL translation, validation, and BI repointing are the schedule.

A rough split from how these projects tend to run: about a week for schema conversion and the first backfill, two to four weeks translating and re-running models until outputs match, two to four weeks of parallel operation covering at least one monthly close, and a final week repointing dashboards and decommissioning. Teams with heavy stored-procedure logic or many spatial and semi-structured queries sit at the longer end.

You can compress the middle by moving in slices rather than all at once. Pick one business domain, migrate its tables and models, validate it, repoint its dashboards, and repeat. Each slice teaches you something that makes the next faster, and you are never one failed cutover away from a reporting outage. If your target is Google Cloud instead, the same structure applies through the Snowflake and BigQuery migration guide, which covers the reverse type map in detail.

For the parallel-run sync itself, the Redshift to Snowflake connector maps the pair in the browser, casts types, and merges on the key at a flat monthly price rather than a per-row meter, which matters when a migration means moving the same tables repeatedly. You can also book a walkthrough against your own schema.