1/15

03 Nov 2026

Snowflake to Databricks Migration: Must You Move Everything?

No. A Snowflake-to-Databricks migration doesn't require moving everything on day one.

Organizations can migrate the workloads that benefit most from Databricks, keep selected workloads on Snowflake temporarily, or allow Databricks to read Snowflake data while the migration progresses.

The real decision is therefore not simply “How do we migrate Snowflake to Databricks?” It is “What should move, what should stay, and what should interoperate?”

That distinction matters because Snowflake tables, SQL, stored procedures, Snowpark code, Streams, Tasks, and Dynamic Tables do not all migrate in the same way. Databricks provides Lakehouse Federation and Iceberg interoperability for phased adoption, while Lakebridge can automate parts of assessment, SQL conversion, and reconciliation.

However, procedural logic, change-tracking pipelines, security rules, and business-critical results still require engineering validation.

The sections below explain the three migration paths, what moves in a Snowflake migration, how Snowflake components map to Databricks, what Lakebridge can and cannot automate, where results can differ, and how to plan a controlled migration.

Quick Summary

A Snowflake to Databricks migration can follow three paths: move everything, move part, or interoperate. Federation and Iceberg make phased adoption possible, but federation is read-only, and non-Iceberg Snowflake tables can still use Snowflake compute. The most significant migration effort is usually not copying tables, but converting procedural logic, Snowpark code, Streams and Tasks, Dynamic Tables, security policies, dependencies, and workloads where small semantic differences can affect results. Lakebridge can automate parts of discovery, analysis, SQL conversion, and reconciliation, but automation does not replace engineering review or business validation.

Key Takeaways

Moving everything is optional. Many organizations move selected workloads first and keep others on Snowflake for a period.
Federation is read-only. Databricks can read Snowflake through query or catalog federation, but writes continue in Snowflake.
Iceberg changes the cost path. Snowflake-managed Iceberg tables can be read from object storage with Databricks compute, while other tables still use Snowflake compute.
The risk is in the logic. Procedural code, Snowpark, Streams, Tasks, and Dynamic Tables need redesign, not a table copy.
Lakebridge helps, with limits. It covers profiling, analysis, SQL conversion, and reconciliation, but results still need engineering and business validation.
Parity needs evidence. Reconcile through at least one full business cycle before cutover.

Move Everything, Move Part, or Interoperate?

Before migrating a single workload, choose the migration path that matches the organization's long-term data strategy.

Approach	What Happens	Best When	Main Consideration
Move everything	Migrate tables, logic, pipelines, and consumers, then retire Snowflake	One platform is the strategic goal	Requires the broadest migration scope and parallel validation
Move part	Move selected workloads while other workloads remain on Snowflake	Engineering, streaming, ML, or other workloads have higher Databricks priority	Both platforms must be governed during the transition
Interoperate	Keep both platforms and share data through federation or open formats	Both platforms have a long-term role	Federation is read-only and may still involve Snowflake compute

For many enterprises, a phased version of move everything or move part is more practical than a big-bang migration.

The important point is that a migration does not have to be all or nothing.

Why Enterprises Consider Moving from Snowflake to Databricks

Snowflake remains a strong platform for SQL analytics and concurrent BI workloads. The case for Databricks becomes stronger when the data environment extends beyond traditional warehouse analytics into engineering, streaming, machine learning, and AI.

Databricks can bring these workloads closer together on governed lakehouse data. This can reduce fragmentation when engineering, analytics, and machine learning teams operate across separate platforms.

Open data formats are another consideration. Delta Lake and Apache Iceberg use open data and storage patterns that can allow multiple engines to work with data in cloud object storage. For organizations looking to reduce platform dependency or support multiple processing engines, this can be an important architectural consideration.

Databricks can also provide a development environment that fits Python-heavy engineering and data science teams through notebooks, Git-based workflows, and CI/CD practices.

Unity Catalog provides governance across supported data and AI assets, including access control, lineage, auditing, row-level controls, and column-level protections.

