1/14

02 Nov 2026

Synapse to Databricks Migration: Is Synapse End of Life?

An Azure Synapse to Databricks migration moves dedicated SQL pools, serverless SQL, Spark pools, and Synapse Pipelines onto Delta Lake tables in your ADLS storage, governed by Unity Catalog, with Lakeflow Jobs and Databricks SQL warehouses doing the work. It is a re-architecture: the risk sits in T-SQL procedures built for an MPP engine (CTAS, distributions, RENAME OBJECT swaps) and in small semantic differences, not in the data copy. Microsoft has not announced an end of life for Synapse as a whole, but the Synapse Spark 3.4 runtime reached end of support on March 31, 2026, and Microsoft's own notice points Spark users toward Fabric, so a destination decision is due. Databricks' Lakebridge profiles Synapse estates and converts Synapse T-SQL to Databricks SQL, and Lakehouse Federation can query a dedicated pool in place, but every figure still needs reconciling against Synapse before cutover.

Many organizations built their cloud warehouse on Synapse because it combined SQL pools, Spark, and pipelines in one Azure workspace. That same bundle makes it hard to leave, because each component carries its own code, schedules, and security. This page covers where Synapse stands, whether Databricks or Fabric fits your team, how each component maps, what Lakebridge does for Synapse, and where results drift. For the services side, see our Databricks migration services overview, and for the wider warehouse picture, our data warehouse to Databricks article.

Quick Summary

Synapse isn't being switched off, but its Spark runtimes are aging out, and Microsoft is shifting investment to Fabric. That makes this as much a destination decision as a migration. Databricks fits teams that want one open lakehouse for SQL, Spark, streaming, and ML, and either way the work is in T-SQL logic, pipelines, and proving the numbers match.

Key Takeaways

Synapse is not retired, but it is aging. No end-of-life is announced for the service as a whole, yet Spark 3.4 has already ended, and new capability is going to Fabric.
Choose the destination on purpose. Databricks and Fabric are both valid, and the right one depends on your team, your stack, and your Spark and ML needs.
The risk is in the code. CTAS-based ETL, RENAME OBJECT swaps, WHILE loops, and dynamic SQL need refactoring, not translation.
Data in ADLS shortens the path. Parquet and Delta files already in the lake can often be registered in Unity Catalog instead of copied.
Lakebridge helps. It profiles Synapse estates and converts Synapse T-SQL deterministically, with no semantic validation.
Parity needs evidence. Reconcile against Synapse through at least one full business cycle before cutover.

Why Synapse Teams Are Re-Evaluating Their Platform

The case for leaving rarely rests on one event. Pressures usually accumulate:

Platform direction. Microsoft's guidance for aging Synapse runtimes now recommends Fabric, so the roadmap question is real even without an end-of-life date.
Elastic, workload-specific compute. Dedicated SQL pools scale in fixed DWU steps for the whole pool, while Databricks sizes jobs, SQL warehouses, and serverless compute independently per workload.
Concurrency. Dedicated pools cap concurrent queries and depend on careful distribution design, while Databricks SQL warehouses scale out for BI users.
One engine for SQL, Spark, and AI. Synapse splits work across SQL pools, serverless SQL, and Spark pools, whereas Databricks runs BI, engineering, streaming, and ML on the same Delta tables.
Open formats in your own storage. Delta Lake data in ADLS stays in open Parquet files that Power BI, Fabric, and other engines can read.
Governance. Unity Catalog governs tables, files, and AI assets in one place, with Entra ID integration.

Synapse Support Dates That Shape Your Timeline

Item	Date	What It Means
Synapse Runtime for Apache Spark 3.4	End of support March 31, 2026	No bug fixes, security updates, or vulnerability remediation, and phased disablement of jobs
Synapse Runtime for Apache Spark 3.5 (GA)	End of support announced October 31, 2026, effective October 31, 2027	Spark pools need a plan within the next year
Azure Synapse Analytics overall	No end-of-life date announced as of this check	Dedicated SQL pools, serverless SQL, Spark pools, and pipelines remain supported

