Migrate Redshift to Snowflake in 5 Days: Scripts & Tools

16 minutes to read
Get free consultation

 

Moving your data warehouse from Amazon Redshift to Snowflake does not need to take months. In our work with analytics leaders, we have seen organizations complete full migrations in as little as five days when they follow a structured approach and use the right tools.

This guide walks you through the exact scripts, tools, and strategies we use to help companies accelerate their Redshift to Snowflake migrations. Whether you are a Chief Data Officer evaluating platforms or an Analytics Director managing the technical execution, you will find actionable steps to minimize downtime and maximize your return on investment.

Why Organizations Migrate from Redshift to Snowflake

Before diving into the how, let us address the why. Organizations typically choose Snowflake over Redshift for several compelling reasons:

Architecture Advantages:

Cost Optimization:

Clients report 30-40% cost savings after optimizing their Snowflake environment compared to their previous Redshift spend. The key is executing the migration efficiently so you can start realizing those savings faster.

The 5-Day Migration Framework

A successful migration breaks down into five distinct phases. Each phase has specific deliverables, tools, and scripts to keep you on track.

Day 1: Assessment and Planning

The first day focuses on understanding what you have and mapping your migration path. Rushing this step leads to scope creep and missed deadlines.

Your Actionable Steps:

Run this script to catalog all database objects:

-- Get table and schema inventory
SELECT 
    schemaname,
    tablename,
    tableowner,
    tabletype,
    pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) as table_size
FROM pg_catalog.pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC;

-- Get stored procedures inventory
SELECT 
    nspname as schema,
    proname as procedure_name,
    pg_get_function_arguments(oid) as arguments
FROM pg_proc p
JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE nspname NOT IN ('pg_catalog', 'information_schema');

Use Redshift system tables to identify your most critical workloads:

SELECT 
    query,
    querytxt,
    starttime,
    endtime,
    datediff(second, starttime, endtime) as duration_seconds
FROM stl_query
WHERE starttime > dateadd(day, -30, getdate())
ORDER BY duration_seconds DESC
LIMIT 100;

Document all upstream data sources (ETL jobs, streaming pipelines) and downstream consumers (BI tools, applications, data science notebooks).

Deliverable: A migration scope document listing all tables, views, stored procedures, and their priority ranking based on business impact.

Day 2: Environment Setup and Code Conversion

With your inventory complete, day two focuses on preparing your Snowflake environment and converting database code.

Set Up Your Snowflake Account:

Create an initial warehouse strategy that isolates workloads:

-- Create dedicated warehouses for different workloads
CREATE WAREHOUSE WH_ETL_LOADING
    WITH WAREHOUSE_SIZE = 'MEDIUM'
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE
    INITIALLY_SUSPENDED = TRUE;

CREATE WAREHOUSE WH_ANALYTICS
    WITH WAREHOUSE_SIZE = 'SMALL'
    AUTO_SUSPEND = 60
    AUTO_RESUME = TRUE
    INITIALLY_SUSPENDED = TRUE;

CREATE WAREHOUSE WH_DATA_SCIENCE
    WITH WAREHOUSE_SIZE = 'LARGE'
    AUTO_SUSPEND = 300
    AUTO_RESUME = TRUE
    INITIALLY_SUSPENDED = TRUE;

Code Conversion Tools:

The most efficient approach uses SnowConvert AI, Snowflake’s free migration tool. It handles the heavy lifting of converting DDL, DML, and procedural code.

For Redshift-specific constructs, here are the key transformations:

Redshift Snowflake Notes
GETDATE() CURRENT_TIMESTAMP() Direct replacement
DISTKEY, SORTKEY Remove entirely Snowflake handles distribution automatically
VACUUM, ANALYZE Remove entirely Automated maintenance
TIMESTAMPTZ TIMESTAMP_TZ Explicit time zone handling
SUPER (JSON) VARIANT Semi-structured data type

Sample DDL Conversion Script:

-- Redshift DDL (Before)
CREATE TABLE sales_data (
    sale_id INTEGER ENCODE az64,
    customer_id INTEGER ENCODE az64,
    sale_date TIMESTAMP,
    amount DECIMAL(10,2)
)
DISTSTYLE KEY
DISTKEY (customer_id)
SORTKEY (sale_date);

-- Snowflake DDL (After)
CREATE TABLE sales_data (
    sale_id INTEGER,
    customer_id INTEGER,
    sale_date TIMESTAMP_NTZ,
    amount NUMBER(10,2)
);