The decision, however, should remain workload-driven. Organizations dominated by highly concurrent SQL analytics may have a different business case from organizations whose primary growth is in engineering, streaming, machine learning, or AI.

What Moves in a Snowflake to Databricks Migration?

A Snowflake migration is not simply a table-copy exercise. A Snowflake estate typically contains data, SQL, procedural code, pipelines, security policies, and downstream consumers, and each layer requires a different migration approach.

Snowflake Asset	Typical Migration Treatment
Tables	Migrate to the target Delta or Iceberg architecture
Views	Convert SQL and validate results
Stored procedures	Convert or redesign procedural logic
UDFs	Map to appropriate Databricks SQL or Python logic
Snowpark	Refactor to appropriate Databricks/PySpark patterns
Snowpipe	Redesign ingestion
Streams	Redesign change tracking
Tasks	Rebuild orchestration and dependencies
Dynamic Tables	Redesign declarative or incremental processing
Security policies	Recreate target security controls
BI connections	Repoint and validate reports
Data sharing	Redesign using the appropriate sharing mechanism

Standard SQL and straightforward tables are generally easier to migrate. The harder work tends to show up in procedural code, incremental processing, task dependencies, security policies, Snowpark workloads, and business logic embedded in the Snowflake environment.

Reading Snowflake From Databricks: Federation and Iceberg

A migration does not necessarily require copying every Snowflake table before Databricks can access it.

Lakehouse Federation provides Databricks with governed, read-only access to external systems through Unity Catalog. For Snowflake, the important distinction is between query federation and catalog federation.

Query Federation

With query federation, Databricks pushes queries to Snowflake over JDBC. Data can therefore remain in Snowflake while Databricks accesses it without first creating a separate copy.

The trade-off is that the queries still use Snowflake compute. This makes query federation useful for early migration stages, select lookups, or workloads where immediate data movement isn't justified.

Catalog Federation for Snowflake-Managed Iceberg

Snowflake-managed Iceberg tables provide another option. Databricks can access these tables directly from object storage through catalog federation, using Databricks compute rather than relying on Snowflake compute for the data access path.

This makes Iceberg particularly relevant when an organization wants to reduce dependence on Snowflake compute while transitioning workloads.

Three details are important for planning.

Federation is read-only. DML and DDL against Snowflake through a foreign catalog are not supported, so writes continue in Snowflake until the workload is migrated.
Non-Iceberg Snowflake tables use the query-federation path. They do not automatically receive the same object-storage access model as Snowflake-managed Iceberg tables.
Federation is a transition mechanism, not necessarily the final architecture. It can help organizations move workloads in stages without migrating every dataset simultaneously.

Five Layers of a Snowflake Estate to Inventory

A reliable migration starts with inventory and dependency analysis, not immediate conversion.

Data and Storage

Inventory databases, schemas, tables, stages, VARIANT columns, historical data, transient tables, and any Time Travel retention requirements that genuinely need to be preserved.

Transient tables and staging objects are particularly important because they may feed downstream jobs even when they do not appear to be business-facing assets.

SQL and Procedural Logic

The inventory should include views, UDFs, stored procedures, Snowpark code, JavaScript procedures, Snowflake Scripting, and business rules embedded inside SQL.

This is often where migration complexity increases because procedural behavior cannot always be translated through simple SQL syntax conversion.

Pipelines and Orchestration

Snowpipe, Streams, Tasks, Task graphs, Dynamic Tables, Airflow workflows, dbt jobs, and external orchestration should be mapped together.

A Stream may appear to be a standalone object, but a Task may depend on its offset or processing state. Understand those dependencies before rebuilding the pipeline.

Security and Governance

Role hierarchies, row access policies, masking policies, secure views, tags, and inherited permissions should be included in the assessment.

Redesign security as part of the migration rather than treating it as a post-migration activity.

Consumers and Sharing

