# Migrating to Databricks without a cutover spreadsheet > How we move Synapse and Snowflake estates onto Databricks with Lakebridge and Airlift. One manufacturing migration took six weeks instead of six months. Published: 2026-10-08 Author: Preetham Reddy Tags: Databricks, Cloud, What We Do Canonical: https://www.techfabric.com/blog/synapse-snowflake-databricks-migration-airlift --- A manufacturing company came to us on Azure Synapse with the usual split estate: dedicated SQL pool logic, pipelines, and reporting wired straight into Synapse endpoints. We finished the migration to Databricks in six weeks. That kind of move normally runs six months or more, and the difference wasn't that we typed faster. The difference was that we stopped treating conversion as the project. Conversion is the part everyone budgets for and the part that goes fine. A transpiler takes the T-SQL, produces Databricks SQL, and reports a conversion rate that looks good in a steering deck. Then the program stalls for four months while nobody can answer a simpler question: which of these objects is actually safe to cut over, validated against what, by whom. That question is where migrations die, and it's the question [Airlift](https://airlift.techfabric.com) was built to answer. ## Start with an inventory before you write a plan Every migration I have seen that slipped did so because the scope was guessed. Somebody counted views in a catalog query, multiplied by a gut-feel hours figure, and sold a date. The first thing we run is Lakebridge Analyzer. It scans the exported metadata and produces a complexity report with a full inventory of mappings, programs, transformations, functions and variables, plus the interdependencies between jobs and components, which is what you actually need to sequence waves ([Lakebridge Analyzer guide](https://databrickslabs.github.io/lakebridge/docs/assessment/analyzer/)). Objects come back graded, and the ones flagged HIGH or VERY HIGH are the ones that will need eyes after transpilation ([Lakebridge getting started](https://databrickslabs.github.io/lakebridge/docs/getting_started/)). For a Synapse source the export is SQL files out of the database platform; for ETL tools it's a repository export, usually XML or JSON. Analyzer supports Synapse, Snowflake, Teradata, SSIS, ADF, Informatica-adjacent tools and a long list more, so a mixed estate goes through one assessment instead of three. One practical detail that saves a week later. If your DDL lives in monolithic files with procedures, tables, views and functions jumbled together, split them first with `sqlsplit`. Analyzer then gives you per-object results instead of per-file averages, and the transpiler gets cleaner input: ``` ./sqlsplit -d /path/to/your/sql -o /path/to/split/output databricks labs lakebridge analyze \ --source-directory /path/to/split/output \ --source-tech Synapse \ --report-file /path/to/output/analysis.xlsx \ --generate-json true ``` Pass `--generate-json true` even if nobody asks for it. The Excel report is for the steering committee. The JSON is what you load into your own tracking so that object counts, complexity and wave membership stay queryable instead of being copied by hand. In Airlift that assessment runs as a Databricks workspace job and lands as a governed record with the tool version pinned. Pinning the version matters more than it sounds. Six months on, when someone asks why an object was graded the way it was, "Analyzer said so" isn't an answer unless you can say which Analyzer. ## What you are actually migrating off Synapse Synapse is one brand over several products, and they don't move at the same speed. Databricks' own field guidance splits it cleanly. Most of the effort goes into Dedicated SQL Pools, where years of stored procedures, distribution strategies and indexing decisions have accumulated. Serverless SQL Pools are mostly a matter of re-establishing views, external tables and access patterns, while Spark Pools are the easiest, because both sides are Apache Spark and notebooks often move with few changes ([Navigating a Synapse Migration to Databricks](https://www.databricks.com/blog/navigating-synapse-migration-databricks)). The trap is treating those as one workstream with one date. They involve different stakeholders and carry different risk. Orchestration, permissions and BI connectivity are the parts most often underestimated, because the semantic models and reports are wired directly into Synapse endpoints and nobody owns the full list. A Snowflake estate has a different shape and the same failure mode. The SQL converts well. What is hard is the surrounding gravity, meaning tasks, streams, the warehouses someone sized two years ago, and the BI tools pointed at a specific role. ## Run the old system and the new one at once Both sources support a hybrid period, and taking it's the single biggest de-risking move available. For Snowflake, Lakehouse Federation gives you two options. Query federation creates a Unity Catalog connection and a foreign catalog, pushes queries down over JDBC, and is read-only, so it suits ad hoc reporting and proof-of-concept work. Catalog federation connects the Snowflake catalog and runs the query directly against object storage on Databricks compute, which Databricks describes as more cost-effective and performance-optimized, and which is the one meant for incremental migration or a long-term hybrid ([Connect to external databases and catalogs](https://docs.databricks.com/aws/en/query-federation/)). Azure Synapse is a supported query federation source too. Setting up the Snowflake connection takes a security integration on the Snowflake side and a connection plus foreign catalog on the Databricks side. Watch `OAUTH_REFRESH_TOKEN_VALIDITY`: it defaults to 90 days, and when the refresh token expires you have to re-authenticate the connection ([Run federated queries on Snowflake](https://docs.databricks.com/aws/en/query-federation/snowflake)). A federated catalog that silently stops working in the middle of a migration is a bad Tuesday. Use the federated catalog to move consumers before you move data. Repoint a dashboard at Unity Catalog while the table still lives in Snowflake, prove the numbers, then swap the storage underneath. The BI team experiences one change instead of two. ## Certify objects, then cut over waves Here is the discipline that compressed six months into six weeks. An object isn't migrated because a transpiler emitted SQL. It is migrated when there is evidence it behaves the same. Lakebridge's Reconciler compares row counts, schema and data values between source and target and writes results to a workspace dashboard ([getting started](https://databrickslabs.github.io/lakebridge/docs/getting_started/)). That is your parity evidence. Airlift admits it into an object's readiness track and only then mints a signed migration certificate, and a wave stays structurally blocked until every object in it is certified and the configured approvals are collected. That inversion is the whole trick. Cutover night stops being a bridge call and a checklist where approvals are Slack messages and rollback is a plan in somebody's head. The gate reads governed state, and rollback becomes a first-class action instead of an apology. The deterministic pass runs first. Lakebridge converts what it can convert the same way every time, and the output carries inline `FIXME` comments at the positions it couldn't guarantee. For the residue, Airlift allows exactly one bounded repair candidate from a Harness agent with no tools, no filesystem, no network and fixed iteration and cost budgets. The agent proposes; it is never granted evidence admission, certification, waivers, wave approval, cutover or rollback. Agents convert, humans decide. ```mermaid %% caption: Objects are certified individually; the wave gate stays blocked until every object in it has admitted evidence and the approvals are collected. flowchart TD A["Assess estate with Analyzer"] --> B["Group objects into waves"] B --> C["Deterministic conversion pass"] C --> D["Reconcile against source"] D --> E["Certify object with evidence"] E --> F["Wave gate reads approvals"] F --> G["Verified cutover and attest"] class F accent ``` And when compliance comes back two quarters later asking who approved what, one governed export assembles the trail, content-digested and replayable. ## What the lakehouse gives you that the warehouse could not Teams justify these migrations on licensing and then find the savings somewhere else. There are fewer services to operate and fewer integration points, and one governance model replaces SQL permissions in one place with lineage stitched together in another. The more interesting part is what becomes possible once the data is in Unity Catalog. Lakebase is managed Postgres running inside the Databricks platform with autoscaling, branching and native Unity Catalog integration ([Lakebase Postgres](https://docs.databricks.com/aws/en/oltp/projects/)). It supports four patterns. You can serve lakehouse data in Postgres at low latency, store Postgres changes back as Delta with full change history, back an application, or run an online feature store or an agent state store. A plant-floor app that needs sub-second reads of a table your warehouse computes overnight is a sync instead of a new system of record. Compute has scale-to-zero on by default with a 24-hour inactivity timeout, so a dev branch costs nothing while nobody is using it ([get a Postgres database](https://docs.databricks.com/aws/en/oltp/projects/get-started)). That is the transactional half. The analytical and AI half is the same catalog, with governance that covers data, notebooks and AI assets together, so an AI workload doesn't require a new governance silo. None of it is reachable while your logic is locked in stored procedures on a dedicated SQL pool. Sequence it that way too. Migrate, certify, then build. Teams that try to redesign the data model and adopt three new capabilities during the cutover get neither. ## What I would tell a team starting this Spend the first two weeks on assessment and don't negotiate it away. An inventory with complexity grades and dependency edges is what turns a date from a guess into a plan, and it is also the artifact that lets you say no to scope creep with evidence. Decide what "done" means for a single object before you convert the first one. Row counts only, or row counts plus value-level reconciliation on the columns finance actually reads? Write it down as a readiness profile, assign profiles per object class, and make the gate enforce it. Teams that define parity after conversion argue about it forever. Pick the hybrid period deliberately and set its end date. Federation is a bridge with a destination on the other side, and a bridge nobody plans to dismantle becomes two platforms to pay for. And keep the agents on the conversion side of the line. One bounded proposal, independently validated, recorded by digest. Every decision that a person would have to defend to an auditor stays with a person. If you are part-way through a migration that has stalled, the diagnosis usually has nothing to do with the SQL. It is that nobody can prove which objects are safe. Fix that and the schedule fixes itself. More on how we work with the platform at [/databricks](/databricks).