Snowflake Migration Plan: 24-Week Template With Cutover and Owners

8 min read ยท 2026-10-25

A snowflake migration plan is a phased schedule for moving your data warehouse, pipelines and reports from a legacy platform to Snowflake, with owners, validation steps and a cutover date. Most plans follow the same path: inventory what you have, set up the Snowflake account and security, convert schemas and code, load and validate data, run old and new in parallel, then cut over and switch off the old system. The template below covers 24 weeks in six phases.

The hard parts are rarely the data load. They are the hidden stored procedures, the reports nobody listed, the business users who need to sign off and the compute costs nobody set limits on. This plan puts those up front. It also includes who owns what, a filled-in example, a validation checklist, the risks that delay cutover and how to present progress to leadership. Adjust the timeline to your data volume and the number of pipelines and reports.

The roadmap at a glance

Goal: By week 24, all in-scope data, pipelines and reports run on Snowflake, users have signed off on the results, and the legacy warehouse is switched off. Duration: 24 weeks

  1. Assessment and scope (Weeks 1-4)

    Know exactly what you are moving and decide how to move it.

    • Inventory databases, schemas, tables, views, stored procedures, ETL jobs, scheduled scripts and BI reports.
    • Use query logs from the legacy system to find which tables and reports are really used, and mark the rest for retirement.
    • Choose the approach: lift and shift first, or redesign pipelines during the move. Many teams lift and shift, then improve.
    • Group objects into migration waves by business domain, such as finance, sales and operations.
    • Set success criteria: data matches within agreed tolerances, report runtimes, cutover date.

    Milestone: A scoped inventory with migration waves, approach and success criteria signed off by the data platform lead and the business data owners.

  2. Account, security and foundations (Weeks 3-7)

    Set up Snowflake so every later step builds on a secure, cost-controlled base.

    • Design the account structure, databases and schemas for raw, staging and curated data.
    • Set up roles and access with role-based access control, linked to your identity provider for single sign-on.
    • Create virtual warehouses per workload, such as loading, transformation and BI, with auto-suspend settings.
    • Set resource monitors and budgets so compute spending triggers alerts before it becomes a surprise.
    • Configure network policies, encryption options and audit needs with your security team.

    Milestone: Snowflake environment approved by security, with roles, warehouses and resource monitors in place.

  3. Schema and code conversion (Weeks 6-12)

    Rebuild schemas and convert SQL, stored procedures and pipelines to run on Snowflake.

    • Convert DDL for tables and views, adjusting data types that differ between platforms.
    • Convert stored procedures and SQL scripts. Snowflake's SnowConvert tool can help for some source platforms, but plan for manual review.
    • Rebuild or repoint ETL and ELT jobs, for example in your orchestration tool or a transformation tool such as dbt.
    • Put all converted code in version control with code review.

    Milestone: All wave-one objects and pipelines deployed in a development environment and passing unit tests.

  4. Data migration and validation (Weeks 10-16)

    Load historical data and prove it matches the source.

    • Extract historical data to cloud storage and load it with COPY INTO, starting with the largest tables to test throughput.
    • Set up incremental loads, using Snowpipe or your pipeline tool for ongoing data.
    • Validate each table: row counts, checksums or aggregates on key columns, and null and duplicate checks.
    • Compare report outputs between the old and new systems for agreed sample periods.
    • Log every difference with an owner and a decision: fix, accept or explain.

    Milestone: All wave-one tables loaded and validated, with a reconciliation report signed off by business data owners.

  5. Parallel run and user acceptance (Weeks 15-21)

    Run old and new side by side until users trust Snowflake.

    • Run pipelines on both platforms daily and compare outputs automatically.
    • Repoint BI dashboards to Snowflake in a test workspace and have report owners check them.
    • Tune warehouse sizes and query performance for the heaviest reports.
    • Train analysts and engineers on Snowflake features they will use, such as Time Travel and zero-copy cloning.
    • Write the cutover runbook: freeze window, final sync, switch steps, checks and rollback plan.

    Milestone: User acceptance signed off for every in-scope report, and the cutover runbook approved in the go/no-go meeting.

  6. Cutover and decommission (Weeks 21-24)

    Switch production to Snowflake and retire the old platform.

    • Run the cutover during the agreed freeze window, following the runbook step by step.
    • Hold a hypercare period with daily checks on loads, reports and costs.
    • Keep the legacy system read-only for an agreed period, then archive what your retention rules require.
    • Switch off legacy servers and end licenses and contracts.

    Milestone: Production running on Snowflake through hypercare with no critical issues, and the legacy warehouse shut down.

Who owns what

A data migration involves engineering, analytics, security, finance and the business teams who trust the numbers. Name owners early and put them in a RACI on the first page of the plan.

The most often forgotten owners are the business data owners. Without their sign-off, validation never ends because nobody can say the numbers are right.

  • Data platform lead (program owner): plan, waves, status, go/no-go decision.
  • Data architect: target design, data modeling, conversion approach.
  • Data engineers: conversion, pipelines, loads, performance tuning.
  • BI lead: report inventory, repointing dashboards, report validation.
  • Security team: roles, access, network policies, audit.
  • Business data owners (finance, sales, operations): validation rules and sign-off.
  • FinOps or finance: budgets, resource monitors, cost reporting.

