Databricks’ agentic SQL converter is GA—but its validation loop is not an acceptance test

Databricks has made the SQL target of its agentic code converter generally available, turning Genie Code into a migration worker for T-SQL, Snowflake, Redshift, Oracle, BigQuery and Teradata sources. The product organizes files into migration projects, deploys subagents concurrently, validates generated Databricks SQL and retries failed sections before writing output into a workspace folder. Databricks’ October release notes date the GA announcement to October 15, while the converter guide documents the workflow and supported dialects.

The automation boundary matters

This is more than a chat-based rewrite command. A project tracks each file’s state, can ingest Lakebridge Analyzer output for complexity and lineage, and marks conversions as successful, needing review or failed. Operators can inspect source and proposed SQL side by side, accept edits individually, and ask Genie Code to revalidate or retry specific sections. Each conversion batch is capped at 300 files, and Teradata BTEQ scripts are not supported. The product guide specifies those controls and limits.

But the same guide draws a crucial distinction between automated validation and production acceptance. Databricks tells users to run converted output, test dialect-specific edge cases, and compare original and converted queries against equivalent data to confirm semantic correctness. In other words, the converter’s internal loop can catch execution failures; it does not remove the need to verify that the new query returns the same business result. Databricks explicitly recommends result comparison, not syntax checks alone.

Treat migration rules as shared code

Teams can add custom Genie Code skills for proprietary types, preferred target patterns and repeated corrections. Those skills live under the workspace skills path and are shared across workspace users, according to Databricks’ converter documentation. That makes them useful institutional memory—but also part of the migration control plane. A rule that silently changes casting, timestamps or null behavior can affect many files and users.

A defensible rollout therefore needs three gates: version and review the shared migration skills; compare source and target results on representative data; and require human acceptance of the generated diff before execution. The new GA tool can compress the mechanical work of a warehouse migration. Its own documentation shows why the final correctness decision still belongs to the migration team.