The Spark runtime dates come from Microsoft Learn, and the "no end of life" statement reflects analyst reports checked in October 2026, so confirm both on Microsoft's lifecycle pages. Microsoft's own notice for the ended Spark 3.4 runtime recommends upgrading to Synapse Spark 3.5 or Fabric Runtime 2.0, and it prioritizes Fabric. The practical reading is that you are not forced out of Synapse on a fixed date, but Spark pool users have a clock, and every new capability lands elsewhere.

Synapse vs Databricks at a Glance

Area	Azure Synapse	Databricks
Warehouse engine	Dedicated SQL pool, an MPP warehouse sized in DWUs and queried with T-SQL	Databricks SQL warehouses over Delta tables
Lake queries	Serverless SQL pool over ADLS files	SQL warehouses and Spark over Delta tables and volumes
Spark	Spark pools on Synapse runtimes	Databricks Runtime, jobs, and serverless compute
Orchestration	Synapse Pipelines, built on the Data Factory engine	Lakeflow Jobs and declarative pipelines
Storage and format	Pool-managed warehouse storage plus files in ADLS	Open Delta Lake tables in your own ADLS storage
Governance	Pool permissions and workspace roles	Unity Catalog for tables, files, and AI assets
Tuning model	Distributions, indexes, partitions, and workload groups	Liquid clustering, Photon, and per-workload compute
ML and AI	Spark pools plus separate Azure services	MLflow and AI tooling on the same governed data

The practical difference is that Synapse splits work across several engines inside one workspace, while Databricks runs SQL, Spark, streaming, and ML against the same governed tables.

Databricks or Fabric: Choosing the Destination

Situation	Better Fit
Heavy Spark, streaming, ML, or multi-cloud goals, with open Delta and Unity Catalog governance	Databricks
Microsoft-centered stack, Power BI at the core, and a small platform team	Microsoft Fabric, where Microsoft provides guided migration tooling for Synapse SQL pools, Spark, and pipelines
A stable, tuned dedicated SQL pool with no near-term pressure	Staying on Synapse for now can be reasonable, if you plan around the Spark runtime dates
A mixed estate	Databricks producing governed Delta data that Power BI and Fabric consume

Neither answer is universal. Fabric migration paths for the Microsoft side are covered in our Microsoft Fabric migration services, Fabric data pipeline migration, and Fabric consulting pages, and the reverse direction in Databricks to Microsoft Fabric. For a broader comparison, see Databricks vs Snowflake.

Five Layers of a Synapse Estate to Inventory

Layer	What It Includes	Commonly Missed
Data and storage	Dedicated pool tables, external tables, lake folders, file formats, partitions, and history	How much history genuinely needs to move
Code and logic	Stored procedures, views, functions, Spark notebooks, Spark job definitions, and embedded business rules	Logic buried in CTAS chains and RENAME OBJECT swaps
Pipelines and orchestration	Synapse Pipelines, mapping data flows, triggers, linked services, integration runtimes, and Synapse Link connections	Implicit dependencies between triggers
Security and governance	Entra ID logins, database roles, row-level and column-level security, dynamic data masking, and managed identities	Workspace permissions that grant access indirectly
Consumers	Power BI datasets and DirectQuery reports, Excel connections, extracts, and applications	Consumers nobody documented

How Each Synapse Component Maps to Databricks