-- Add clustering key for large tables only
ALTER TABLE sales_data CLUSTER BY (sale_date);

Deliverable: Converted DDL scripts for all tables and views, converted stored procedures, and a functioning Snowflake environment.

Day 3: Data Migration

Day three is about moving your data efficiently. The most reliable method uses Amazon S3 as an intermediate staging area.

Step 1: Unload Data from Redshift

-- Unload to S3 in Parquet format for optimal performance
UNLOAD ('SELECT * FROM schema_name.table_name')
TO 's3://your-bucket/migration/table_name/'
IAM_ROLE 'arn:aws:iam::account-id:role/RedshiftUnloadRole'
FORMAT AS PARQUET
PARALLEL ON
MAXFILESIZE 256 MB;

Step 2: Create an External Stage in Snowflake

-- Create storage integration
CREATE STORAGE INTEGRATION s3_migration_int
    TYPE = EXTERNAL_STAGE
    STORAGE_PROVIDER = 'S3'
    ENABLED = TRUE
    STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::account-id:role/SnowflakeLoadRole'
    STORAGE_ALLOWED_LOCATIONS = ('s3://your-bucket/migration/');

-- Create stage pointing to S3
CREATE STAGE migration_stage
    STORAGE_INTEGRATION = s3_migration_int
    URL = 's3://your-bucket/migration/'
    FILE_FORMAT = (TYPE = PARQUET);

Step 3: Load Data into Snowflake

-- Use a sized-up warehouse for faster loading
ALTER WAREHOUSE WH_ETL_LOADING SET WAREHOUSE_SIZE = 'XLARGE';

-- Copy data from stage to table
COPY INTO sales_data
FROM @migration_stage/sales_data/
FILE_FORMAT = (TYPE = PARQUET)
MATCH_BY_COLUMN_NAME = CASE_INSENSITIVE;

-- Scale back down after loading
ALTER WAREHOUSE WH_ETL_LOADING SET WAREHOUSE_SIZE = 'MEDIUM';
Pro Tip: For tables over 1TB, consider running parallel COPY commands by partitioning your unload by date ranges.

For ongoing data synchronization during migration, tools like Fivetran can maintain real-time replication between both platforms until cutover.
https://stellans.io/wp-content/uploads/2026/01/stellans2026-01-15T14_59_49.593Z.png

Deliverable: All historical data loaded into Snowflake tables.

Day 4: Validation and Testing

Rigorous testing builds confidence and catches issues before they impact production.

Data Validation Script:

-- Row count comparison query for Redshift
SELECT 'sales_data' as table_name, COUNT(*) as row_count 
FROM schema_name.sales_data;

-- Row count comparison query for Snowflake
SELECT 'sales_data' as table_name, COUNT(*) as row_count 
FROM schema_name.sales_data;

-- Aggregate validation for numeric columns
-- Run on both platforms and compare results
SELECT 
    COUNT(*) as total_rows,
    SUM(amount) as total_amount,
    AVG(amount) as avg_amount,
    MIN(sale_date) as earliest_sale,
    MAX(sale_date) as latest_sale
FROM sales_data;

Performance Benchmarking:

Run your top 20 queries from the Day 1 analysis against both platforms. Document execution times to demonstrate performance improvements.

-- Enable query profiling in Snowflake
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

-- Run benchmark queries and capture timing
SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

BI Tool Testing:

Update connection strings in your BI tools (Tableau, Power BI, Looker) to point to Snowflake. Test all critical dashboards and reports for:

Deliverable: Validation report documenting row counts, aggregate comparisons, and performance benchmarks.

Day 5: Deployment and Cutover

The final day executes your go-live plan with minimal business disruption.

Cutover Checklist:

-- Run incremental load for data changed since Day 3
UNLOAD ('SELECT * FROM schema_name.table_name WHERE updated_at > ''2024-01-15''')
TO 's3://your-bucket/migration/incremental/'
IAM_ROLE 'arn:aws:iam::account-id:role/RedshiftUnloadRole'
FORMAT AS PARQUET;

Update your orchestration tool (Airflow, dbt, Fivetran) to target Snowflake:

# Example dbt profiles.yml update
snowflake_production:
  target: prod
  outputs:
    prod:
      type: snowflake
      account: your_account
      user: your_user
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      role: TRANSFORM_ROLE
      database: ANALYTICS
      warehouse: WH_ETL_LOADING
      schema: public

