Moving from Snowflake to Databricks is rarely a simple data-copying project. The tables may be the most visible part of the environment, but they are only one part of what keeps it running. SQL logic, pipelines, security policies, BI tools, applications, schedules, and support processes all have to be accounted for.
That is where migration plans often fall short. A query may need rewriting for Databricks SQL, a Snowflake role structure may not belong in Unity Catalog, and query history may show that an apparently important table is no longer used.
This guide walks through the migration in the order most teams need to tackle it: understand the existing estate, decide what should move, design the Databricks environment, migrate and convert the workloads, validate the results, and cut over without losing the option to roll back.
Why Are Companies Moving from Snowflake to Databricks?
The strongest reason to migrate is not that one platform is universally better. It is that the organization has a specific problem Databricks is better positioned to solve.
For some US companies, that problem is platform sprawl. Bringing analytics, engineering, streaming, data science, and AI workloads closer to the same governed data can simplify how teams build and operate them.
Other common goals include:
- Using open table formats and cloud object storage
- Standardizing batch and streaming pipelines
- Bringing analytics and machine learning workflows onto one platform
- Centralizing access control, lineage, and auditing
- Reducing duplicated data and disconnected engineering processes
None of these goals automatically justifies a migration. If Snowflake reliably supports the company's core analytics workloads and there is no clear operational, architectural, or financial benefit to moving, staying put may be the better decision.
If your team is still choosing a platform, start with a broader Databricks vs. Snowflake comparison. Migration planning should begin only after the business case is clear.
What Should You Assess Before the Migration?
Before moving anything, build a dependency-aware inventory of the Snowflake estate. A spreadsheet containing databases, schemas, and table names is useful, but it does not tell you which processes will break when a table moves.
Your assessment should cover:
- Databases, schemas, tables, views, and materialized views
- Dynamic tables, streams, and tasks
- Stored procedures and user-defined functions
- Snowpark applications and libraries
- Roles, grants, masking policies, and row-access policies
- Internal and external stages
- Shares, integrations, and external functions
- dbt models, macros, tests, and packages
- ETL tools, schedulers, and CI/CD pipelines
- BI dashboards, semantic models, and extracts
- Applications and services that query Snowflake
- Query frequency, service-level requirements, and compute usage
For every material asset, record its owner, business purpose, upstream source, downstream consumer, schedule, and failure impact.
Query history often changes the scope. It can reveal duplicate pipelines, dormant reports, and objects that still exist but no longer serve a business purpose. Retiring those workloads is usually more valuable than faithfully rebuilding them on a new platform.
The assessment is finished when the dependencies are understood and every workload has a decision; not when a list of objects has merely been exported.
Map Snowflake Components to Databricks
Snowflake and Databricks solve many of the same problems, but their features do not always line up one for one. Use the following table as a planning aid, not as an automatic conversion map.
| Snowflake component | Possible Databricks destination | What to review |
|---|---|---|
| Tables | Delta tables | Data types, precision, partitioning, and load design |
| Views | Databricks SQL views | Syntax and semantic differences |
| Materialized views | Materialized views or redesigned pipelines | Refresh behavior and workload fit |
| Dynamic tables | Lakeflow Spark Declarative Pipelines or jobs | Dependencies and refresh requirements |
| Streams and tasks | Structured Streaming, Lakeflow Jobs, or pipelines | State, scheduling, retries, and recovery |
| Roles and grants | Unity Catalog privileges and account groups | Ownership and privilege inheritance |
| Stored procedures and UDFs | Databricks SQL, Python, Scala, or jobs | Procedural logic and runtime compatibility |
| Snowpark workloads | Spark or Databricks-native applications | API, library, and execution differences |
| BI connections | Databricks SQL warehouses | Drivers, authentication, concurrency, and query behavior |
A simple scheduled task may convert with limited effort. A workflow that combines tasks, streams, stored procedures, and external functions probably will not. That distinction should shape the migration schedule and estimate from the beginning.
Choose a Migration Approach
Most migrations follow one of three patterns.
Big-bang cutover
The organization moves most workloads during one release. This can work for an isolated environment, but it concentrates risk in one window.
Phased migration
Workloads move by domain, data product, or dependency group. The team validates one wave before starting the next. For a production estate with many dashboards, applications, and governance requirements, this is usually the most practical option.
Temporary coexistence
Snowflake and Databricks run side by side while workloads are moved and checked. Databricks supports query federation with Snowflake, which can help teams access data that has not moved yet.
Coexistence buys time, but operating two platforms complicates cost, identity, monitoring, and reconciliation. Give this phase an owner, an end date, and clear exit conditions.
How to Migrate from Snowflake to Databricks
1. Agree on what success looks like
Start with the reason for moving and turn it into measures the team can test. Capture the current baseline for pipeline reliability, data freshness, query performance, concurrency, dashboard availability, recovery time, and platform consumption.
Define which domains are included, what remains in Snowflake, what comes later, and who can approve or stop a cutover.
This prevents engineering from declaring completion before the business agrees the environment is production-ready.
2. Give every workload a treatment
Do not assume that everything should be converted. Place each workload into one of five groups:
- Retire: It is unused, duplicated, or no longer valuable.
- Retain: It should stay in Snowflake because moving it adds cost or risk without enough benefit.
- Directly convert: It can move with limited changes.
- Refactor: It needs code or configuration changes but will keep the same business purpose.
- Redesign: Its current architecture does not translate cleanly or is no longer the right approach.
Consider business importance, complexity, volume, security, dependencies, and recovery needs. Choose a pilot meaningful enough to expose real issues without putting a critical operation at risk.
3. Design the Databricks environment
Decide how the target environment will be organized before loading production data.
Key decisions include:
- Cloud provider and region
- Object-storage design and Delta table structure
- Catalog and schema organization
- Development, test, and production separation
- Compute policies and SQL warehouses
- Pipeline and job orchestration
- Secrets, service principals, and CI/CD
- Monitoring, alerting, backup, and recovery ownership
Location matters, especially for US organizations operating across regions or clouds. Snowflake notes that moving data to another region or cloud may incur transfer charges; cloud-provider charges may apply as well. Review the Snowflake data-transfer guidance before selecting a route.
4. Rebuild governance in Unity Catalog
Snowflake roles should not simply be copied and renamed in Databricks. Unity Catalog has its own hierarchy, inheritance behavior, ownership model, and administrative boundaries.
Design the new model around account-level groups, catalogs, schemas, workspace bindings, service principals, storage credentials, row filters, column masks, lineage, and audit requirements. For companies handling financial, healthcare, customer, or other regulated data, this work should happen early, not during the final week of cutover.
Databricks' Unity Catalog best practices provide a useful starting point. Test the design with real user roles and service identities. Confirm that people can access what they need and, just as importantly, cannot access what they should not.
5. Move historical and changing data
A common approach is to unload data from Snowflake into cloud object storage and then load it into Delta tables.
Snowflake supports COPY INTO <location> for unloading tables or query results into files, including partitioned and multi-file exports. Its data-unloading documentation explains the available patterns.
On the Databricks side, COPY INTO can load files into Delta tables. Databricks describes the command as idempotent because repeated runs load only new data. For larger or continuously arriving datasets, a streaming or managed pipeline may be a better fit. See the Databricks COPY INTO documentation for current behavior and supported options.
Plan separately for historical backfill and incremental changes. Review decimal precision, timestamps, nulls, file sizes, partitioning, encryption, schema evolution, and failed-load recovery.
Before moving on, reconcile counts, aggregates, checksums, or other agreed controls. "The job completed" is not proof that the right data arrived.
6. Convert SQL, procedures, and pipelines
Valid SQL is not necessarily equivalent SQL. Functions, casting rules, identifiers, timestamps, null handling, recursive CTEs, lateral operations, and numeric precision can all change the result.
Lakebridge can help assess workloads, translate SQL, and reconcile data. It is an accelerator, not a substitute for engineering review. Lakebridge is a Databricks Labs project provided without a formal service-level agreement, as stated in its Lakebridge repository.
Review Snowflake queries and views, dbt models, stored procedures, UDFs, dynamic tables, streams, tasks, Snowpark applications, and external integrations. Test whether the code returns the right business result, not only whether it runs. A revenue dashboard that executes successfully but reports the wrong number is still a failed migration.
7. Reconnect everything around the data
Once the data and transformation logic work, reconnect the systems that depend on them. That may mean replacing drivers and connection strings, configuring authentication, rebuilding schedules, updating secrets, reconnecting BI semantic models, refreshing extracts, revising application queries, and changing CI/CD pipelines.
Test dashboard filters, exports, scheduled reports, parameterized queries, timeouts, concurrency, and application error handling. A green connection test covers only a small part of the risk.
8. Run Snowflake and Databricks in parallel
Compare important workloads over their normal operating cycle. A daily pipeline may need several clean runs; month-end reporting may need a full close.
Compare row counts, null patterns, aggregates, business KPIs, timestamps, freshness, permissions, dashboard behavior, runtime, concurrency, failures, recovery, and platform consumption.
Engineering teams can confirm technical consistency, but business owners should approve the numbers they use to make decisions. Keep a reconciliation record showing every difference, its cause, how it was resolved, and who approved it.
9. Cut over without removing the safety net
The cutover plan should define the change freeze, final incremental load, consumer order, monitoring owners, and rollback authority.
Define rollback triggers before the release. Examples may include a failed critical pipeline, material KPI differences, incorrect permissions, broken downstream applications, or performance below the approved baseline.
Keep the previous production path available during a defined stabilization period. Shutting down Snowflake immediately after redirecting users removes the fastest recovery option when the risk is still highest.
10. Optimize, then decommission
After cutover, review query plans, compute size, table design, schedules, concurrency, maintenance, and actual consumption.
Once the workload is stable, remove temporary synchronization jobs, archive the required migration evidence, update runbooks and ownership, and verify that no consumer still points to Snowflake. Decommission Snowflake objects in stages rather than deleting the whole environment at once.
Cutover Validation Scorecard
Use the same scorecard for every migration wave so the go/no-go decision is based on evidence rather than release pressure.
| Area | Question to answer before cutover |
|---|---|
| Data | Do approved counts and reconciliation checks match? |
| Business logic | Do reports show the expected KPI values? |
| Freshness | Are ingestion and reporting SLAs being met? |
| Security | Do users and services have exactly the intended access? |
| Performance | Does the workload meet its approved baseline? |
| Compatibility | Do BI tools and applications behave correctly? |
| Operations | Are monitoring, alerting, and recovery procedures active? |
| Cost | Has actual consumption been compared with the baseline? |
| Rollback | Can the previous production path be restored safely? |
| Approval | Have technical and business owners signed off? |
Decide in advance which checks are mandatory. A workload should not reach production simply because "most" of the boxes are green.
Common Migration Mistakes
- Looking only at tables: This misses applications, dashboards, tasks, security rules, and integrations. Map both upstream and downstream dependencies.
- Assuming converted SQL means matching results: Compare approved KPIs and business outputs, not just successful execution.
- Copying the existing access model: Design Unity Catalog around the target operating model and test positive and negative access cases.
- Migrating unused assets: Use query history and owner confirmation to remove obsolete workloads from scope.
- Ignoring transfer and coexistence costs: Include network, cloud storage, staging, and the period when both platforms are active.
- Treating automated conversion as finished code: Review, test, and monitor everything generated by a conversion tool.
- Cutting over too much at once: Move by domain or dependency group and learn from each wave.
- Decommissioning Snowflake too early: Keep a rollback route until the new workload has passed its stabilization period.
Who Should Be Involved?
The team usually needs a migration architect, data and Databricks engineers, a SQL or analytics engineer, security and governance ownership, BI or application owners, QA support, and business-domain approvers. The exact mix depends on how much logic must be rewritten and how many systems rely on the current environment.
After the inventory is complete, budget and feasibility questions become easier to answer. The supporting Snowflake to Databricks Migration Cost guide can help readers understand how workload complexity, remediation, data movement, parallel operation, and the delivery model affect the plan.
The people doing the work need more than general data-migration experience. They should be able to handle Delta architecture, SQL remediation, Unity Catalog, orchestration, reconciliation, and production cutover. If you are evaluating an outside team, use this guide on how to hire certified Databricks developers to assess practical capability as well as certifications.
Snowflake-to-Databricks Migration Checklist
Before the first production migration wave, confirm that:
- The business case, scope, owners, and success criteria are approved.
- Snowflake assets and their dependencies have been inventoried.
- Every workload has a treatment and migration wave.
- The target Databricks architecture is ready.
- Unity Catalog access has been designed and tested.
- Historical and incremental data movement is planned.
- SQL, procedures, pipelines, and applications have conversion owners.
- BI, orchestration, and downstream systems are included in testing.
- Parallel validation includes technical and business approval.
- Cutover, rollback, stabilization, and decommissioning plans are documented.
Plan the Migration Around Workloads, Not Tables
A successful Snowflake-to-Databricks migration does not try to make the new platform look exactly like the old one. It gives every workload an intentional destination, distinguishes quick conversions from real redesign work, and checks business outcomes as carefully as technical outputs.
The safest plan is the one that makes risk visible early: inventory dependencies, move in controlled waves, validate both environments, and retain a rollback path until Databricks is stable.
