What Databricks Lakebridge Automates and Where It Falls Short

How Lakebridge Databricks Migrations Work

A Lakebridge migration moves through assessment, conversion and reconciliation in that order. Each stage produces output the next one uses. The Analyzer report shapes which transpiler you pick, and the converted code has to be deployed and loaded before Reconcile has anything to compare.

Assessment With the Profiler and Analyzer

Assessment tells you how big the migration is and how hard each piece will be before any code moves. Lakebridge runs it through two separate tools, and they answer different questions.

The Profiler is the stage most teams skip. It feeds the cost side of the plan, since Databricks uses its output to estimate savings after the move. Its source coverage is narrow though. It works with Teradata, Oracle, SQL Server, Snowflake, Synapse and BigQuery. Everything else goes straight to the Analyzer, and that sizing baseline then has to come from somewhere like a data migration cost calculator.

The Analyzer has much wider coverage and needs no database access. Its report also has a limit. It only sees what the source metadata reveals, so business priorities and architecture choices still have to come from your team.

Code Conversion With Three Transpilers

Lakebridge converts code through three pluggable transpilers, and choosing the right one matters more than any setting inside them.

Morpheus

Morpheus parses SQL into a syntax tree and rebuilds it for Databricks. It covers only SQL Server, Snowflake and Synapse. It leans cautious. Morpheus flags anything it cannot guarantee as a warning, even when the output turns out to be correct. That creates review noise. Still, it beats silent errors.

BladeBridge

BladeBridge is the mature, pattern-based option. It handles Oracle, Teradata, Netezza and Redshift, plus ETL sources like DataStage and SSIS. Teams outside the Morpheus dialects usually land here.

Switch

Switch uses large language models to turn SQL and other formats into Databricks notebooks. It can take on any source format through custom prompts. The catch is maturity. Databricks still labels Switch experimental, and every file needs an LLM call, which makes it slower than the other two.

Databricks’ own advice is to start with Morpheus for SQL Server, Snowflake or Synapse and check the dialect table for anything else. There is also a newer Agentic Converter built into the Databricks UI, with limits of 300 files per batch and 1,000 lines per script. It does not support Teradata BTEQ scripts yet.

Data Reconciliation With Reconcile

Reconcile checks that the data in Databricks matches the source system, and it can run while both platforms are still live. It offers four report types.

• Schema compares column names and data types.

• Row hashes each row and needs no join key.

• Data joins on key columns and reports mismatches column by column.

• All runs the data and schema checks together.

Reconcile connects to Oracle, Snowflake, SQL Server, Redshift, Teradata, BigQuery and Databricks itself. By default the job runs on serverless compute, which keeps setup light but adds to the Databricks bill on large tables.

Which Sources Does Databricks Lakebridge Support?

Databricks Lakebridge supports more than 30 source systems, but only a handful get full coverage across all three stages. The Analyzer reads almost everything. The Converter and Reconcile cover far fewer. The table below trims the full list down to the sources teams ask about most.

Six sources get coverage at every stage. Snowflake is one of them, so the mechanics of the move are well supported. The Databricks vs Snowflake decision still deserves a hard look before conversion starts. Teradata also has full coverage, which helps teams running data warehouse modernization against a licence renewal date. One caveat applies there. Row and data reconciliation on Teradata need a hash function installed on the source and wired into the config first.

BigQuery sits in an odd spot. The main Converter does not list it, though the newer Agentic Converter does handle BigQuery SQL. Reconcile also has trouble with some BigQuery types. Types like BIGNUMERIC and TIME may show as mismatches even when the data moved correctly. Narrower Databricks integer types can show as matches when they cannot hold the full source range.

The Hadoop stack gets the least help. Hive, Oozie and Impala are Analyzer-only. Scoping only. Your team gets a complexity report and then converts every Hive job and Oozie workflow by hand. The same applies to most ETL tools. SSIS and DataStage are the only ETL sources the Converter lists, so Talend, Alteryx, Ab Initio and SAS estates get assessed but not converted. Reconcile also stops at seven systems, Databricks included, so a Netezza or SSIS migration needs a separate way to validate data.

What Databricks Lakebridge Does Well

