Most teams underestimate the gap between what runs on Snowflake and what runs cleanly on Databricks. The SQL is portable; the operational model isn't.
What ports cleanly
Most analytical SQL — joins, window functions, aggregations — moves with little change once you align on the SQL dialect. dbt models port over with mostly-mechanical updates. Star-schema dimensional models are unchanged. If your transformation logic is in dbt, you're already most of the way there.
What needs rewriting
Anything that depends on Snowflake-specific features (Streams, Tasks, Snowpipe, Search Optimization Service) needs a Databricks-native equivalent. Streams become Auto Loader or Delta Live Tables. Tasks become Databricks Workflows. The substitutions exist — but they're not drop-in, and the operational characteristics differ.
Where teams burn time
- Permission models. Snowflake's role hierarchy and Databricks Unity Catalog grants don't map 1:1. Plan a separate phase for governance.
- Cost tuning. Compute is priced and scaled differently. The pattern that was cheap on Snowflake might not be cheap on Databricks (and vice versa).
- Cluster sizing. Going from "warehouse size" to "node type and autoscale range" is a learning curve for analysts.
- Stored procedures and UDFs. These rarely port cleanly. Plan to rewrite them.
What we'd do differently
Run the two platforms in parallel for at least one full reporting cycle before cutover. The bugs you'll catch are the ones nobody anticipated — usually around timezone handling, type coercion, or null semantics. Don't skip the parallel run to save time; you'll spend the savings five times over reconciling production discrepancies later.