Synapse Component	Common Challenge	How to Solve It
T-SQL stored procedures	CTAS, temp tables, WHILE loops, dynamic SQL, and staging swaps have no direct Spark equivalent	Build a dependency graph, convert in waves by complexity, replace CTAS and rename patterns with Delta writes and MERGE, and refactor loops into set-based logic, as in our PL/SQL conversion article
T-SQL dialect	TOP, ISNULL, CROSS APPLY, string concatenation with +, IDENTITY, and RENAME OBJECT differ from Spark SQL	Agree on a translation standard, automate the syntax, and validate query by query
Distributions and indexes	Hash, round-robin, and replicated distributions, clustered columnstore indexes, partitions, and manual statistics shape today's performance	Drop distribution and index logic, use liquid clustering and Photon, and benchmark the top queries before cutover, and do not turn a HASH distribution column into a partition column, because that carries Synapse-shaped thinking over
Data types and collation	DATETIME rounding, MONEY, and case-insensitive collations change joins, DISTINCT results, and totals	Agree a type-mapping standard, decide how case is handled, and test edge cases against Synapse output
Workload management	Workload groups, classifiers, and resource classes control concurrency inside one pool	Separate workloads onto their own jobs compute and SQL warehouses, size each independently, and enforce limits with compute policies and budgets
Serverless SQL and external tables	OPENROWSET queries, external tables, and credentials over ADLS are scattered across scripts and views	Register lake data as Unity Catalog external tables and volumes with storage credentials, and convert serverless views to governed views
Spark pools and notebooks	Notebooks rely on mssparkutils, linked services, runtime versions, and pool-specific libraries	Replace mssparkutils with dbutils, linked services with Unity Catalog connections and secret scopes, and pin libraries per job
Synapse Pipelines and data flows	Copy activities, mapping data flows, triggers, and integration runtimes carry implicit dependencies	Rebuild transformations as notebooks or Lakeflow Spark Declarative Pipelines, move scheduling to Lakeflow Jobs, or keep Data Factory as orchestrator where it adds value
Synapse Link and feeds	Near-real-time feeds, including Dynamics 365 and Dataverse exports, must keep flowing during and after the move	Repoint upstream loads to also write bronze Delta tables during the parallel run and apply changes with MERGE, and for Dataverse exports see the note below the table
Security and access	Row-level security, column-level security, dynamic data masking, and database roles do not carry over	Sync Entra ID groups to Unity Catalog, redesign access with row filters and column masks, test per role, and see our guide to migrating row-level security

Dynamics 365 and Dataverse deserve a specific check. Databricks' Lakeflow Connect Dynamics 365 connector can read Azure Synapse Link exports from ADLS Gen2, whether written as CSV or as Parquet-format Delta tables, using Entra ID OAuth. Reports indicate Microsoft is deprecating Synapse Link's Delta Lake export option, with new customers closed out from October 2026 and removal in December 2027, and that export path depends on a Synapse Spark pool, so confirm the current status in Microsoft's Power Platform notices before you design around it.

If your Power BI reports sit on Synapse, plan them in the same wave as their source tables, and see our Power BI consulting services and enterprise BI migration services for the report layer.

Moving Data Out of Dedicated SQL Pools

A phased path avoids a big-bang copy:

Read in place first. Lakehouse Federation can query a Synapse dedicated pool through a connection of type sqldw, which gives analysts early access while history moves. It needs Databricks Runtime 13.3 LTS or above with Standard or Dedicated access mode, or a Pro or serverless SQL warehouse. Databricks recommends federation over its older Azure Synapse connector, which uses the COPY statement and works with dedicated pools only.
Export history to the lake. Use CETAS to write dedicated pool tables as Parquet files in ADLS, in parallel by partition, then convert them to Delta tables.
Register what is already in the lake. Parquet and Delta files that Synapse Spark or serverless SQL already wrote to ADLS can often be registered as Unity Catalog external tables, so check storage access and Delta table features before you copy anything.
Keep both platforms current. Repoint the upstream loads that feed Synapse so they also write bronze Delta tables during the parallel run, and apply changes with MERGE.
Reconcile until the numbers match.

Preserve existing surrogate key values as data when you load dimensions and facts, instead of regenerating them, because identity values are not guaranteed to be contiguous on either platform.

What Lakebridge Covers for Synapse Today

Lakebridge is Databricks' free, open-source migration toolkit from Databricks Labs, and Databricks' own Synapse migration blog cites automation of 80 to 90% of code conversion, a vendor figure for favorable cases. Databricks also notes that syntax conversion is usually straightforward while semantic differences, such as case-insensitive collation, need more care. For Synapse, it covers these pieces:

Lakebridge Piece	What It Does for Synapse	What Still Needs Engineers
Synapse profiler	Profiles a Synapse workspace, including SQL pools, with utilization and activity dashboards	Deciding what to retire and sequencing waves
Legacy Synapse profiler	Profiles a dedicated SQL pool, including legacy Azure SQL DW, using SQL authentication	Security review of the authentication method
Analyzer	Scores SQL code complexity and compatibility	Interpreting results and planning conversion waves
Morpheus transpiler	Converts Synapse dedicated pool T-SQL to Databricks SQL deterministically, and warns when it cannot guarantee equivalence	It does no semantic validation such as type-checking, so outputs need testing
BladeBridge and Switch	BladeBridge lists Synapse among its source dialects, and Switch (LLM-based, experimental) handles constructs the others do not	LLM output needs review and reconciliation

Lakebridge is a Databricks Labs project, so confirm support terms before building production timelines on it. Our Databricks migration services overview covers how tooling and services divide the work, and our SQL Server and SSIS to Databricks article shows how the same toolkit handles the closest sibling dialect.

Worked Example: CTAS and RENAME to CREATE OR REPLACE

A nightly summary table rebuilt with CTAS and swapped in with RENAME OBJECT is typical Synapse ETL. This is an illustrative example, not a client engagement.

Synapse dedicated SQL pool

CREATE TABLE dbo.sales_summary_new
WITH (DISTRIBUTION = HASH(customer_id), CLUSTERED COLUMNSTORE INDEX)
AS
SELECT customer_id, SUM(amount) AS total_amount, COUNT(*) AS order_count
FROM dbo.fact_sales
GROUP BY customer_id;

RENAME OBJECT dbo.sales_summary TO sales_summary_old;
RENAME OBJECT dbo.sales_summary_new TO sales_summary;
DROP TABLE dbo.sales_summary_old;

Databricks SQL

CREATE OR REPLACE TABLE gold.sales_summary
CLUSTER BY (customer_id)
AS
SELECT customer_id, SUM(amount) AS total_amount, COUNT(*) AS order_count
FROM silver.fact_sales
GROUP BY customer_id;

Four statements become one atomic statement. The distribution and index options disappear, replaced by liquid clustering, and readers keep seeing the previous version until the new one commits, with Delta time travel available if you need to inspect or restore it. Check that SUM over a MONEY column maps to DECIMAL(19,4) so totals match. For large tables, incremental loads with MERGE are usually better than rebuilding the whole table each night. Please test this example in a Databricks workspace before adapting it.

Where T-SQL Results Drift on Databricks

Synapse Behavior	What Changes on Databricks	Safeguard
Case-insensitive default collation	String comparisons are case-sensitive, so joins, DISTINCT, and filters change	Decide the rule deliberately, and normalize keys where the old behavior must hold
Trailing spaces ignored in string comparisons	Spark compares strings exactly	Trim keys explicitly and test with real data
DATETIME and MONEY types	DATETIME rounds to 3.33 ms steps and MONEY has four decimals	Map to TIMESTAMP and DECIMAL(19,4), and reconcile at column level
IDENTITY surrogate keys	Identity values are not guaranteed contiguous, and regenerated keys can differ	Load existing key values as data and re-seed key generation deliberately
Optimizer statistics and hints	Statistics, distribution choices, and hints do not carry over	Drop hints and benchmark the top queries
Result set caching	Cached results disappear with the pool	Confirm freshness expectations, and use SQL warehouse caching and Databricks materialized views where needed

These are the differences behind totals that never quite reconcile, and the reason for column-level checks like those in our automated ETL testing with Python approach. The same set-based thinking appears in our comparison of traditional vs modern ETL.

A Phased Synapse to Databricks Migration Plan

