Snowflake to Databricks Migration: A Step-by-Step Cutover Plan

Before You Read On

A Snowflake to Databricks migration is a controlled move of tables, SQL, pipelines and permissions from Snowflake into a governed Databricks lakehouse. The work is mostly discovery and validation, not copying data. Plan for an inventory, automated SQL conversion with manual review, a parallel run with reconciliation, and a cutover one domain at a time.

• Cost: you trade Snowflake credits for Databricks DBUs plus a separate cloud infrastructure bill, so model both lines before you commit.
• Effort: discovery of undocumented stored procedures and hardcoded references takes longer than moving the data.
• Risk: a big-bang switch is the main failure mode; a domain-by-domain cutover with a rollback path contains it.
• Fit: it pays when you want data engineering, machine learning and BI on one platform under Unity Catalog.

Most teams do not leave Snowflake because the warehouse failed. They leave because the work around it multiplied: an ingestion tool, a transformation tool, a scheduler, a separate ML stack and a pile of glue code. Fivetran’s 2026 enterprise infrastructure benchmark found that 53% of engineering capacity goes to pipeline maintenance rather than new capability.

The destination has matured to meet them. Databricks reported in its December 2025 Series L announcement that its Data Warehousing product passed $1 billion in annual revenue run-rate. In plain terms, Databricks SQL is now a warehouse people bet production on, not a side feature of a Spark platform.

The hard part is not the destination. It is the hundreds of small dependencies nobody wrote down: a stored procedure one analyst owns, a dashboard that points at a schema by name, a task chain that runs at 2 a.m. and feeds finance. This plan is built to find those before they find you.

Why a Snowflake to Databricks Migration Is a Process Problem First

I run migrations the way I run any Lean Six Sigma project. You map the current state before you touch it. Moving a broken workflow to a faster engine just produces the wrong numbers sooner.

That is the Assess step of our AIM-IT method: Assess, Innovate, Model, Implement, Track. For a warehouse move, Assess means a complete inventory of objects, jobs, consumers and owners. Innovate means deciding what to retire instead of migrate. Model is the target lakehouse design. Implement is the conversion and cutover. Track is reconciliation and cost monitoring after go-live.

A practitioner field report on the Databricks Community forum, published in February 2025, makes the same point from the trenches. The author describes finding more than 100 hardcoded Snowflake references in production jobs and says the team ended up spending half of its migration time on discovery and impact analysis. That ratio sounds excessive until you have lived through a cutover without it.

How Snowflake Objects Map to the Databricks Lakehouse

Before converting anything, agree on where each Snowflake concept lands. The table below is the mapping we start from. It is a starting point for design review, not a promise that every object converts one to one.

If your current design is a flat set of schemas, this is the moment to introduce a medallion architecture: bronze for raw landings, silver for conformed entities, gold for the views your BI tools read. It is far cheaper to impose that structure during the move than after it.

The Step-by-Step Cutover Plan

These steps run in order for each domain (finance, sales, operations and so on). You repeat steps 4 through 8 per domain, which keeps any single cutover small enough to roll back.

1. Inventory everything. Pull the full list of databases, schemas, tables, views, stored procedures, UDFs, tasks, pipes and grants. Join it to query history so you know which objects are actually used, by whom and how often.
2. Retire before you migrate. Objects with no reads in 90 days go on a retirement list with a named owner who signs off. Every table you retire is one you never have to convert, validate or pay for.
3. Design the target lakehouse. Define catalogs, schemas, the medallion layers, naming standards and the Unity Catalog grant model. Decide which workloads get serverless SQL warehouses and which get job compute.
4. Run automated conversion. Lakebridge is a free Databricks Labs toolkit, announced in June 2025, with an analyzer, a converter and a reconciliation validator. Databricks names Snowflake, Teradata, Oracle and SQL Server among the more than ten warehouses and ETL tools it covers. Databricks says it automates up to 80% of migration tasks. Treat the other 20% as the real schedule.
5. Review converted code by hand. Procedural stored procedures, JavaScript UDFs and anything using Snowflake-specific functions need an engineer to read the output. A transpiler that finishes without errors has not proven the logic is equivalent.
6. Move the data. Unload historical tables to cloud storage in Parquet and ingest them into Delta tables in bronze. Stand up incremental loads with Auto Loader or Lakeflow Connect so new data keeps flowing into the lakehouse during the parallel run.
7. Run both platforms in parallel. Lakehouse Federation lets you register Snowflake as a read-only foreign catalog in Unity Catalog. You can then compare Snowflake and Databricks outputs from one SQL editor: row counts, column sums, hash totals and the top business KPIs.
8. Cut over one domain. Repoint BI connections and downstream consumers, freeze writes to the Snowflake version, and keep it readable for an agreed rollback window. Only then decommission.

