migrating toBrowse playbooks
← All playbooks
Data warehouses migration

Amazon Redshift → Snowflake

Move databases, schemas, tables, and rows, data types, precision, nulls, and time zones, views, materialized views, and sql dialect, primary keys, constraints, and data quality, users, roles, grants, row and column policy, pipelines, stages, external tables, and file formats, scheduled queries, tasks, procedures, and udfs, bi, dbt, notebooks, and downstream consumers from Amazon Redshift to Snowflake with a reversible cutover, explicit exception ledger, and evidence-backed verification.

Typical timeline15–45 business days70–180 hours active work
Statusneeds review
Source profileAmazon Redshift documentation reviewed 2026-07-20
Destination profileSnowflake documentation reviewed 2026-07-20
Documentation date
Review window
Evidence2 sources
This route needs review.Use it as a planning baseline, then verify the dated sources and test with representative data before production.
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Amazon Redshift

Reasons to stay
  • Deep AWS integration and mature SQL warehousing support large enterprise analytical workloads
  • Managed analytical storage and compute support large-scale SQL, governance, and reporting
Reasons to leave
  • Cluster design, distribution, workload management, and AWS-specific operations demand specialist tuning
  • SQL dialects, security models, pipelines, workload tuning, and historical evidence create deep lock-in
New platform

Snowflake

What gets better
  • Elastic compute, data sharing, governance, and cross-cloud availability support sophisticated analytical programs
  • Managed analytical storage and compute support large-scale SQL, governance, and reporting
What gets worse
  • Snowflake SQL, stages, tasks, security objects, and consumption economics create deep platform dependence
  • SQL dialects, security models, pipelines, workload tuning, and historical evidence create deep lock-in
Best of the move

Snowflake: Elastic compute, data sharing, governance, and cross-cloud availability support sophisticated analytical programs. This removes a major source-side concern: Cluster design, distribution, workload management, and AWS-specific operations demand specialist tuning.

Worst of the move

What you lose: Deep AWS integration and mature SQL warehousing support large enterprise analytical workloads. What you inherit: Snowflake SQL, stages, tasks, security objects, and consumption economics create deep platform dependence.

Connected catalog

2 destinations are documented from Amazon Redshift. Compare nearby routes before committing.

Also from Amazon Redshift
Also moving to Snowflake
Jump to a section
01At a glance

Know the shape of the move.

Transfer outcome10 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 2, Manual rebuild: 7, Not transferred: 1.
Clean0
Partial2
Manual7
Lost1
Mapping route8 of 9 fields have a destination path

This timeline assumes

  • Up to 100 TB, 10,000 tables, 5,000 scheduled jobs, and 1,000 users
  • Administrators control both Amazon Redshift and Snowflake, including billing, identity, APIs, integrations, and export permissions.
  • Amazon Redshift remains intact and recoverable until Snowflake completes one representative operating cycle.
  • A production-shaped pilot includes every object type, access class, edge case, and failure path.
  • The migration team preserves stable source identifiers and records durable evidence for every blocking check.