Phase	What Happens	Exit Criterion
Discovery	Profile dedicated and serverless pools, procedures, notebooks, pipelines, data flows, Synapse Link connections, and Power BI consumers, using query history and DWU usage	A scored inventory
Rationalization	Retire unused tables, procedures, pipelines, and reports, and decide how much history moves	An approved, smaller scope
Destination and design	Confirm Databricks or Fabric, choose a lift-and-shift, modernize, or hybrid approach, then define the medallion layers, Unity Catalog structure, ADLS layout, compute strategy per workload, and identity mapping	A signed-off design and wave plan
Pilot	Migrate one visible, low-risk workload end to end	A measured conversion rate and reconciled output
Data and code conversion	Export history, register lake data, and convert procedures, notebooks, and pipelines into Spark SQL, PySpark, and Lakeflow pipelines	Converted code passing tests
Validation and parallel run	Reconcile row counts, aggregates, and checksums table by table, and compare key Power BI outputs through a month-end	Signed-off parity
Cutover and decommission	Repoint Power BI and other consumers and train users, keep Synapse available for rollback until sign-off, then pause and retire pools, pipelines, and workspaces	No remaining Synapse dependency

For sequencing across waves, see our key checklist for BI modernization and cloud migration to Databricks article. If your Synapse pipelines orchestrate SSIS or Data Factory work, our article on SSIS to Azure Data Factory covers that layer.

Best Practices for a Low-Risk Migration

Decide the destination first, because it changes tooling, code targets, and the Power BI approach.
Rationalize before you migrate. Never move tables, procedures, or pipelines nobody uses.
Design Unity Catalog, Entra ID group mapping, and the ADLS layout before loading the first table.
Register existing lake data in place wherever storage access and Delta table features allow.
Start with a pilot that is visible to the business but low in risk.
Refactor T-SQL for Spark instead of translating MPP-specific patterns line by line, and do not map HASH distribution columns to partition columns.
Keep Synapse available as a rollback option until the parallel run is signed off.
Automate reconciliation and run it on every load during the parallel run, through at least one month-end.
Set compute policies, SQL warehouse auto-stop, and budget alerts from day one, and keep data security compliance requirements in view.
Version notebooks, SQL, and pipeline definitions in Git with CI/CD deployment.

Frequently Asked Questions

Is Azure Synapse end of life?

Microsoft has not announced an end-of-life date for Azure Synapse Analytics as a whole, and dedicated SQL pools, serverless SQL, Spark pools, and pipelines remain supported. But the Synapse Spark 3.4 runtime reached end of support on March 31, 2026, and Microsoft's guidance for aging runtimes points toward Fabric.

How do I migrate data from Synapse to Databricks?

Query the pool in place with Lakehouse Federation, export history to Parquet in ADLS with CETAS, convert or register it as Delta tables in Unity Catalog, keep both platforms current during a parallel run, and reconcile before cutover.

What is the difference between Synapse and Databricks?

Synapse bundles a dedicated SQL pool sized in DWUs, serverless SQL, Spark pools, and pipelines in one Azure workspace, while Databricks is a lakehouse platform where SQL warehouses, jobs, streaming, and ML run on the same open Delta tables governed by Unity Catalog.

Should I move from Synapse to Databricks or Fabric?

Both are valid. Fabric suits Microsoft-centered teams that want Microsoft's guided migration tooling, while Databricks suits teams that want one open lakehouse for large-scale engineering, streaming, ML, and AI, and many estates combine them, with Databricks producing governed data that Power BI and Fabric consume.

Can Lakebridge convert Synapse T-SQL?

Yes, partly. Lakebridge's Morpheus transpiler has a Synapse dialect for dedicated SQL pools that converts T-SQL to Databricks SQL deterministically, and a Synapse profiler assesses the estate, but Morpheus does no semantic validation, so stored procedure logic and results still need testing.

Scope Your Synapse Migration with DataTerrain

Moving a Synapse estate is easy to start and hard to finish, because the effort hides in T-SQL procedures, pipelines, and the numbers that must still match. DataTerrain brings 17+ years of experience and has supported 400+ clients in data and reporting modernization, including Microsoft-centered estates, with automated assessment, T-SQL and pipeline conversion, and figure-for-figure validation. Start with our ETL Solutions or the wider Databricks migration services page.

Talk to our migration team