BI dashboards, applications, APIs, external partners, data shares, Marketplace dependencies, and downstream systems must also be identified.

Moving the underlying data without repointing and validating its consumers does not constitute a complete migration.

How Snowflake Components Map to Databricks

The migration primarily maps Snowflake behavior and business intent to the Databricks architecture rather than replacing object names one for one.

Snowflake Component	Common Challenge	Databricks Migration Approach
SQL	Function and syntax differences	Convert SQL and validate results
VARIANT	Semi-structured JSON and path expressions	Map to appropriate VARIANT, STRUCT, ARRAY, or MAP structures
Stored procedures	Control flow, dynamic SQL, and transactions	Convert simple logic to SQL and refactor complex logic where required
UDFs	Different execution models	Map to SQL or Python functions
Snowpark	Snowflake-specific APIs	Refactor to appropriate PySpark/Databricks patterns
Snowpipe	Snowflake-specific ingestion	Redesign using Databricks ingestion capabilities
Streams	Change-tracking offsets	Use Change Data Feed or appropriate streaming patterns
Tasks	Scheduling and dependencies	Rebuild using Lakeflow Jobs and explicit dependencies
Dynamic Tables	Declarative refresh and incremental processing	Redesign using appropriate materialized-view or streaming-table patterns
Time Travel	Historical access and recovery	Use Delta time travel with defined retention
Cloning	Test and recovery environments	Use appropriate Delta clone patterns
Security policies	Different roles and policy models	Redesign using Unity Catalog
Data sharing	Snowflake-specific sharing model	Redesign using appropriate sharing capabilities
Compute	Snowflake credit model	Benchmark Databricks compute separately

Reports and dashboards also need to be included in the migration wave. Repointing a BI connection without validating the resulting metrics can leave technically migrated data with incorrect business reporting.

Can Lakebridge Automate a Snowflake to Databricks Migration?

Partly. Lakebridge can automate much of the assessment, conversion, and reconciliation, but it does not eliminate engineering validation.

Lakebridge is a Databricks migration toolkit with components designed for different stages of migration.

Lakebridge Component	Snowflake Use	What Still Needs Engineering
Profiler	Measures workload size, usage, and cost drivers	Deciding what to retire and how to sequence migration waves
Analyzer	Inventories SQL and assesses complexity	Turning analysis into a practical conversion plan
Morpheus converter	Converts Snowflake SQL to Databricks SQL	Semantic and business validation
Switch	Experimental LLM-based conversion option	Review and reconciliation of generated output
Reconcile	Compares source and target data	Defining business-critical validation criteria

Lakebridge can substantially reduce repetitive migration effort, but complex stored procedures, Snowpark applications, Streams and Task dependencies, security redesign, semantic differences, BI validation, and business sign-off still require engineering involvement.

The practical model is:

Automate repetitive conversion → review complex logic → reconcile results → validate with the business.

Worked Example: Snowflake Streams and Tasks to Databricks

Streams and Tasks illustrate why a Snowflake migration involves more than SQL conversion.

A typical Snowflake pipeline may follow this pattern:

Source table → Stream captures changes → Task processes changes → Target table

A Databricks implementation may instead use:

Source → Change Data Feed or streaming ingestion → Transformation → Databricks workflow

A concrete version of that pattern follows. This is an illustrative example, not a client engagement.

Snowflake

CREATE OR REPLACE STREAM raw.orders_stream ON TABLE raw.orders;

CREATE OR REPLACE TASK etl.merge_orders
  WAREHOUSE = etl_wh
  SCHEDULE = '15 MINUTE'
WHEN SYSTEM$STREAM_HAS_DATA('raw.orders_stream')
AS MERGE INTO silver.orders t USING (
  SELECT order_id, status, amount
  FROM raw.orders_stream
  WHERE METADATA$ACTION = 'INSERT'
) s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.status = s.status, t.amount = s.amount
WHEN NOT MATCHED THEN INSERT (order_id, status, amount)
  VALUES (s.order_id, s.status, s.amount);