02What transfers

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Databases, schemas, tables, and rowspartialcriticalNamespace depth, table kinds, partitioning, clustering, and load formats require transformation. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Map databases, schemas, tables, and rows explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Data types, precision, nulls, and time zonespartialcriticalNumeric precision, semi-structured types, timestamps, geography, arrays, and null semantics differ. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Map data types, precision, nulls, and time zones explicitly, pilot every feature class, and reconcile accepted, changed, rejected, and excluded items.
Views, materialized views, and SQL dialectmanualcriticalFunctions, quoting, DDL, procedural SQL, optimizer hints, and materialization behavior require conversion. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild views, materialized views, and sql dialect, then test normal, edge, failure, and rollback behavior.
Primary keys, constraints, and data qualitymanualcriticalConstraint enforcement and informational metadata vary and cannot be assumed after loading. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild primary keys, constraints, and data quality, then test normal, edge, failure, and rollback behavior.
Users, roles, grants, row and column policymanualcriticalIdentity, role hierarchy, ownership, masking, row access, and authorized views need redesign. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild users, roles, grants, row and column policy, then test normal, edge, failure, and rollback behavior.
Pipelines, stages, external tables, and file formatsmanualcriticalCloud storage integration, credentials, copy commands, stages, and external metadata are platform-specific. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild pipelines, stages, external tables, and file formats, then test normal, edge, failure, and rollback behavior.
Scheduled queries, tasks, procedures, and UDFsmanualcriticalSchedulers, runtimes, languages, packages, and execution identity do not transfer. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild scheduled queries, tasks, procedures, and udfs, then test normal, edge, failure, and rollback behavior.
BI, dbt, notebooks, and downstream consumersmanualhighConnection strings, database names, SQL behavior, drivers, and cached extracts must be updated. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild bi, dbt, notebooks, and downstream consumers, then test normal, edge, failure, and rollback behavior.
Query history, lineage, and audit evidencelosthighHistorical query plans, result caches, lineage, access history, and workload evidence remain source-native. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Archive query history, lineage, and audit evidence as dated source evidence and define the new destination baseline.
Performance, concurrency, capacity, and costmanualcriticalWarehouse sizing, slots, distribution, queues, caching, and billing models require new baselines. A successful bulk job therefore does not prove semantic parity between Amazon Redshift and Snowflake.Inventory and rebuild performance, concurrency, capacity, and cost, then test normal, edge, failure, and rollback behavior.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Amazon Redshift: Databases, schemas, tables, and rowsSnowflake: approved databases, schemas, tables, and rows representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for databases, schemas, tables, and rows.
Amazon Redshift: Data types, precision, nulls, and time zonesSnowflake: approved data types, precision, nulls, and time zones representationtransformPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for data types, precision, nulls, and time zones.
Amazon Redshift: Views, materialized views, and SQL dialectSnowflake: approved views, materialized views, and sql dialect representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for views, materialized views, and sql dialect.
Amazon Redshift: Primary keys, constraints, and data qualitySnowflake: approved primary keys, constraints, and data quality representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for primary keys, constraints, and data quality.
Amazon Redshift: Users, roles, grants, row and column policySnowflake: approved users, roles, grants, row and column policy representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for users, roles, grants, row and column policy.
Amazon Redshift: Pipelines, stages, external tables, and file formatsSnowflake: approved pipelines, stages, external tables, and file formats representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for pipelines, stages, external tables, and file formats.
Amazon Redshift: Scheduled queries, tasks, procedures, and UDFsSnowflake: approved scheduled queries, tasks, procedures, and udfs representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for scheduled queries, tasks, procedures, and udfs.
Amazon Redshift: BI, dbt, notebooks, and downstream consumersSnowflake: approved bi, dbt, notebooks, and downstream consumers representationmanualPreserve source IDs, ownership, timestamps, access intent, and an explicit exception status for bi, dbt, notebooks, and downstream consumers.
Amazon Redshift: Query history, lineage, and audit evidenceNo destinationunsupportedRetain immutable source evidence; do not manufacture destination-native history.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Amazon Redshift data, configuration, access, and operating evidence before any destination write.

  1. Export every available Amazon Redshift object and binary in scope, including databases, schemas, tables, and rows, data types, precision, nulls, and time zones, views, materialized views, and sql dialect, primary keys, constraints, and data quality.
  2. Capture configuration and runtime dependencies for users, roles, grants, row and column policy, pipelines, stages, external tables, and file formats, scheduled queries, tasks, procedures, and udfs, bi, dbt, notebooks, and downstream consumers.
  3. Record counts, sizes, owners, timestamps, access classes, financial totals where applicable, and known exceptions.
  4. Hash immutable exports, record tool versions and commands, and transform working copies only.

Proof to capture: A signed manifest accounts for every scoped record class, configuration object, binary, count, total, exception, and hash.

Transformation · Version-controlled migration workbook, SQL, or typed transformation code

Identity, schema, and disposition registry

Preserve stable identity and make every mapping or exclusion reviewable.

  1. Inventory source types, identifiers, owners, states, and access.
  2. Define one approved destination representation or explicit archive decision.
  3. Reject unmapped critical items and produce an exception ledger.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Official APIs, provider importers, checksums, and reconciliation scripts

Dependency-ordered migration package

Load prerequisite identities and configuration before dependent records and runtime actions.

  1. Normalize encoding, timestamps, identifiers, nulls, and destination limits.
  2. Run a representative pilot and retain request, response, and rejection evidence.
  3. Reconcile the final delta before enabling destination production writers.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Import

A completed migration hides missing or altered databases, schemas, tables, and rows

criticalpossible likelihood

Headline counts look plausible while semantic, access, or relationship checks fail.

Consequence
The destination becomes authoritative with incomplete or misleading business data.
Mitigation
Reconcile by type, state, owner, access class, and representative record rather than total count alone.

Stop if: Any critical item lacks a verified destination, approved transformation, explicit exclusion, or recoverable archive.

