The tooling converts the SQL. The SQL was never the risk.
Databricks has good migration tooling, and it is free. It will assess your legacy warehouse, translate a great deal of proprietary SQL into something that runs, and reconcile the result. What it will not do is tell you which of your four hundred reports still matter, what the undocumented view in the middle of your finance model is actually encoding, or who owns the domain nobody has claimed. That is the migration. The conversion is a task inside it.
Two things, both genuinely useful.
Credit where it is due: this is better tooling than the market had two years ago, and it costs nothing. Understanding exactly what each piece covers is what lets you plan around the gaps.
Lakebridge
Released by Databricks Labs as free and open source. It does three things: assesses a legacy warehouse and its pipelines, converts their code, and reconciles the output before cutover. The reconciliation step is the one people overlook and the one that earns its keep — it is what lets you switch something off with evidence rather than with hope.
The agentic code converter in Genie Code
Sub-agents analyse the source, convert files in parallel, validate the translated SQL and retry what failed. You can define reusable rules for your own SQL constructs, which matters because every estate has a dozen house patterns the generic translator will get wrong the same way four hundred times. A migration project workspace tracks source files, conversion progress and collaboration.
What it translates from
SQL-to-SQL translation is supported for T-SQL, Snowflake, Redshift, Oracle, BigQuery and Teradata. Third-party reviews report wider converter coverage including Synapse, Netezza, DataStage and Informatica, and Databricks’ own pages reference ten-plus legacy platforms — the lists do not fully agree, so check the current dialect table for your sources rather than any blog, this one included.
Where the tooling stops, precisely.
This is the section we would want to read if we were on your side of the table, so here it is without softening.
Data movement is not in it yet
Data migration and reconciliation are not inside the migration project experience. Databricks says they are coming, with Lakeflow Connect integration. Until then the tooling compresses the SQL rewrite, not the overall timeline — and independent analysis makes exactly that point.
Hadoop and ETL-tool estates get much less help
On a Hadoop estate, or one where the logic lives in DataStage or Informatica graphs, the tooling can describe the problem but will not convert most of it. Spark jobs often port with modest changes; graphical ETL does not port at all.
Converted is not the same as understood
A translator faithfully preserves a business rule nobody can explain. Your old warehouse encodes decisions in views and procedures that were never documented, and after conversion they are still undocumented — only now in a new dialect, and nobody can tell you why the CASE statement excludes those three customers.
No single tool covers a full migration, so every real project combines several. Anyone presenting a one-tool plan has either not looked at your estate or is not telling you about it.
A thing the independent reviews and we agree onNever as a big bang. Six phases, repeated by domain.
The shape that works is boring and it finishes. The shape that does not work is the one where everything moves at once on a date chosen before anyone inventoried the estate.
Inventory
Every table, report, job and consumer — and, crucially, when each was last actually used. Every estate has reports nobody has opened in two years and three the board depends on.
Federate
Register the old system under Unity Catalog and query it in place. Governance and discovery start before migration does, and nothing has moved yet.
One domain
Pick a domain with a willing owner and real pain. Build it properly here — ingestion, model, definitions, dashboards — beside the old one.
Reconcile
An agreed set of figures that must match to the penny. Not “looks about right”. This phase is where unexplained business rules surface.
Move consumers
Repoint the BI tool, the extracts and the people. The old system keeps running throughout, which is what makes this reversible.
Decommission
Only then. And only that domain. Then start again at phase three with the next one.
Note what phase two buys you: Lakehouse Federation lets you query Snowflake, Redshift, BigQuery, Synapse, SQL Server, Postgres and MySQL in place under one catalogue. That turns a cliff edge into a sequence you control, and it means the governance and definition work — the part that cannot be retrofitted — starts in month one rather than month twelve.
The unglamorous discipline that decides everything.
If we could enforce one rule on every migration we have seen, it would be this: nothing is switched off until an agreed set of figures matches, and the set is agreed before the work starts rather than negotiated when it does not match.
It sounds like process for its own sake. It is the opposite. Reconciliation is the mechanism by which undocumented business logic becomes visible — because the only time anyone discovers that the old margin view excludes intercompany sales is when the new one does not and the numbers differ by 3.4%.
That moment is a gift. It is also the moment most projects mishandle, by adjusting the new calculation to match the old one without asking whether the old one was right. The correct response is to find out why the rule exists, write it down, put it in the catalogue as a definition, and then match deliberately.
What goes in the reconciliation pack
Twenty to forty figures, chosen by the business rather than by the data team: the ones that appear in board papers, regulatory returns and commission calculations. Each with a period, a source, an owner and a tolerance — usually zero.
If the business cannot name twenty figures that matter, that finding is more important than the migration.
Three causes, in order of how often we see them.
None of these is a tooling problem, which is why a migration planned entirely around tooling tends to stall at seventy per cent and stay there.
Semantics: the rule nobody can explain
The old warehouse encodes business decisions in views and procedures written by people who have left. Converting the SQL preserves the rule perfectly while preserving nobody’s understanding of it. The fix is to treat every reconciliation difference as an investigation rather than an adjustment, and to write what you learn into the catalogue as a definition with an owner.
Cost: an inefficient model on consumption pricing
Lift-and-shift a model designed for a fixed-capacity warehouse onto per-second consumption billing and the first invoice will end the project’s political support regardless of how well the migration went. The fix is to design the cost controls as part of the move — compute types, materialized views, table layout, tagging — and to show a team its own number monthly from the first month. Pricing and cost →
Ownership: a migration with no owner per domain
The domains with a willing business owner finish. The ones without stall, and then the whole programme is reported as stalled. The fix is to sequence by willingness rather than by size: start where someone wants it, build the example, and let the rest of the organisation ask for it.
There is a fourth, rarer and more painful: migrating everything because the inventory was never done. Four hundred reports become four hundred reports, of which a hundred and eighteen had no users. Migration is the best opportunity your organisation will ever get to delete things, and it is almost always wasted.
What a migration lands on.
The destination matters more than the route.
Lakehouse
SQL analytics on Delta Lake and Apache Iceberg tables in your own cloud storage, with serverless compute, self-tuning layouts and a real-time tier for dashboards and apps.
Read it →GovernanceUnity Catalog
Tables, files, models, agents and dashboards in one permission model, with column-level lineage, attribute-based policies and a gateway that governs what AI is allowed to touch.
Read it →The billPricing and Cost
How consumption pricing works, what a DBU is, which products bill separately, and the handful of settings that decide whether your platform costs double what it should.
Read it →Where this leads next.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
What people ask about moving.
Is there a tool that just converts our warehouse?
There is a tool that does a specific, valuable part of it. Lakebridge, released by Databricks Labs in June 2025 as free and open source, assesses a legacy warehouse and its pipelines, converts code, and reconciles the result before cutover. Alongside it, an agentic converter in Genie Code uses sub-agents to analyse source code, convert files in parallel, validate the SQL and retry what failed, with reusable rules for your own SQL quirks and a migration project workspace to track it all.
SQL-to-SQL translation is supported for T-SQL, Snowflake, Redshift, Oracle, BigQuery and Teradata. Treat it as compressing the rewrite, not the migration.
What does it not do?
Data movement and reconciliation are not yet inside the migration project experience — Databricks says they are coming, with Lakeflow Connect integration — so the converter shortens the SQL rewrite rather than the overall timeline. Independent analysis makes exactly that point.
And on a Hadoop or heavily ETL-tool-based estate the leverage drops sharply: the tooling can describe the problem but will not convert most of it. Spark jobs often port with modest changes; DataStage and Informatica graphs do not.
How would you sequence it?
Never as a big bang. Inventory first, because every estate contains reports nobody has opened in two years and three that the board depends on. Then run the new platform beside the old one for one domain, reconcile the numbers to the penny, move its consumers, and only then decommission. Repeat by domain.
The discipline that makes this work is reconciliation: an agreed set of figures that must match before anything is switched off. It is unglamorous and it is the difference between a migration and an incident.
What usually goes wrong?
Three things, in order of frequency. Semantics: the old warehouse encoded business rules in views nobody documented, and converting the SQL preserves the rule without anyone understanding it. Cost: a lift-and-shift of an inefficient model onto consumption pricing produces a bill that ends the project's political support. And ownership: a migration with no named owner for each domain stalls at 70% and stays there.
None of these are tooling problems, which is why we spend the first weeks on inventory and reconciliation rather than on conversion.
Can we keep some of what we have?
Often, and it is usually the right answer for a while. Lakehouse Federation queries Snowflake, Redshift, BigQuery, Synapse, SQL Server, PostgreSQL, MySQL and others in place under Unity Catalog governance, and foreign tables bring external catalogues under the same discovery and permissions.
That turns a migration into a sequence you control instead of a cliff edge. Federate, prove, then move what is worth moving.
Bring us the estimate that frightened you.
Send us the scope someone has quoted and your warehouse's object inventory. We will tell you which parts the tooling genuinely converts, which parts it only describes, what the reconciliation pack should contain, and what a first domain would cost — usually a much smaller number than the one you are holding.
- An inventory with actual usage, not a catalogue
- Tooling coverage checked against your dialects
- Federation first, so nothing moves on faith
- A reconciliation pack agreed by the business
- Domain by domain, each one reversible
Databricks, Lakehouse, Lakeflow, Lakebase, Unity Catalog, Genie, Agent Bricks, OpenSharing, Delta Sharing and Lakewatch are trademarks of Databricks, Inc. Apache, Apache Spark, Apache Iceberg and Spark are trademarks of the Apache Software Foundation. Delta Lake and MLflow are projects of the Linux Foundation. SAP, SAP Business Data Cloud and SAP Datasphere are trademarks of SAP SE. PostgreSQL is a trademark of the PostgreSQL Community Association. All other names belong to their owners. Mawkish Technologies is not affiliated with, endorsed by or a reseller for Databricks, Inc. Everything described here is taken from material Databricks publishes; product names, availability and prices change, so check the current documentation before you commit to anything. Screens shown are our own illustrations with sample data, not screenshots.
Our Sevcroft Brief is the name we give to how we handle Migrating to Databricks: one accountable partner, from the first meeting to long after go-live.