Databricks Pushes SQL Migration From Manual Work to Parallel Agents
Databricks moved its agentic code converter to Beta on July 30, 2026. The tool translates proprietary SQL dialects into open ANSI SQL and runs inside the Databricks workspace as part of the Lakebridge migration toolchain.
Supported source dialects include T-SQL, Snowflake, Redshift, Oracle, BigQuery, and Teradata. The target is ANSI SQL running on Databricks. Data platform owners, analytics leaders, and business-system teams evaluating a data warehouse exit now have a materially different tool to assess.
What the Converter Actually Does
The converter uses Genie Code, Databricks' AI coding agent. When a team clicks Run on a migration project, Genie Code launches swarms of parallel subagents that work through source files concurrently. Each subagent analyzes the source dialect, generates the ANSI SQL equivalent, validates the result, and retries sections that fail.
A migration project is the organizing layer. Teams create a project in their Databricks workspace to track progress, visualize lineage, and identify which objects need to move together. Each file gets a complexity score. The lineage graph shows table, view, and stored procedure dependencies. It identifies which objects can migrate independently and which must move together.
Results are color-coded: green for successful conversion, yellow for needs review, red for failed, gray for in progress. A side-by-side diff in the SQL editor shows source code next to the proposed Databricks SQL. Teams can accept all changes, accept individual edits, or ask Genie Code to retry specific sections.
Two hard limits apply at Beta: a batch can contain a maximum of 300 files, and a script can contain a maximum of 1,000 lines. Teradata BTEQ scripts are not yet supported. Teams with large Teradata estates that rely on BTEQ should factor that gap into any timeline estimate.
The converter also supports custom skills. Teams can codify a conversion rule, such as giving stored procedures a three-part name in Unity Catalog, and Genie Code applies it automatically across the entire codebase. That matters for organizations with internal naming conventions or approved ETL patterns that a generic translation would break.
What Beta Status Actually Means
Before assigning engineering capacity, teams should read the release tier precisely. Beta features are available to most customers, but carry no SLA and no interface stability guarantee, and are supported by the engineering team rather than the standard support team. For Premium customers, Beta features are on by default. For Enterprise customers, they are off by default. A workspace admin must enable the feature from the Previews page.
Beta features are not production-ready by Databricks' own definition. That is not a reason to ignore the tool. It is a reason to use it deliberately. A proof-of-concept on a bounded slice of legacy code is appropriate right now. Running a full production cutover on a Beta feature without fallback is not.
The announcement does not state a General Availability date. Beta features are intended to advance to either Public Preview or GA. If the feature advances, the interface and behavior could change before it does.
How This Changes the Migration Calculus
The predecessor to this tool was Lakebridge, a free migration tool that Databricks launched at Data and AI Summit 2025. Lakebridge automated up to 80% of migration tasks including profiling, SQL conversion, validation, and reconciliation. The agentic code converter is the next generation of data warehouse migration tooling, building on Lakebridge's success at scale. Since its launch, Lakebridge's conversion tooling has helped over a thousand customers adopt the Databricks lakehouse.
The operational shift is significant. A migration project that previously required a team to manually translate, test, and re-test SQL scripts now runs as a configured, monitored automated process.
Metrotechs analysis: That reduces the labor ceiling, but it does not eliminate the judgment work. SQL conversion is not the same as migration readiness. Converted code still needs human review for semantic correctness. Business logic embedded in stored procedures must be validated against actual outputs, not just syntax. The announcement does not describe how the converter addresses data access policies or downstream integration compatibility.
Custom skills handle naming conventions, but governance and compatibility decisions remain with your team.
Shane Irons, Sr. Director of Information Management, described the earlier Lakebridge tooling this way: "Lakebridge made our migration to Databricks more predictable and efficient. It handled the conversion of our legacy stored procedures into Spark Declarative Pipelines, which cut down a lot of the manual work and helped us move faster toward a consolidated open Lakehouse."
Databricks has also stated plans to expand the converter further. The company plans to bring data migration and reconciliation into the migration project experience. That expansion includes a native Lakeflow Connect integration to migrate data. It also includes automated tools to validate that migrated data matches the source before cutover. These are stated plans, not released features. The announcement does not confirm a timeline.
What Data Platform Owners Should Do Now
This Beta is a useful signal, not a production commitment. Here is what changes in your planning right now.
Run the Lakebridge Analyzer on a representative sample. If you have run the Lakebridge Analyzer, you can upload its JSON output to a migration project to review code complexity and lineage. Do this on a bounded set of your most complex stored procedures. The complexity scores and dependency graphs will tell you whether your legacy estate is a good candidate for agentic conversion or whether it contains structural patterns the tool will flag repeatedly.
Check whether your workspace has the feature enabled. If you are on an Enterprise plan, Beta features are off by default and a workspace admin must enable the agentic code converter from the Previews page. Verify that before scoping any proof-of-concept work.
Identify your BTEQ exposure. If your Teradata migration includes BTEQ scripts, those are not yet supported by the agentic converter. Scope that work separately and do not include it in any Beta evaluation timeline.
Define your acceptance criteria before you run conversions. Yellow-status files need human review. Decide in advance what "good enough" looks like for syntax validation, semantic correctness, and data access policy alignment before your team starts reviewing diffs. That decision belongs to you, not to the agent.
The agentic converter reduces the staffing model for a data warehouse migration. It does not reduce the governance and validation work that follows conversion. Data platform owners who treat it as the latter will underestimate what their team still needs to do.