DCF Research

Snowflake Migration Guide: Phases, Tools, Timelines

By DCF ResearchEdited by Peter KorpakPublished · Updated

A Snowflake migration moves schemas, code, data and downstream reports off a legacy platform in dependency-ordered waves. Much of the effort sits in converting and testing business logic rather than copying data. Snowflake now offers free conversion tooling and an AI-assisted migration agent for the main source platforms, but you still need people who know your source system, a validation plan and a parallel run before cutover.

This guide is part of our Snowflake consultants research. Snowflake tooling details are as documented in October 2026.

What are the phases of a Snowflake migration?

A migration runs in seven phases: assess, design the target, convert code, move data, validate, run in parallel and cut over, then decommission and tune. The middle phases repeat for each wave of related objects instead of running once for the whole estate.

  1. Assess and scope. Inventory tables, views, procedures, ETL jobs and reports. Flag dead, duplicate and staging objects, find dynamic SQL (Snowflake's documentation calls it often the hardest code to convert), and group objects into dependency-ordered waves. Snowflake's assessment produces an exclusion report, a dynamic SQL report and a waves report. Exit criterion: an agreed in-scope list and wave plan.
  2. Design the target. Decide the account and role structure, warehouse layout, naming and cost guardrails before data lands. Decide per subject area whether to lift and shift, modernize, or take the middle path Snowflake calls pragmatic lift, adjust and shift.
  3. Convert code. Run source DDL, SQL and procedures through SnowConvert. It flags what it cannot translate as errors, warnings and issues (EWIs) and functional difference messages (FDMs), which are fixed by hand or with AI assistance. Exit criterion: converted objects deploy to a test database without errors.
  4. Move data. Bulk-load history, then keep the target current with incremental loads or change data capture (CDC) until cutover. Snowflake's migration tooling extracts to files in a stage and loads with COPY INTO. Snowflake Openflow offers CDC connectors for SQL Server, Oracle, PostgreSQL and MySQL; third-party replication services are the alternative.
  5. Validate. Compare schema, aggregate metrics and selected rows, and test procedures and functions against baselines captured from the source. Details are in the validation section below.
  6. Run in parallel and cut over. Run old and new side by side on the same inputs until agreed reports reconcile, then repoint BI tools, ETL and applications wave by wave. Keep a tested rollback path until the legacy retention checks pass.
  7. Decommission and tune. Shut down the legacy platform, then review warehouse sizes, auto-suspend settings and budgets against actual usage. See our guide to Snowflake cost optimization.

Which tools does Snowflake provide for migration?

As of October 2026, Snowflake's migration tooling is branded Snowflake AIM. It pairs SnowConvert AI, which converts code, with an agent inside Snowflake CoCo that drives assessment, wave-based deployment, data migration and validation. Snowflake's pricing page lists code conversion tools as free; the credits your loads and tests consume are not.

ToolWhat it doesCoverage and limits (Snowflake docs, October 2026)
Snowflake AIM Agent for Data WarehousesSix-stage guided workflow: connect, init, register, convert, assess, migrate. Builds deployment waves, migrates data, validates it, and tests procedures against source baselines.Source connections for SQL Server, Redshift, Oracle, Teradata and PostgreSQL. In its support matrix several capabilities are marked planned for Teradata, Oracle and PostgreSQL, and AI conversion and verification is listed for SQL Server and Redshift only.
SnowConvert AI (CLI and desktop)Converts source code to Snowflake SQL and reports EWIs and FDMs.Deterministic conversion covers many dialects, including Teradata, Oracle, SQL Server, Redshift, Azure Synapse, BigQuery, Netezza, Vertica, Hive and Db2. Snowflake recommends the AIM agent for new projects and the CLI for manual migrations.
Snowflake AIM for VirtualizationTeradata only. A gateway translates Teradata SQL in real time so existing applications can run on Snowflake with few rewrites.Customer-deployed on Red Hat-compatible Linux VMs; starts with an assessment of Teradata schema and query logs.
Snowpark Migration AcceleratorScans Python and Scala code that calls Spark APIs, inventories it, and converts it to use the Snowpark API.Spark workloads only.
Snowflake OpenflowData integration service with CDC connectors for SQL Server, Oracle, PostgreSQL and MySQL.Generally available for Snowflake deployments on AWS, Azure and Google Cloud commercial regions.

Check the support matrix for your source before assuming coverage, because the docs separate what is available from what is planned. SnowConvert AI use is subject to Snowflake's Conversion Software Terms of Use.

Partner proposals often add third-party tools: replication or CDC services (Snowflake's NAVEX story names Fivetran and AWS Database Migration Service for ingestion), dbt for transformation, and data-testing products. Ask which are in scope, who licenses them, and what they add beyond Snowflake's own tools. For a Snowflake-delivered option, Snowflake's own services team offers migration planning and execution with SnowConvert, working with partners.

How do you validate a migration and cut over safely?

Validate at three levels, test business logic against source baselines, and cut over wave by wave after a parallel run with written exit criteria. Snowflake's data validation compares schema (L1), aggregate metrics (L2) and, where you enable it, individual rows and cells (L3).

  • Data levels. L2 numeric comparisons use a default tolerance of 0.001. L3 is optional because row-level comparison across many partitions is expensive; Snowflake advises starting with a small set of tables and L3 off, then enabling row validation only where you need it, such as ledgers and regulated data.
  • Procedures and functions. The AIM agent captures the output of source procedures from query logs or AI-generated test cases, runs the converted object on a zero-copy clone, and loops on fixes until outputs match. The source database is the reference, so capture baselines while it is still reachable.
  • Constraints. Snowflake enforces NOT NULL but only declares primary key, foreign key and unique constraints on standard tables; they are enforced on hybrid tables. If the legacy system relied on constraints to reject duplicates, add uniqueness and referential tests to the new pipelines.
  • Parallel run. Agree before it starts how many consecutive loads must reconcile, which reports must match and within what tolerance, who signs off for the business, and who pays for running both platforms.
  • Cutover by wave. The assessment orders objects so dependencies deploy first, with 40 objects per wave by default and adjustable. Business cutover can then follow subject areas, repointing reports after each area reconciles. For Teradata sources, virtualization lets existing applications keep their SQL while data moves.
  • Zero downtime. For an analytics warehouse this usually means users keep the legacy system until cutover. What needs a freeze is the final delta load and any schema change, so have the partner define the term in the statement of work.

How long does a Snowflake migration take?

Vendor-reported examples run from six weeks to eight months, and a 2020 peer poll put the typical expectation at 6 to 12 months. We use three planning bands, shown below as DCF Research estimates; run the assessment on your own code and replace them with its output.

ScopePlanning range (DCF Research estimate)Basis
Small: one source system, limited custom logic, modest report count6 weeks to 4 monthsVendor-reported cases of six weeks, about three months and four months in the next table
Typical: one legacy warehouse with stored procedures, ETL jobs and dozens of reports6 to 12 monthsHalf of poll respondents chose 6 to 12 months; one vendor-reported 8-month healthcare payer engagement
Large: several sources, heavy procedural logic, many downstream consumers12 to 24 months or more40% of poll respondents chose 12 months or longer (28% for 12 to 18, 8% for 18 to 24, 4% for over 24)
ExampleWhat movedReported timeSource
Travelpass30 TB and 134 pipelines or processes, with Snowflake's services teamSix weeksSnowflake migration page (2026), vendor-reported
WHOOPRedshift, Dremio, PostgreSQL and other sources, including data cleanupAbout three months (done in 2022)Snowflake blog (2024), vendor-reported
Core Digital MediaTeradata appliance, about 150 usersWithin four months, Teradata decommissionedSnowflake blog (2024), vendor-reported
Healthcare payer (unnamed client of Hakkoda, now part of IBM)More than 2 PB in 12 databases, 700+ queries; Teradata decommissioned8-month engagementHakkoda blog (2024), vendor-reported
Gartner Peer Community poll721 respondents on a fair timeline for leaving a legacy warehouseUnder 6 months 7%; 6 to 12 months 50%; 12 to 18 months 28%; 18 to 24 months 8%; over 24 months 4%Gartner Peer Community (poll from about 2020, judging by its comments); opinions, not measured outcomes

The cases are vendor-reported and unaudited. Even so, they suggest that data volume does not set the schedule by itself: the Hakkoda case moved more than 60 times the data of the Travelpass case in under six times the duration.

What stretches a schedule: dynamic SQL and business logic buried in procedures, replacing an ETL tool at the same time, many reports to repoint, data quality problems that validation exposes in the legacy system, long parallel runs and change freezes. What shortens it: removing dead objects early (the assessment flags deprecated, temporary, test and duplicate objects for review with subject-matter experts), wave-based work, automated conversion of routine objects, and early business sign-off on reconciled reports.

Snowflake's documentation does not publish a share of code that converts automatically. Ask a partner to measure it on a sample of your own code, as the share of objects that convert with no EWIs, instead of quoting a firm-wide figure.

What should you require from a Snowflake migration partner?

Require evidence that the team has moved your source platform to Snowflake at similar scale, named certified staff, a wave plan with validation evidence per wave, and clear terms for the parallel run and handover. Snowflake's partner tier is a program measure, not an audit of delivery quality.

Snowflake says its services partners sit in Select, Premier or Elite tiers, that a tier reflects certifications, closed pipeline, deal registrations and customer success stories, and that Select, Premier and Elite partners each pay an annual fee. On October 23, 2026 Snowflake's directory listed 1,127 AI Data Cloud Services Partner entries: 885 Select, 131 Premier and 111 Elite, so about one entry in ten is Elite. Snowflake's partner directory lists Accenture, Deloitte, Slalom, Cognizant, Infosys, Tredence and phData, among other firms we track, as Elite Services partners (checked October 2026). Entries are by legal entity and region: KPMG's four listings show Elite, Premier and Select, and Wipro's two show Elite and Select. Check the listing for the entity that will sign your contract.

Put these in the statement of work:

  1. Paid assessment first. Ask for assessment output on your code before the build is priced: objects by type, EWI counts, dynamic SQL, ETL packages and proposed waves.
  2. Named staff. Ask for named architects and engineers, their SnowPro Advanced certifications and their allocation. Snowflake's directory listings show a count of SnowPro Core and Advanced certifications per partner entity, which does not tell you who will be on your team.
  3. Same-source references. Two references that migrated from your source platform to Snowflake at a comparable object count, with contacts you can call.
  4. Wave evidence. Per wave: validation levels run, tolerances used, procedures tested against baselines, and defects still open at sign-off.
  5. Parallel run and rollback. Duration, exit criteria, who pays for both platforms, and the trigger for rolling back.
  6. Commercial terms. Fixed price per wave, or capped time and materials with a change process tied to object counts. Settle who owns converted code and runbooks, and whether partner accelerators carry license fees.
  7. Handover and guardrails. Documentation, training for your team, and resource monitors and budgets in place before go-live.

DCF Research tracks 50 data and AI consulting firms using public evidence, does not let firms pay to change their score or rank, and has not audited any firm's migration work. For what a migration can cost, see Snowflake implementation cost. For moves between clouds or platforms more broadly, see our cloud data platform migration guide.

Frequently asked questions

Is SnowConvert free?

Snowflake's pricing page lists free code conversion tools, and the documentation says SnowConvert AI use is subject to the Conversion Software Terms of Use. Loads, tests and parallel workloads on Snowflake still consume credits, and a partner may charge for its own accelerators.

Should we lift and shift or re-architect?

Snowflake's guide describes three approaches: lift and shift, modernization, and pragmatic lift, adjust and shift. It says lift and shift is generally the fastest and most cost-effective, and that many organizations underestimate a full redesign. That is the vendor's view. A workable compromise is to move stable reports as they are and redesign only the subject areas where the legacy model is the problem.

Can Snowflake's tools migrate ETL jobs and BI reports?

In part. For the sources in its support matrix, the AIM agent converts SSIS packages and Informatica workflows to dbt and repoints Power BI reports to Snowflake. Other ETL products and BI tools need manual or partner-led work, so check the matrix for your stack before scoping.

Sources

More in Snowflake Consultants

← Back to Insights