Cutover

Amazon Redshift and Snowflake both perform production actions

criticalpossible likelihood

Users, schedules, webhooks, integrations, or traffic continue changing both systems.

Consequence
State diverges or customers receive duplicate, contradictory, or unsafe actions.
Mitigation
Freeze source writers and transfer one production owner at a time with an approved rollback.

Stop if: An unapproved source writer or destination duplicate action appears after the freeze.

Verification

Destination access or security is broader than approved

criticalpossible likelihood

A representative restricted user can read, change, export, or trigger an unauthorized item.

Consequence
Confidential, regulated, financial, or security-sensitive data is exposed or changed.
Mitigation
Apply least privilege before bulk loading and test every access class using ordinary identities.

Stop if: Any unauthorized read, write, export, administrative action, or secret access succeeds.

06Precise timeline

Do the work in this order.

Estimate forUp to 100 TB, 10,000 tables, 5,000 scheduled jobs, and 1,000 users
Total elapsed15–45 business days
Active work70–180 hours
BufferAdd time for large Amazon Redshift exports, destination rate limits, unsupported features, identity exceptions, regulated data, or a strict downtime objective.
01
Days 1–4Inventory and decisions2–4 days
02
Days 3–8Backup and reconcile2–5 days
03
Days 6–20Map, transform, and pilot5–12 days
04
Days 18–35Bulk load, final delta, and switch2–8 days
05
Days 25–45Observe and close7–14 days
  1. Days 1–4 · inventory

    Inventory and decisions

    8–16 hours active2–4 days elapsedOwner, legal, security, and finance review waiting
    • Inventory Amazon Redshift data, configuration, identities, integrations, limits, and billing.
    • Approve scope, owners, mappings, exclusions, acceptance thresholds, and rollback authority.

    Depends on: Amazon Redshift and Snowflake administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item and production action has an owner and disposition.

    Stop when: Authority, retention, billing, access, or system ownership is unclear.

  2. Days 3–8 · backup

    Backup and reconcile

    8–20 hours active2–5 days elapsedProvider export processing waiting
    • Create immutable data, configuration, binary, and audit exports.
    • Reconcile source counts, totals, sizes, access classes, and hashes.

    Depends on: Approved inventory and retention location

    Stop / go checkpoint

    Transform?

    Go when: The signed source manifest and exports agree.

    Stop when: Any critical dataset, binary, configuration, or recovery path is absent.

  3. Days 6–20 · pilot

    Map, transform, and pilot

    25–70 hours active5–12 days elapsedDestination processing and owner review waiting
    • Configure Snowflake and transform a production-shaped pilot.
    • Test normal records, every feature class, edge cases, permissions, failures, and rollback.

    Depends on: Verified source backup and approved mapping registry

    Stop / go checkpoint

    Scale?

    Go when: Every pilot mapping and blocking verification check passes.

    Stop when: Any critical invariant, access boundary, or production action lacks a safe destination.

  4. Days 18–35 · cutover

    Bulk load, final delta, and switch

    20–55 hours active2–8 days elapsedImports, propagation, indexing, or synchronization waiting
    • Freeze production writes and automated actions in Amazon Redshift.
    • Apply and reconcile the final delta, switch ownership to Snowflake, and run all blocking checks.

    Depends on: Passed pilot, stakeholder go decision, and rehearsed rollback

    Stop / go checkpoint

    Open production?

    Go when: Snowflake is the sole production owner and every critical exception is resolved.

    Stop when: A source writer remains active, a blocking check fails, or rollback is unavailable.

  5. Days 25–45 · observe

    Observe and close

    9–19 hours active7–14 days elapsedRepresentative operating-cycle evidence waiting
    • Monitor correctness, access, failures, latency, delivery, cost, and user outcomes.
    • Sign the verification report and close rollback only after stable evidence.

    Depends on: Verified cutover

    Stop / go checkpoint

    Close rollback?

    Go when: No trigger occurs during the approved observation period.

    Stop when: Data, access, delivery, routing, cost, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Snowflake the only production system without losing the final Amazon Redshift delta.

