Navigating a Synapse Migration to Databricks

Navigating a Synapse Migration to Databricks | Databricks Blog Skip to main content

Summary

Synapse customers are stuck stitching together Dedicated SQL, Serverless SQL, Spark Pools, and ADF — paying for duplicated governance, extra tooling, and operational overhead on a warehouse that was never built for ML, streaming, and AI.

The blog is a practical, field-tested playbook for migrating from Azure Synapse (Dedicated SQL Pools, Serverless SQL, and Spark Pools) to a unified Databricks Lakehouse, structured as a phased program.

The payoff: streamlined Synapse migration and practical field engineering tips for simpler architecture, better performance and lower costs.

Azure Synapse has served as a reliable foundation for SQL analytics at scale, and teams that built on it made a sensible choice at the time. However, a platform primarily designed around a data warehouse isn't built for the full range of what data teams are now expected to deliver. Filling those gaps usually involves adding more services, integrations and operational overhead, which builds up over time. Migrating to Databricks is one way to address this issue. In this blog we address how to approach Synapse migration and what to keep in mind while executing it. What a Synapse Migration Unlocks Across Synapse migration engagements we see with our customers, three business drivers come up consistently: Unified data estate. As data platforms grow, the number of services involved increases too. For example, Synapse Analytics pools handle one set of workloads, Spark pools handle another, and serverless SQL provides ad hoc access. Azure Data Factory often sits alongside these to orchestrate everything. Many organisations also have legacy SSIS workloads that still need to be supported. None of these components are problematic in isolation. However, the challenge arises when additional services are introduced, as this adds another layer of governance, monitoring, permissions management and operational overhead. Databricks addresses this issue by unifying data engineering, analytics, machine learning and governance on a single platform. Rather than moving between services with different operating models, teams can work against the same underlying architecture and governance framework. The result is reduced complexity, fewer integration points, and a platform that's easier to operate at scale. Future readiness. Focus of modern data teams now is shifted towards supporting machine learning models, real-time data pipelines, and AI-powered applications. All of these workloads depend on the same underlying data. The challenge is that traditional, warehouse-centric architectures were not designed for this level of convergence and were primarily targeting BI needs. As requirements expand, organisations often find themselves adding more services and specialised tools to fill capability gaps. Databricks is built for this convergence, unifying data, analytics, and AI on a single platform. With Unity Catalog providing consistent governance across data, notebooks, and AI/ML assets, and Unity AI Gateway extending those controls to models, agents, and AI applications, organizations can adopt new AI workloads without adding new governance silos. Operational efficiency. While most migration business cases begin with licensing costs, that's rarely where the biggest savings come from. The larger impact often comes from reducing the number of systems that teams need to operate and support. Fewer services means fewer integrations, fewer handoffs between tools, and fewer potential issues.

Synapse Databricks: Capabilities Overview

Organisations that have already made the move are seeing tangible results. For example, Casey's , the third-largest convenience store chain in the United States, migrated its analytics environment from Synapse to Databricks Lakehouse (formerly Databricks SQL), reducing operational data delivery times from eight hours to four. As another example, Italgas simplified its architecture by removing both Synapse and Azure Analysis Services. The company reported a 73% reduction in workload costs while serving both Power BI and AI-driven analytics directly from Databricks. While the specifics vary from organisation to organisation, the pattern remains consistent: simpler architectures, faster data delivery and a platform better aligned to the demands placed on modern data teams. Understanding What You Are Actually Migrating One thing that often catches teams off guard early in a Synapse migration is the scope of what they are moving. Although Azure Synapse is often considered a single platform, in practice it comprises a variety of distinct services operating under one brand, each of those may require different migration strategies and has a different level of complexity. Most migrations spend the majority of their effort on Dedicated SQL Pools, where business logic, stored procedures, distribution strategies, indexing decisions, and performance optimisations have accumulated over years. But the complexity rarely stops at the SQL. The same migration usually has to account for orchestration (Azure Data Factory and Synapse Pipelines), permissions and governance (SQL permissions plus Microsoft Purview, with lineage often stitched together manually), and BI and third-party connectivity (semantic models, reports, and downstream tools wired directly into Synapse endpoints). This is the part of the estate that demands the most redesign, testing, and validation - and the part most likely to be underestimated. Serverless SQL Pools are generally simpler, because they primarily provide a query layer over files in a data lake. Migration here is mostly about re-establishing views, external tables, and access patterns rather than redesigning complex workloads. Spark Pools are the simplest component to move, since Synapse Spark and Databricks are both built on Apache Spark and notebooks can often migrate with relatively few changes. The important point is that these components move at different speeds, involve different stakeholders, and present different risks. Organisations that approach the migration as a single workstream with a single timeline often underestimate both effort and complexity. That's where schedules start to slip and migration programmes begin to expand beyond their original scope. To migrate successfully, teams should structure the migration journey. How to Structure the Migration A...