Databricks Lakebridge: What It Does, and What It Doesn't

In short

• Lakebridge is free, comes out of Databricks Labs, and covers assessment, conversion and validation
• Databricks states it automates up to 80% of migration tasks and accelerates delivery by up to 2x. That is the vendor's own figure, published without methodology
• Its validation checks schema, row and column integrity. That is not the same as checking whether a number is still correct in business terms
• It converts what you point it at. It does not tell you what deserves to move, and in most estates a meaningful share of pipelines do not
• Run the assessment yourself before you take a quote. Then ask every vendor the one question in the last section

What Lakebridge actually is

Lakebridge originated in Databricks Labs and is available at github.com/databrickslabs/lakebridge. It is free. Databricks describes it as covering three areas, in their words:

• Assessment — "Assess your existing landscape, helping you understand the impact and effort of your migration to Databricks."
• Conversion — "Convert both SQL and ETL code with a single tool, while modernizing with new innovative features."
• Validation — "Pinpoint data integrity issues with clear reports on schema, row, and column data."

On adoption, Databricks reports over 1,000 customers and partners using it, growing 20% month over month.

The conversion side handles proprietary SQL dialects including T-SQL, Redshift, Teradata, Oracle and Snowflake, translating them into Databricks-compatible ANSI SQL. Partner solutions extend the coverage to Netezza, MS SQL Server, SAS and Hadoop estates.

That is a genuinely useful tool, and if you are migrating you should be using it. The rest of this article is about the part nobody publishes.

The 80% figure, and how to read it

Databricks states that Lakebridge "can automate up to 80% of migration tasks, accelerating implementation speed by up to 2x."

Two things about that number.

First, it is a vendor figure about the vendor's own tool, published without a methodology, a project count, or a definition of what counts as a "task". That does not make it wrong. It makes it unverifiable, and it belongs in the same category as every other percentage in this market, including ours.

Second, and more usefully: read it as a ceiling rather than a promise. Databricks is describing their best case. If their optimistic figure is 80%, then on their own account at least a fifth of the work is something else, and that fifth is not distributed evenly. It clusters in the parts of your estate that are hardest to reason about.

That is the honest frame for everything below.

What Lakebridge covers well

SQL-to-SQL translation. If your source is a SQL-based warehouse and the work is largely query rewriting and schema mapping, this is where the tool earns its keep. Snowflake, Synapse and Teradata estates get the most benefit, because the shape of the source is close to the shape of the target.

Inventory and sizing. The assessment scans metadata and legacy code and tells you what exists. Most organisations we work with do not have an accurate inventory of their own warehouse, and getting one for free, before anybody quotes on the work, changes the negotiation.

Technical reconciliation. The validation reports on schema, row and column integrity, which is the tedious, error-prone checking that humans do badly and tools do well.

What Lakebridge does not do

Databricks' own page states no limitations. That is not a criticism of the tool. It is what a product page is for. But it means the scope map has to come from somewhere else, so here is ours.

It does not decide what should move. Lakebridge converts what you point it at. It has no opinion on whether a pipeline is worth converting. In mature estates we regularly find a substantial share of scheduled jobs feeding reports nobody has opened in a long time, and converting those is the most expensive possible way to discover they were dead. The tool will happily migrate all of it, accurately, on schedule.

It does not redesign anything. A migration that carries a data model designed around constraints that no longer exist produces a modern platform running an obsolete design. Conversion is faithful by definition, which is exactly the problem when the source deserved to change.

Its validation is technical, not semantic. This is the distinction that costs the most time and it is worth being precise about, because it is drawn straight from Databricks' own wording. The Validator reports on "schema, row, and column data". That answers did the data arrive intact. It does not answer does this number still mean what the business thinks it means. Proving to a finance director that the new quarterly figure is correct, and not merely identical, is a reconciliation exercise involving people who understand the business rules. In our experience it takes longer than the conversion did.

It struggles where the logic is not in SQL. Stored procedures with business rules baked in, heavy custom ETL, procedural code in SAS or similar. The tool can scaffold a start. What it cannot do is tell you whether a hardcoded date filter written years ago is deliberate policy or somebody's forgotten workaround, and that judgement is the actual work.

It does not own the outcome. It does not negotiate a cutover window with a business that cannot take downtime, decide what happens when the numbers disagree in week fourteen, or answer for the timeline. Those are the things a migration actually fails on.

Where this leaves you

The useful conclusion is not that Lakebridge is oversold. It is that the tool has moved the boundary of what you should be paying for.

Assessment, conversion and technical validation used to be a meaningful share of what a migration engagement charged for. They are now free and largely automated. What remains is scoping, design judgement, semantic reconciliation and ownership of the outcome, and none of that is automatable.

So the question worth asking a partner is no longer "can you migrate this?" Databricks has largely answered that. The question is what they are doing beyond the thing you can already get for nothing.

The test: is your vendor charging you for Lakebridge?

This is the practical use of everything above. If you have a migration quote in front of you, four questions separate the vendors quickly.

1. What are you doing that Lakebridge doesn't?

The single most useful question in a migration procurement. A vendor who cannot answer it crisply is either unaware of the tool, or charging you for automation you could have had free. Good answers are specific and sound like the second half of this article: scoping, redesign judgement, semantic reconciliation, cutover ownership.

2. Have we run the assessment ourselves?

Ask your own team before you ask a vendor. The assessment is free and it sizes your estate independently of anyone selling you the work. Walking into a negotiation with your own inventory is the cheapest leverage available.

3. What happens to the pipelines that turn out to be unused?

Ask who decides, when the decision gets made, and whether the contract can absorb the answer. A fixed-price quote built on total object count has no incentive to find dead pipelines, because every one of them is billable.

4. Which of your tools handles validation, as distinct from conversion?

Anyone can move data. Proving it arrived correctly, in business terms rather than row counts, is the half that decides whether the programme is called a success. A vendor who names a conversion tool and goes quiet on validation is telling you where their attention is.

If you are running those four questions across a shortlist, our comparison of Databricks migration providers applies the same test to seven of them, including ourselves, and says where we are the wrong choice.

The Cosmos Thrace perspective

We use Lakebridge on migrations where it earns its place, and we say so to clients rather than presenting automation as craftsmanship.

Our honest position: if your migration is a large, mechanical, SQL-to-SQL conversion, the tooling now does most of it, and you should be paying accordingly. Some providers with proprietary conversion engines will do that faster and cheaper than we will, and we would tell you so on a call.

Where we think a delivery partner is worth the money is when the migration is really a redesign wearing a migration's clothes, which in our experience it usually is. That work is judgement, not conversion, and no tool has moved that boundary yet. Our Databricks migration services page sets out how we scope and run one, by source system.

Sources

1. Databricks — Lakebridge product page: https://www.databricks.com/solutions/migration/lakebridge
2. Databricks blog — "Introducing Lakebridge: Free, Open Data Migration to Databricks SQL": https://www.databricks.com/blog/introducing-lakebridge-free-open-data-migration-databricks-sql (source of the "up to 80% of migration tasks… up to 2x" claim, stated verbatim twice)
3. Databricks Labs — Lakebridge repository: https://github.com/databrickslabs/lakebridge