Recommended window: A low-volume weekday morning with platform, data, security, networking, finance, and business owners available.

  1. Freeze user, integration, schedule, and API writes in Amazon Redshift.
  2. Capture and reconcile the final source delta against the last verified checkpoint.
  3. Apply the approved delta and configuration changes to Snowflake.
  4. Switch traffic, domains, integrations, credentials, automation, and user entry points in dependency order.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Snowflake alone owns production, totals reconcile, exceptions are signed, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Amazon Redshift without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, keys, or retention settings are changed.

  1. Stop new user, integration, schedule, and API writes in Snowflake.
  2. Restore prior Amazon Redshift traffic, domains, credentials, automation, and integration ownership.
  3. Export and classify the Snowflake post-cutover delta.
  4. Apply safe destination-era changes back to Amazon Redshift without duplicating actions.
  5. Run the same blocking checks against the restored source.

Proof to capture: Amazon Redshift again owns production with current data and no duplicate destination action.

Rollback immediately when
  • Unexplained critical count, value, relationship, or checksum variance
  • Missing, corrupted, or exposed critical data
  • Duplicate production action or unresolved split-brain state
  • Failed access, security, delivery, routing, performance, or integration check
  • A critical feature has no safe destination replacement or rollback path
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingDatabases, schemas, tables, and rows reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for databases, schemas, tables, and rows.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Databases, schemas, tables, and rows ledger with counts, exceptions, sample IDs, and owner sign-off.
V-02BlockingData types, precision, nulls, and time zones reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for data types, precision, nulls, and time zones.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Data types, precision, nulls, and time zones ledger with counts, exceptions, sample IDs, and owner sign-off.
V-03BlockingViews, materialized views, and SQL dialect reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for views, materialized views, and sql dialect.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Views, materialized views, and SQL dialect ledger with counts, exceptions, sample IDs, and owner sign-off.
V-04BlockingPrimary keys, constraints, and data quality reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for primary keys, constraints, and data quality.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Primary keys, constraints, and data quality ledger with counts, exceptions, sample IDs, and owner sign-off.
V-05BlockingUsers, roles, grants, row and column policy reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for users, roles, grants, row and column policy.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Users, roles, grants, row and column policy ledger with counts, exceptions, sample IDs, and owner sign-off.
V-06BlockingPipelines, stages, external tables, and file formats reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for pipelines, stages, external tables, and file formats.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Pipelines, stages, external tables, and file formats ledger with counts, exceptions, sample IDs, and owner sign-off.
V-07BlockingScheduled queries, tasks, procedures, and UDFs reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for scheduled queries, tasks, procedures, and udfs.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.Scheduled queries, tasks, procedures, and UDFs ledger with counts, exceptions, sample IDs, and owner sign-off.
V-08BI, dbt, notebooks, and downstream consumers reconciliationCompare source inventory, transformed output, destination results, and a stratified sample for bi, dbt, notebooks, and downstream consumers.Every in-scope item is present, intentionally transformed, explicitly excluded, or retained in the signed source archive.BI, dbt, notebooks, and downstream consumers ledger with counts, exceptions, sample IDs, and owner sign-off.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check and exception.

  1. Create final Amazon Redshift exports and archive verification, access, financial, and rollback evidence.
  2. Revoke temporary credentials, API keys, webhooks, elevated roles, and migration network access.
  3. Remove obsolete jobs, embeds, domains, integrations, collectors, routes, and DNS records.
  4. Keep the source intact and read-only through the approved legal and operational retention window.
  5. Cancel paid plans only after billing, legal, security, evidence, and recovery review.
  6. Schedule the next Snowflake backup, restore test, access review, and migration-playbook review.
10Experiences from the field

When the plan met reality.

First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.

First-person accountSanket Nalawade · Apisero

Redshift to Snowflake Migration2021

Sanket Nalawade describes moving a warehouse containing hundreds of terabytes from Amazon Redshift to Snowflake after concurrency growth pushed disk and CPU utilization above 90%, delayed Tableau queries, and forced manual ETL reruns. The team unloaded Redshift data to Amazon S3, cleaned and transformed it, then loaded Snowflake with COPY while coordinating Talend, Matillion, AWS DMS, and reporting workloads.

What they recommend
  • Inventory every batch, replication, and BI consumer before moving data because warehouse contention can hide cross-system dependencies.
  • Stage exports in object storage and validate transformations separately from the final Snowflake load.
Worth noticing
  • The trigger was operational contention at scale, not a failure of Redshift to serve the original workload.
  • Moving the tables was only one part of a warehouse migration that also involved ETL, real-time replication, and Tableau.
Sources and evidence

Verify against the primary material.

Platform behavior changes. Check these sources and the review dates above before executing a production migration.

  1. Amazon Redshift: official portability and migration documentationAccessed 2026-07-20
  2. Snowflake: official portability and migration documentationAccessed 2026-07-20