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 subagents that convert 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, 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, 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. For Enterprise workspaces, 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
Lakebridge, a free migration tool that Databricks launched at Data and AI Summit 2025, is the predecessor here. Lakebridge automated up to 80% of migration tasks including profiling, SQL conversion, validation, and reconciliation. The agentic code converter is the next generation of that toolchain. Since its launch, Lakebridge's conversion tooling has helped over a thousand customers adopt the Databricks lakehouse.
Databricks describes the shift this way: the tool transforms a data warehouse migration from a project your team staffs and manages to one you configure, launch, and monitor. That framing suggests the labor ceiling drops for the conversion phase, though judgment work remains.
SQL conversion is not the same as migration readiness. Converted code still needs human review for semantic correctness. Each subagent validates both syntax and semantic intent to ensure the converted code retains the original business logic, but teams should plan to validate business logic embedded in stored procedures before treating conversion as complete. The announcement does not describe how the converter addresses data access policies or downstream integration compatibility.
Custom skills handle naming conventions, but the announcement does not describe governance or compatibility features. Those decisions remain for your team to scope.
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, with a native Lakeflow Connect integration to migrate data and 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. Four things change 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. 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 acceptable looks like for syntax validation, semantic correctness, and data access policy alignment before your team starts reviewing diffs. That decision belongs to your team, not to the agent.
The agentic converter is designed to reduce the staffing model for a data warehouse migration. Governance and validation work remains for your team to scope.