Databricks SQL, run by a Lakeflow Job every 15 minutes

-- raw.orders has delta.enableChangeDataFeed = true
MERGE INTO silver.orders AS t
USING (
  SELECT order_id, status, amount
  FROM table_changes('raw.orders', :last_version)
  WHERE _change_type IN ('insert', 'update_postimage')
) AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET t.status = s.status, t.amount = s.amount
WHEN NOT MATCHED THEN INSERT (order_id, status, amount)
  VALUES (s.order_id, s.status, s.amount);

The key difference is state. A Snowflake Stream remembers what it has already delivered, but table_changes reads from a version you supply, so the job must store the last processed version and pass it in on the next run. A streaming table in a declarative pipeline handles that checkpointing for you, which is usually the better target for new pipelines. If a table can receive updates, decide whether the original logic meant to process them, because the filter above keeps inserts and the post-update row images. Please test this example in a Databricks workspace before adapting it.

The objective is not to reproduce the Snowflake object names. It is to preserve the intended business behavior.

The migration should therefore establish how changes are captured, how processing positions are tracked, how dependencies are handled, what happens when processing fails, how late-arriving data is handled, and how duplicate records are controlled.

A pipeline is considered successfully migrated only when its resulting business output matches the required behavior.

Where Snowflake and Databricks Results Can Differ

A migration can be technically successful while still producing different business results.

Small differences in SQL behavior, data types, ordering, timestamps, or incremental processing can affect reports and downstream applications.

Snowflake Behavior	Potential Databricks Difference	Safeguard
NULLs sort last in ascending order by default	Spark sorts NULLs first in ascending order by default	Explicitly define NULL ordering
FLOAT uses 64-bit double precision	Databricks FLOAT is 32-bit	Map types deliberately and reconcile numeric columns
NUMBER uses defined precision and scale	Decimal and division behavior can differ	Define explicit DECIMAL precision and scale
TIMESTAMP_NTZ, LTZ, and TZ types	Timestamp behavior differs between platforms	Map timestamp types deliberately and define the session time zone
Unquoted identifiers are stored in uppercase	Identifier casing can differ	Standardize naming and test dependent objects
Streams track offsets automatically	Change Data Feed requires explicit version or checkpoint handling	Define checkpoint and version management

These differences are why row counts alone are not enough.

Validation should compare not only record counts but also aggregates, checksums, null counts, duplicate counts, key relationships, business calculations, pipeline outputs, and critical BI results.

For important workloads, reconciliation should continue through a full business cycle, such as month-end processing, before production cutover.

A 7-Phase Snowflake to Databricks Migration Plan

Phase 1: Discover

Profile the Snowflake estate, including databases, tables, views, procedures, UDFs, Snowpark code, Streams, Tasks, Dynamic Tables, shares, and downstream consumers.

The output should be a scored inventory that identifies complexity, usage, dependencies, and migration priorities.

Phase 2: Rationalize

Remove obsolete tables, views, tasks, pipelines, and dashboards before migration. Determine how much historical data genuinely needs to move and identify duplicate workloads.

The objective is to migrate the required estate rather than reproducing unnecessary technical debt.

Phase 3: Design

Choose whether the program will move everything, move selected workloads, or interoperate.

Then define the target data architecture, Unity Catalog structure, storage model, compute strategy, identity mapping, security model, and migration waves.

Phase 4: Pilot

Select a visible but relatively low-risk workload and migrate it through the entire process.

The pilot should establish realistic conversion effort, performance, cost, data parity, pipeline behavior, and business acceptance before larger waves begin.

Phase 5: Convert

Migrate the required data and convert SQL, stored procedures, Snowpark code, pipelines, security controls, and dependent workloads.

Use automation wherever the conversion is repeatable, and subject complex business logic to additional engineering review.

Phase 6: Validate and Parallel Run

Run the source and target environments together long enough to establish confidence.