What Goes Wrong in Real Snowflake Migrations

These failure modes compound. The first one causes most of the others, which is why the order matters.

1. Undocumented logic surfaces late. Stored procedures written by one person, often outside any repository, appear only when a report breaks after cutover. Query history and object-level lineage are the only reliable way to find them early.
2. Hardcoded names break downstream jobs. Every fully qualified Snowflake reference in a Python script, a dbt model or a BI extract is a future failure once names change to Unity Catalog’s three-level form. Search code repositories and BI metadata, not just the warehouse.
3. Converted SQL that runs but disagrees. Differences in null handling, implicit casting, date functions and semi-structured path syntax produce answers that look plausible and are wrong. Only reconciliation against the source catches this.
4. Cost surprises in the first month. Snowflake credits bundle compute you never had to size. On Databricks you pay DBUs plus a separate cloud bill for compute, storage and networking. Warehouses left running without auto-stop turn a savings case into an overrun.
5. Permissions rebuilt from scratch. Snowflake row access and masking policies do not convert automatically. If you rebuild them late, you either delay go-live or ship with access that is wider than it should be.

None of these are exotic. Each is a process gap that shows up as a technical symptom. Fix the inventory and ownership first, and most of the list shrinks.

Validation: How You Know the Numbers Match

Reconciliation is the step teams most often cut when the schedule slips, and it is the step that protects your credibility with finance. Build it as a repeatable job, not a one-time spreadsheet.

For every migrated table, compare row counts, null counts per column, sums of numeric measures and a hash of key columns. For every gold view that feeds a dashboard, compare the headline KPIs for the same date range on both platforms. Record every mismatch with an owner and a resolution, then rerun until the list is empty for an agreed number of cycles.

Schedule these checks in Lakeflow Jobs during the parallel run so they run after each load, not when someone remembers. When a domain passes for several consecutive cycles, it is ready for cutover. If you are still deciding whether the move is worth it at all, our Databricks vs Snowflake comparison covers the platform trade-offs, and our guide to warehouse to lakehouse migration covers the wider pattern.

Your First 90 Days on the Migration

This is the order we run a first domain in. It assumes a mid-market team with one or two data engineers on the work and a business owner who can sign off numbers.

Weeks 1 to 2: Inventory and decisions

Export the object inventory and join it to query history. Build the retirement list and get owners to sign it. Pick the first domain: meaningful enough to prove value, small enough to roll back. Agree the Unity Catalog naming standard and the grant model before anyone creates a table.

Weeks 3 to 6: Convert and load

Run Lakebridge analysis and conversion on the first domain’s SQL. Review procedural code by hand. Land historical data in bronze, build silver and gold with Lakeflow Declarative Pipelines, and turn on incremental loads. Register Snowflake through Lakehouse Federation so the parallel comparison is ready the day data lands.

Weeks 7 to 12: Parallel run and cutover

Run reconciliation after every load. Fix mismatches at the source of the logic, not with patches in gold. Once the domain passes for the agreed number of cycles, repoint BI and downstream consumers, hold the Snowflake copy read-only through the rollback window, then decommission it. Capture what slowed you down and apply it to domain two.

If you want a second set of eyes on the inventory or the cutover plan, our Databricks consulting team runs this exact sequence, starting with the process map rather than the code.

Frequently Asked Questions (FAQs)

How long does a Snowflake to Databricks migration take?

It depends on the number of objects in active use and how much procedural logic you carry. A single domain following the plan above fits in roughly 90 days. A full estate is a series of those cycles, and discovery usually takes longer than the data movement.

Is Lakebridge free, and will it convert all of our SQL?

Databricks describes Lakebridge as free for Databricks customers and partners. It is a Databricks Labs toolkit, not a fully supported core product. Databricks claims up to 80% automation of migration tasks, so plan engineering time for the remainder, especially stored procedures.

Can we run Snowflake and Databricks side by side during the migration?

Yes. Lakehouse Federation lets Databricks query Snowflake through a read-only foreign catalog in Unity Catalog. That makes it practical to compare outputs from both platforms during a parallel run before you cut over each domain.

Will moving to Databricks lower our costs?

Not automatically. You swap Snowflake credits for Databricks DBUs plus a separate cloud infrastructure bill. Savings come from right-sized SQL warehouses, auto-stop settings, retiring unused objects and consolidating tools, so build a cost baseline before and after cutover.

What should we migrate first?

Start with a domain that matters to the business but can tolerate a short rollback. Avoid the most critical financial reporting in the first cycle. The lessons from domain one make every later domain faster and safer.