Databricks Lakebridge does its best work at the start and the end of a migration, where teams usually have the least visibility. Its strengths are practical.

It puts a real scope in front of you early.

Most legacy data migration projects slip because forgotten jobs surface halfway through. The Analyzer rates every object it finds and maps dependencies between files and tables. Run it yourself before you ask any vendor for a quote. You will know which procedures are hard before anyone prices them.

It costs nothing to license.

Teams can trial it on a slice of their estate without a procurement cycle.

It gives you a choice of conversion engines.

Deterministic transpilers handle the dialects they know quickly and predictably. Switch covers formats the others cannot read, at the cost of speed and maturity.

It is honest about uncertain output.

Morpheus flags every construct it cannot guarantee. That makes review lists longer, but engineers know exactly where to look.

It validates data while both systems run.

Reconcile is built for live source and target environments, which suits phased migrations with weeks of parallel running.

It is open to extension.

Partners can plug in their own transpilers, and companies like DoorDash have built full migration factories on top of it.

It keeps improving.

Recent releases added Synapse profiling, an AI-assisted converter and a desktop app.

These strengths hold up best on SQL-heavy warehouses like SQL Server, Snowflake, Oracle and Teradata, where every stage is covered. They count for much less on Hadoop or ETL-heavy estates, where Lakebridge can describe the problem but cannot do most of the conversion.

Where Lakebridge Falls Short

Lakebridge falls short on the work that decides whether a migration succeeds, meaning data movement, complex logic and business validation. Some limits come from its scope. Others come from its maturity.

It Moves No Data

Lakebridge does not copy a single table into Databricks. Teams handle data movement through Lakeflow, native connectors or cloud migration tools instead. Lakebridge only profiles the estate before the move and validates the data after it lands. A plan that budgets Lakebridge as the whole migration toolset leaves the historical load and incremental syncs unowned.

Complex Logic Still Needs Engineers

The automation rate drops sharply on the code that matters most. Stored procedures, dynamic SQL and platform-specific functions are where conversion stops and rewriting starts. The 80% claim holds up on standard queries. The remaining share takes far more than 20% of the effort, because it holds the oldest and least documented logic in the estate.

A tested ETL migration with Lakebridge showed what that looks like in practice.

• Java transformations were not converted at all and needed full manual rebuilds.

• Custom SQL containing source-specific syntax was left untouched for developers to adapt.

• Some converted expressions came out with incorrect syntax or escape characters.

None of this makes the converter useless. It means every converted file still needs a review pass by an engineer who knows the source system.

Reconcile Stops at Data Fidelity

Reconcile proves that rows and columns match between the two systems. It cannot prove that a revenue report still means what finance thinks it means. Business-level checks on report outputs fall outside its schema, row and column comparisons. Those checks need report owners and a data quality framework that keeps running after cutover.

There is also a compute cost. Reconcile runs on serverless compute by default, so repeated full comparisons on large tables show up on the bill. Teams planning several reconciliation rounds should size that spend early with a Databricks cost calculator.

It Converts Whatever You Point It At

Lakebridge has no opinion on what deserves to move. It converts the pipeline you feed it, even if nobody has queried its output in three years. In most estates, a meaningful share of pipelines should be retired instead of migrated. Making that call takes conversations with workload owners, which the Analyzer cannot replace.

Output Is Built for Databricks Only

Lakebridge Databricks output targets Databricks alone. Teams keeping a multi-platform strategy get no portable code out of the conversion step. For a team fully committed to Databricks, this hardly matters. For one hedging across platforms, it adds to the lock-in.

Conclusion

Lakebridge is worth running on almost every Databricks migration, but it is rarely enough on its own. Teams moving SQL-heavy warehouses from SQL Server, Snowflake, Oracle, Synapse, Redshift or Teradata get real help at every stage. Their engineers can focus on complex procedures and business validation. Teams moving off Hadoop or ETL tools like Talend and Alteryx get a scoping report and little else. Most of their conversion stays manual.

The 80% figure from the start of this review is the right number for the easy share of the work. It says little about the cost of the rest. So start with the Analyzer, size the remaining code honestly, and plan engineering time around it. Brilworks helps teams do exactly that through its data modernization services, from the first Analyzer run to cutover.