Example: a retailer moving from an on-premises warehouse

Picture a retailer with an on-premises SQL Server warehouse, around 300 tables, many stored procedures and a set of Power BI reports used by finance and merchandising. The hardware support contract ends in eight months, which sets the deadline.

The team starts with finance because it has the strictest checks, then uses what it learns for the larger merchandising domain.

  • Weeks 1-4: inventory finds a large share of tables unused in the last year, marked for retirement. Owner: data platform lead. Milestone: scope signed.
  • Weeks 3-7: Snowflake account, roles mapped to Azure AD groups, warehouses for loading and BI. Owner: data architect. Milestone: security approval.
  • Weeks 6-16: finance wave converted, loaded and reconciled to the cent against month-end reports. Owner: data engineering lead. Milestone: finance controller signs off.
  • Weeks 15-21: merchandising wave in parallel run, Power BI reports repointed. Owner: BI lead. Milestone: user acceptance signed.
  • Weeks 21-24: cutover over a weekend, two weeks of hypercare, old server read-only then off. Owner: data platform lead. Milestone: legacy shut down.

Validation checklist

Validation is where trust is won or lost. Agree on the checks and tolerances with business data owners before you load any data, not after they find a difference.

Automate the checks so they can run every day during the parallel run. Keep the results in a shared log that owners can read.

  • Row counts match per table and per load date.
  • Sums and averages of key numeric columns match within the agreed tolerance.
  • No unexpected nulls or duplicates in primary key columns.
  • Date and time values match, including time zones.
  • Key reports show the same totals for agreed sample periods.
  • Pipeline run times meet the agreed schedule.

Cost controls from day one

Snowflake bills compute and storage separately, and compute grows with how warehouses are sized and how long they run. Without guardrails, migration testing and parallel runs can use more compute than expected.

Set the rules in the foundations phase and report spending weekly during the migration. Confirm current pricing and features with your Snowflake account team.

  • Separate warehouses per workload so you can see who uses what.
  • Auto-suspend set on every warehouse.
  • Resource monitors with alerts at agreed thresholds.
  • Start warehouses small and size up only when a workload needs it.
  • A weekly cost review with the data platform lead and finance.

Risks and dependencies

Log risks in the first week, each with an owner and a fallback. Review them in the weekly status meeting and raise anything that threatens the cutover date to the sponsor.

The biggest dependency is business availability for validation and user acceptance. Book their time in the plan the same way you book engineering time.

  • Hidden logic in stored procedures. Owner: data architect. Fallback: add buffer to the conversion phase and review complex procedures first.
  • Unlisted reports and extracts. Owner: BI lead. Fallback: check query logs for every user and service account before cutover.
  • Validation differences nobody can explain. Owner: business data owner. Fallback: agree tolerances up front and log decisions.
  • Compute costs above budget. Owner: FinOps. Fallback: resource monitors and warehouse right-sizing.
  • Cutover issues. Owner: data platform lead. Fallback: a tested rollback plan and the legacy system kept read-only.

How to present it to leadership

Use one slide. At the top, a 24-week timeline with the six phases and the cutover date. Below, one row per migration wave with its status in green, amber or red and the business owner who signs off. Add the top three risks with owners, and a small box with compute spending against budget.

Leave the object counts and technical details out of the summary. Leadership cares about the date, the business sign-offs and cost. Keep the inventory and validation log as appendices for anyone who wants the detail.

Common mistakes to avoid

  • Migrating every table without checking usage moves data nobody needs, so use query logs to retire unused objects first.
  • Leaving cost controls for later creates surprise bills during testing, so set auto-suspend and resource monitors in the foundations phase.
  • Treating stored procedure conversion as automatic underestimates effort, so review converted code and budget time for manual fixes.
  • Validating only row counts misses wrong values, so check aggregates, keys and report totals too.
  • Cutting over without a parallel run removes the safety net, so run both systems side by side until users sign off.
  • Keeping the legacy warehouse running forever doubles costs, so set a decommission date in the plan and track it.

Frequently asked questions

How long does a Snowflake migration take?

It depends on data volume, the number of pipelines, reports and stored procedures, and team capacity. Smaller migrations can finish in a few months, while large enterprise warehouses can take a year or more. Planning in waves by business domain helps you deliver value earlier.

What are the steps of a Snowflake migration?

The usual steps are assessment, account and security setup, schema and code conversion, data loading, validation, parallel run, cutover and decommissioning. Each step needs an owner and a milestone you can check.

Should you lift and shift or redesign when moving to Snowflake?

Many teams move existing logic first to meet a deadline, then improve pipelines on Snowflake afterward. A redesign during the move makes sense when the old pipelines are poorly understood or already being replaced. Decide per domain rather than for the whole program.

How do you validate data after migrating to Snowflake?

Compare row counts, aggregates of key columns, null and duplicate checks, and the totals of key reports between the old and new systems. Agree tolerances with business data owners first and automate the checks during the parallel run.

How do you control costs during a Snowflake migration?

Create separate warehouses per workload, set auto-suspend, and use resource monitors with alerts. Start with small warehouse sizes and review spending weekly with finance.

Generate this roadmap with AI