Snowflake to Databricks: what the migration actually costs you

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, CREATE TABLE ... USING DELTA, 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. FLATTEN, LATERAL FLATTEN, Snowflake's VARIANT 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. Snowflake and Spark disagree on enough edge cases that anything doing fiscal-calendar or session-window logic needs test coverage, not eyeballing. Clustering. Snowflake's automatic clustering has no direct equivalent. You choose Z-ordering or liquid clustering deliberately, per table, based on actual query predicates. dbt projects port more easily than people expect — adapter swap plus incremental strategy tuning — but BI semantic layers do not. Re-pointing a connection is not a migration; the metrics need re-validation against the old platform, number by number. Design Unity Catalog before you move anything Snowflake's role model does not map cleanly onto Unity Catalog's catalog.schema.table hierarchy, and trying to translate it mechanically produces a permission structure nobody can reason about. Do the design first — catalogs, schemas, group ownership, grant boundaries — and migrate into it. We've written up what the migration itself involves and how to run governance afterwards. Treat this as the one moment you can delete roles. Mature Snowflake estates accumulate roles the way filesystems accumulate temp files, and a migration is the only time you'll have political cover to not recreate them. Validate in three layers, then run in parallel Structural checks — row counts, column types, null distributions — catch the copy errors. Semantic checks — aggregates at several grains, not just the total — catch the logic errors. Financial checks mean regulatory and revenue figures matched exactly, because "close enough" on a restated number is a career event for someone in finance. Then run both platforms in parallel for your critical workloads, comparing outputs daily, for weeks rather than days. Parallel running is expensive and boring and it is the single control that keeps a migration from becoming an incident. Budget for the double bill explicitly so nobody has to justify it mid-project. The breakeven number, honestly Migration costs real money: engineering time, parallel running, retraining, and the conversion long tail that always overruns. Against that, savings depend entirely on workload mix. ML and exploratory workloads usually see meaningful reductions. Steady, predictable SQL reporting often lands at rough parity — Databricks compute isn't free, and a SQL Warehouse left running behaves exactly like a Snowflake warehouse left running. So model it per workload, not as a platform-level percentage. And model the cleanup: a large fraction of any mature estate is tables and jobs nobody consumes. Finding those in discovery and not migrating them is frequently a bigger saving than the platform switch itself. If you're scoping this, the cheapest useful step is a discovery pass — inventory, dependency map, credit consumption by workload, and an honest count of the stored procedures that will need hand conversion. Zephico is a Databricks Consulting Partner, and our certified engineers run that assessment as a fixed-scope engagement before anyone commits to a timeline. Talk to us if you'd rather know the number before the project starts than halfway through it. Originally published on the Zephico blog.