Most Snowflake-to-Databricks migrations get sold on cost and delivered on something else.
The credit line item is what gets the project funded, but the teams that finish happy are usually the ones that moved for a different reason: they wanted ML, streaming and GenAI workloads living next to the analytics data instead of shuttling between two platforms.
If your only justification is the bill, read the breakeven section below before you commit — the honest number is longer than the deck says.
We're a Databricks shop, and we've written elsewhere about how to choose between the two platforms if you haven't committed yet.
This post assumes you have.
What actually changes underneath The two platforms look similar from a SQL console and are structurally different behind it.
The mapping worth internalising before planning anything: Layer Snowflake Databricks Storage Proprietary micro-partitions inside Snowflake Delta Lake files in your own S3/ADLS/GCS bucket Compute Virtual warehouses, T-shirt sized Job clusters, all-purpose clusters, SQL Warehouses, Photon Governance Role hierarchy, row access policies, masking policies Unity Catalog across tables, models, notebooks, dashboards Sharing Secure Data Sharing Delta Sharing (open protocol) Billing unit Credits DBUs, priced differently per compute type The storage row is the one with the most downstream consequences.
On Snowflake, storage and compute are separate line items on the same bill; on Databricks, storage is your cloud provider's problem and your cloud provider's invoice.
That's a genuine benefit — the data stays readable by other engines — but it also means your "Databricks cost" and your "data platform cost" stop being the same number, and finance needs to know that before the first invoice arrives.
Pick a strategy before you pick a tool Three patterns, and the choice determines everything after it: Lift-and-shift.
Replicate schemas one-to-one, translate the SQL, cut over.
Fastest, and it faithfully preserves every design compromise you made in Snowflake — including the ones you made because Snowflake billed you that way.
Defensible when a contract is expiring and the calendar is the constraint.
Re-platform.
Translate the schema into a medallion structure, keep the business logic, redesign the layout.
This is where most estates should land: you get Delta's file layout, liquid clustering and Photon working for you rather than inheriting a shape that fought them.
Re-architect.
Rebuild the pipelines around Databricks-native patterns — streaming ingestion, Delta Live Tables, jobs instead of tasks.
Longest timeline, best economics on the far side, and only realistic if the team is being funded for a platform program rather than a migration ticket.
The mistake is choosing lift-and-shift for speed and then expecting re-architect savings.
Snowflake-shaped tables on Databricks compute cost what Snowflake-shaped tables cost.
The effort lives in the SQL, not the data Copying the data is a solved problem.
Bulk export to Parquet, land it in object storage, , validate.
For a large estate it's a scheduling exercise, not an engineering one — and Lakehouse Federation lets you query Snowflake in place while you sequence it, which is worth using as a bridge rather than as a destination.
The code is where the schedule goes.
Automated converters — Databricks' own tooling, BladeBridge, the assistant — will get you most of the way through straightforward SQL.
What they don't handle is the long tail, and the long tail is disproportionate: JavaScript stored procedures have no Databricks equivalent.
They get rewritten as PySpark or SQL scripting, by hand, by someone who understands what they were doing.
If you have dozens of these, that's your critical path.
Semi-structured handling. , , Snowflake's semantics and its particular null-handling in JSON paths all need deliberate translation.
The queries usually run after conversion; they just quietly return different rows.
Timezone and date arithmetic.
Snow