Update ODBC/JDBC connection strings for all applications.

-- Monitor query performance in Snowflake
SELECT 
    query_text,
    total_elapsed_time/1000 as seconds,
    bytes_scanned/1000000 as mb_scanned,
    warehouse_name
FROM snowflake.account_usage.query_history
WHERE start_time > dateadd(hour, -24, current_timestamp())
ORDER BY total_elapsed_time DESC
LIMIT 20;

Deliverable: Production Snowflake environment serving all workloads.

Key Roles for Migration Success

A successful migration requires clear ownership across several roles:

Role Responsibilities RACI Status
Project Lead Timeline management, stakeholder communication Accountable
Data Engineer Script development, data movement execution Responsible
DBA/Security Admin Access controls, role mapping Responsible
Business Analyst Validation testing, user acceptance Consulted
CDO/Analytics Director Executive sponsorship, resource allocation Informed

Post-Migration Optimization

Once live, optimize your Snowflake environment for cost and performance:

Set Aggressive Auto-Suspend:

ALTER WAREHOUSE WH_ANALYTICS SET AUTO_SUSPEND = 60;
CREATE RESOURCE MONITOR daily_monitor
    WITH CREDIT_QUOTA = 100
    FREQUENCY = DAILY
    START_TIMESTAMP = IMMEDIATELY
    TRIGGERS ON 75 PERCENT DO NOTIFY
             ON 90 PERCENT DO NOTIFY
             ON 100 PERCENT DO SUSPEND;

For detailed guidance on warehouse scaling and cost management, see our guide on automating Snowflake warehouse scaling with resource monitors.

When to Bring in Expert Help

While a 5-day migration is achievable, certain scenarios benefit from experienced guidance:

We have helped organizations complete migrations that seemed daunting at first. Our approach embeds experienced data engineers directly within your team, handling the technical execution while transferring knowledge to your staff. This model solves talent gaps without requiring full-time hires.

Measuring Migration Success

Track these KPIs to demonstrate ROI:

Performance Metrics:

Cost Metrics:

Operational Metrics:

Take the Next Step

Migrating from Redshift to Snowflake is a strategic investment that pays dividends in performance, cost savings, and operational agility. The 5-day framework we have outlined works because it balances speed with thoroughness.

Whether you need hands-on execution support or strategic guidance, our data engineering services can accelerate your migration timeline. We bring the experience of dozens of successful migrations to help you avoid common pitfalls and achieve results faster.

Ready to start your migration? Contact our team to discuss your specific requirements and timeline.

Frequently Asked Questions

How long does a typical Redshift to Snowflake migration take?

A straightforward migration can be completed in 5 days using the framework outlined in this guide. More complex environments with extensive stored procedures or multi-petabyte datasets may require 2-4 weeks. The key factor is preparation: organizations that thoroughly inventory their environment and prioritize workloads achieve faster migrations.

What tools automate Redshift to Snowflake code conversion?

SnowConvert AI is Snowflake’s free tool that automates DDL, DML, and procedural code conversion. It handles most Redshift-specific syntax automatically, including data type mappings and function translations. For the remaining manual conversions, the tool provides detailed reports highlighting areas requiring attention.

Can I run Redshift and Snowflake in parallel during migration?

Yes. Most organizations maintain both environments during a transition period. Use data replication tools to keep both platforms synchronized until you complete validation testing. This approach provides a fallback option if issues arise during cutover.

What are the main cost differences between Redshift and Snowflake?

Redshift charges for provisioned compute capacity regardless of usage. Snowflake charges only when queries run, with per-second billing and instant scaling. Organizations with variable workloads typically see 30-40% cost savings with Snowflake after optimization. The key is setting aggressive auto-suspend policies and right-sizing warehouses.

Do I need to rewrite all my stored procedures?

Redshift uses PL/pgSQL for stored procedures, which Snowflake does not support. You will need to rewrite these in Snowflake Scripting (SQL), JavaScript, Python, or Java. SnowConvert AI automates much of this translation, but complex business logic may require manual review and testing.

References

Article By:

https://stellans.io/wp-content/uploads/2026/01/Vitaly_Lilich.jpg
Vitaly Lilich

Co-founder & CEO

Related Posts

    Get a Free Data Audit

    * You can attach up to 3 files, each up to 3MB, in doc, docx, pdf, ppt, or pptx format.