Reconcile row counts, aggregates, checksums, business calculations, pipeline outputs, and critical BI reports. A complete business cycle provides stronger evidence than a one-time technical comparison.

Phase 7: Cut Over and Decommission

Once the target environment has passed validation, repoint BI tools, applications, and pipelines.

Maintain the Snowflake environment for rollback until production sign-off is complete. Only then should unnecessary Snowflake warehouses, storage, and dependencies be retired.

Best Practices for a Low-Risk Migration

Decide the migration path before starting conversion. Move everything, move part, and interoperate require different architectures and operating models.
Rationalize before migrating. Converting objects that are no longer used adds little value.
Design Unity Catalog before loading production data. Establish governance, permissions, storage locations, and identity mapping before migration waves begin.
Treat federation as a transition strategy. Understand its read-only limitations, query behavior, Snowflake compute implications, and Iceberg requirements before using it at scale.
Start with a representative workload. A good pilot should include enough real complexity to surface migration issues without unnecessarily risking a critical production workload.
Make semantic differences explicit. NULL ordering, numeric precision, timestamps, identifier casing, and incremental processing should be tested deliberately.
Automate reconciliation. Source-to-target validation should run repeatedly during the parallel period rather than only at final cutover.
Version migration assets. SQL, notebooks, pipeline definitions, configuration, infrastructure code, and test scripts should be maintained in version control.
Benchmark real workloads. Do not assume Snowflake credit consumption translates directly into Databricks cost. Compare representative workloads using the proposed target architecture.

How Long Does a Snowflake to Databricks Migration Take?

There is no universal migration timeline.

The effort depends on the size of the Snowflake estate, SQL complexity, stored procedures, Snowpark usage, Streams and Tasks, Dynamic Tables, data volume, pipeline dependencies, security requirements, BI dependencies, migration strategy, and required parallel-run period.

A SQL-focused environment can have a very different migration profile from an enterprise Snowflake estate containing complex procedural workloads, hundreds of pipelines, and numerous downstream consumers.

The most reliable way to estimate the effort is to profile, classify, and rationalize the estate before committing to a migration timeline.

Frequently Asked Questions

How do you migrate from Snowflake to Databricks?

Start by inventorying and rationalizing the Snowflake estate. Then choose whether to move everything, move selected workloads, or interoperate. Design the Databricks architecture, migrate data, convert SQL and procedural logic, rebuild pipelines, validate results against Snowflake, and cut over in a controlled manner.

Do you have to move everything off Snowflake?

No. Organizations can move engineering, streaming, ML, or selected workloads first while keeping other workloads on Snowflake. Databricks can also access Snowflake data through read-only federation during a phased migration.

Can Databricks query Snowflake data without copying it?

Yes, with read-only access. Query federation can push queries to Snowflake over JDBC, while catalog federation can access Snowflake-managed Iceberg tables from object storage using Databricks compute.

Can Lakebridge convert Snowflake SQL?

Yes, partly. Lakebridge includes Snowflake profiling, analysis, SQL conversion, and reconciliation capabilities. Converted SQL still needs semantic and business validation, particularly when workloads contain procedural logic or Snowflake-specific behavior.

Is Databricks cheaper than Snowflake?

It depends on the workload. Cost varies according to compute requirements, workload patterns, concurrency, data architecture, and governance. Benchmark representative workloads before making a cost-based migration decision.

Scope Your Snowflake to Databricks Migration With DataTerrain

Moving off Snowflake is easy to start and hard to finish.

Complexity often lies in procedural logic, change-tracking pipelines, dependencies, security rules, and the business numbers that must still match after conversion.

DataTerrain helps enterprises assess complex data environments, identify migration dependencies, convert SQL and data pipelines, and validate results against source systems.

Instead of committing to a full migration before understanding the estate, start with a representative workload to determine what can be automated, what needs redesign, what should remain temporarily, and where validation is required.

DataTerrain brings 17+ years of experience and 400+ clients in data and reporting modernization.

Request a Free Proof of Concept

Contents