SIGMATIC 21 July 2026 · Mujahid · 10 min read
Azure Synapse to Databricks: a migration guide
Azure Synapse is a sensible platform for a lot of organisations, and a decision to move away from it shouldn’t start from the assumption that it’s failed. The better question is whether the current architecture is still the simplest, most cost-effective and governable foundation for what you need to deliver next.
For some organisations, the answer is yes: a stable Synapse environment running conventional SQL warehousing and Power BI can keep meeting its purpose indefinitely. For others, the platform has gradually expanded into a sprawl of dedicated SQL pools, serverless queries, Spark workloads, Data Factory pipelines and separate security models, and the cost of holding that together as one coherent platform stops being justifiable once requirements extend into streaming, machine learning and AI.
In those cases, Databricks can be a stronger foundation, but only if the migration is treated as a structured transformation programme rather than a code-conversion exercise.
Synapse isn’t one workload
The first mistake organisations make is treating “Synapse” as a single technology that can be lifted and shifted as one unit. In reality it’s a bundle of materially different workloads: dedicated SQL pools full of years of accumulated T-SQL, serverless SQL over files in the data lake, Spark notebooks, Data Factory pipelines, Power BI semantic models, Purview and Azure RBAC, integration runtimes reaching into private networks, and the DevOps pipelines holding it all together. Each has a different migration path and a different level of risk.
Dedicated SQL pools usually need the most effort because they carry the most embedded business logic. Spark notebooks look portable at first glance but often depend on Synapse-specific libraries, linked services and credentials that don’t travel cleanly. A useful migration assessment starts by splitting the estate into distinct workstreams rather than setting one deadline for “migrate Synapse.”
What a move to Databricks can actually achieve
The strongest case for migration usually isn’t that one Databricks feature beats one Synapse feature. It’s reduced fragmentation. Databricks brings data engineering, SQL analytics, streaming, machine learning and AI onto one governance layer through Unity Catalog, which can replace the patchwork of different security models that tends to build up across SQL pools, storage accounts, pipelines and reporting tools. That consistency isn’t automatic: catalog design, domain ownership, environment separation and access groups still need deciding. What changes is that those decisions get made once, in a common framework, instead of being reinvented differently in every analytical service.
The same logic applies to cost. The real saving rarely comes from comparing consumption bills line for line, it comes from eliminating duplicate transformation logic, separate monitoring setups and repeated data movement across systems. That consolidation has to be designed into the target architecture. Moving Synapse workloads into Databricks while keeping every existing integration and duplicated data store just means operating two architectures instead of one.
When migration might not be the right call
Databricks offers little immediate benefit if Synapse is stable, the estate is mostly predictable SQL warehousing and Power BI, costs are understood, and there’s no real demand for streaming, ML or AI. It’s also the wrong answer if the organisation doesn’t have the engineering capacity to run it well, if a large volume of complex T-SQL would need rewriting for no clear return, or if the actual problem is weak data ownership rather than the platform underneath it. Moving to Databricks doesn’t remove the need for architecture discipline, testing and cost management, it just gives you stronger tools for it. An unmanaged Databricks estate can end up just as unruly as the one it replaced. Sometimes the right call is to modernise part of the Synapse estate, retire what’s unused, or run Databricks alongside Synapse for specific workloads rather than migrate everything.
What actually moves
There’s rarely a clean one-to-one replacement. A rough mapping for the highest-value components:
| Current capability | Likely target | Watch for |
|---|---|---|
| Dedicated SQL Pool | Delta Lake and Databricks SQL | T-SQL conversion, stored procedures, reconciliation |
| Serverless SQL Pool | Databricks SQL over governed tables | External tables, file formats, query behaviour |
| Spark Pools | Databricks notebooks, jobs and pipelines | Runtime compatibility, libraries, secrets |
| Synapse Pipelines / ADF | Retained ADF, Databricks orchestration, or both | Connectors, private connectivity, ownership |
| Power BI | Power BI connected to Databricks SQL warehouses | Authentication, semantic models, refreshes |
Retaining Azure Data Factory through the first waves is often entirely reasonable if it already gives you stable connectivity to private networks and legacy systems, moving orchestration should be a deliberate decision, not a purity test. Existing Power BI reports don’t necessarily need rebuilding either. They can often be repointed to Databricks SQL, provided the semantic models, authentication and refresh behaviour are properly tested first.
Decide the target architecture before converting code
Code conversion is visible and measurable, which makes it tempting to start there, but it’s usually the wrong entry point. Before converting a single stored procedure, the programme needs to agree how the target platform will actually operate: the Unity Catalog structure (whether catalogs represent environments or business domains, who owns each one, how access groups are managed), what happens to existing data in the lake (registered in place, restructured, rewritten into Delta, or accessed temporarily through federation), and the engineering standards for source control, testing, deployment and rollback that every migrated workload will be held to. Cost controls belong in this list too: a platform isn’t cheaper because it autoscales, it becomes cost-effective when workloads are designed properly, usage is attributable, and teams are accountable for what they spend.
Three ways to approach it
Replatform first reproduces existing outcomes on Databricks with minimal redesign, translating procedures and repointing reports while keeping the logical model intact. It’s the lowest-risk route to a fixed retirement date, but it risks carrying the old platform’s technical debt into the new one.
Modernise during migration redesigns data models and pipelines as they move, which can genuinely remove duplication and take advantage of Delta Lake and Unity Catalog properly, at the cost of a much larger, harder-to-scope programme, particularly where the current logic is poorly documented.
A hybrid approach is usually the practical answer for an established estate: translate the low-complexity workloads efficiently, redesign the high-value or genuinely broken ones, retire what’s unused, and leave a few things on Synapse temporarily where an immediate move offers little upside.
Discovery should shrink the scope, not just describe it
The first useful output of discovery isn’t a list of everything that needs to move, it’s a smaller, evidence-based list of what’s genuinely required. Most estates accumulate unused tables, dormant pipelines, duplicate datasets and reports nobody opens anymore, and migrating those creates cost without creating value. A good discovery phase combines automated estate profiling (tables, dependencies, query patterns, actual usage) with stakeholder validation on ownership and criticality, because removing an unused workload from scope is cheaper and far less risky than translating it perfectly.
A practical roadmap
A controlled migration tends to move through the same stages: agree the measurable outcomes the migration is meant to produce before scoping starts; build the technical inventory, dependency map and cost baseline; design the target platform (catalog structure, identity model, ingestion patterns, CI/CD, cost management) before delivery scales; prove it with one genuinely representative production workload, not the easiest one you can find; turn the proven patterns into repeatable migration components once they’ve been validated; migrate in waves grouped by business domain and risk, each with its own owner and rollback plan; run critical workloads in parallel with reconciliation evidence before anyone trusts the new numbers; and only decommission Synapse once every dependent report, process and user has genuinely moved.
Where it actually gets hard
T-SQL conversion is manageable for simple queries, but dynamic SQL, cursor-based processing and the physical design constructs specific to dedicated SQL pools (hash distribution, replicated tables) don’t map directly onto Delta Lake, so a literal translation can preserve old complexity without preserving its value. The better question isn’t “how do we reproduce this procedure exactly,” it’s what business outcome the procedure protects and what the most maintainable way to protect it on the new platform looks like.
Orchestration, Power BI and security tend to be underestimated for the same reason: they look like configuration, but ADF pipelines often encode years of retry logic and connectivity knowledge, Power BI performance and authentication behaviour needs testing rather than assuming, and the access model has to be designed alongside the catalog structure, not bolted on afterwards. Networking is worth testing early too, discovering during a late migration wave that a critical source can’t be reached from the new compute model can stall several waves at once.
Mistakes worth avoiding
The most common failure mode is treating migration as a pure technology swap: code moves, but ownership, governance and delivery practices don’t change, so the new platform inherits the old one’s problems. Close behind it is migrating everything because nobody’s confident enough to retire what’s unused, and designing Databricks to resemble Synapse (distribution keys become partitions, every stored procedure gets reproduced without challenge) so the organisation pays for a new platform while keeping the old architecture’s constraints. Starting with the easiest possible workload feels safe but doesn’t test connectivity, governance or production support, so the real problems only surface once the programme has scaled. And underestimating reconciliation is what actually damages trust: a pipeline running successfully doesn’t prove it produced the right numbers.
Building an honest business case
A credible business case weighs current-state costs (compute, storage, tooling, support, and the manual effort spent on reconciliation and failed pipelines) against migration costs (discovery, conversion, parallel running, training, decommissioning) and only then states the expected benefit. Don’t start with a promised percentage saving and work backwards to justify it, build the baseline from actual consumption and delivery performance, then validate the expected improvement through the lighthouse workload before scaling the claim across the whole programme.
What good looks like afterwards
A strong migration leaves you with more than a working Databricks workspace. It leaves a smaller, cleaner workload estate with defined ownership, governed access through Unity Catalog, reusable ingestion patterns, automated deployment, reconciliation evidence for everything that moved, and a dated plan for switching off what’s left of the legacy platform. The measure of success isn’t the number of pipelines converted, it’s whether the organisation can deliver trusted data faster and govern it more consistently than before.
Before committing to a full migration
Leadership should be able to answer a handful of questions before approving the programme: what business problem is this actually solving, which Synapse capabilities are genuinely active, which workloads can be retired outright, how dependent is the estate on T-SQL stored procedures, who will own the Databricks platform once it’s live, how will costs be attributed and controlled, and what evidence will demonstrate the migration actually succeeded. Where those answers aren’t clear yet, the next step isn’t a full implementation proposal, it’s a structured migration assessment.
How Sigmatic Analytics approaches this
We help organisations assess, design and deliver controlled migrations from Azure Synapse to Databricks, starting from what’s genuinely running today rather than what the estate has accumulated over time. The goal isn’t to recommend the largest possible migration, it’s to give you a defensible answer to four questions: what should move, what shouldn’t, in what order, and what has to be true for it to succeed.
Considering a move from Synapse? A short discovery and assessment can identify the scale, dependencies and likely value of a migration before you commit to a larger programme. Book a Synapse-to-Databricks migration assessment.