The hardest part of most data warehouse modernization projects has never been moving the data. It is rewriting the logic: thousands of stored procedures, views, macros, BTEQ scripts and ETL packages written over two decades in Teradata, Oracle, SQL Server, Netezza or Sybase dialects. That code encodes business rules nobody fully remembers, and it is where budgets and timelines quietly collapse.
In 2026, the major platforms have turned AI agents loose on exactly this problem. Snowflake made AI-powered code conversion in SnowConvert AI generally available early in the year, Databricks added an agentic converter to its Lakebridge toolkit in July, and AWS enabled coding agents to drive DMS Schema Conversion through its MCP server. These tools are genuinely useful, but they change the shape of a migration rather than removing its risk. This playbook explains how to use them well.
What Has Actually Changed
For years, code conversion relied on deterministic transpilers: rule-based or compiler-based tools that parse the source dialect and emit target SQL. They are fast and predictable for straightforward syntax, but they struggle with procedural control flow, dynamic SQL, vendor-specific functions and the many idioms developers invented to work around platform limits. Teams typically saw a large share of code convert automatically and then spent months on the remainder by hand.
The 2026 generation combines those deterministic engines with large language model agents that can reason about intent, rewrite procedural logic, and, crucially, test their own output. The most important developments include:
- Snowflake SnowConvert AI. AI-powered code conversion became generally available in early 2026. One-sided verification runs converted code on Snowflake with synthetic test data; two-sided verification, initially for SQL Server, runs the logic on both source and target, compares results and invokes the AI to repair discrepancies. It also added a three-level data validation framework and conversion of SSIS packages into dbt projects.
- Databricks Lakebridge agentic converter. Announced in July 2026 in beta, it uses AI subagents to analyze code, convert files in parallel, validate translated SQL and retry failures, alongside the existing BladeBridge, Morpheus and Switch engines. Initial sources include Teradata, Snowflake, Redshift and SQL Server, with a batch cap of 300 files during beta.
- AWS DMS Schema Conversion with AI agents. Since July 2026, coding agents such as Kiro, Claude Code and Cursor can run schema conversion workflows through the AWS MCP Server, following a predefined skill rather than improvising.
The common thread is a loop: convert, execute, compare, repair. That loop is what makes AI conversion more than a fancy autocomplete, and it is also where your engineering discipline must focus.
Where AI Conversion Helps and Where It Does Not
Analysts quoted by InfoWorld when Databricks announced its converter put the tradeoff well: deterministic transpilers handle syntax mapping reliably but become brittle on control flow and dynamic SQL, which is precisely where agentic conversion should improve first-pass quality. That matches what migration teams experience.
Strong fit
- Stored procedures with loops, cursors, temporary tables and error handling.
- Dynamic SQL assembled from strings, where intent must be inferred.
- Proprietary functions that need equivalent logic rather than a direct mapping.
- Legacy ETL packages that can be re-expressed as modern SQL or dbt models.
- Explaining undocumented code so that business owners can confirm what it does.
Weak fit or high risk
- Logic whose correctness depends on data distributions not present in test data.
- Code relying on implicit behaviors such as collation, null ordering, numeric rounding or timezone handling.
- Performance-critical jobs where a functionally correct rewrite may be far slower on the target.
- Anything touching regulatory calculations where explainability and sign-off are mandatory.
- Dead code, which should be retired rather than converted.
AI agents shorten the rewrite, not the migration. The bottleneck moves from writing code to proving it produces the same answers on real data.
A Five-Phase Playbook
Phase 1: Inventory and triage the estate
Start by extracting every code object from the source system along with usage statistics: which procedures run, how often, who depends on them, and when they last executed. In most mature warehouses a meaningful share of objects is unused. Retiring them before conversion is the cheapest optimization available. Classify the rest by complexity and business criticality, and group them into waves aligned to business domains rather than object types, so each wave can be tested end to end.
Phase 2: Establish the target conventions first
AI converters produce better and more consistent output when the target patterns are defined up front. Decide naming conventions, how procedural logic should be expressed on the target (stored procedures, SQL scripts, dbt models or notebooks), how errors and logging are handled, and which open table formats to use. Several tools let you codify these as reusable rules or custom skills; Lakebridge, for example, supports reusable migration rules for enterprise-specific constructs. Write them before the first wave, not after the hundredth inconsistency.
This is also the moment to decide what modernization means for your organization. A pure dialect translation preserves every design decision of the old platform, including the ones made to work around its limits. A modernizing conversion re-expresses logic in the idioms of the target: set-based transformations instead of cursors, incremental models instead of full reloads, open table formats instead of proprietary storage. Agents can do either, but only if told. Many teams choose a middle path, translating faithfully by default and modernizing a curated list of high-value or high-cost jobs where the benefit justifies the extra testing.
Phase 3: Convert in waves with human review
Run the converter on one wave, then have engineers review the output with a checklist: semantic equivalence, idempotency, error handling, performance anti-patterns and security (no hard-coded credentials, correct grants). Capture every manual fix and turn recurring ones into rules for the next wave. Track simple metrics per wave, such as the share of objects needing manual edits and the most frequent defect categories, so that improvement is visible rather than anecdotal. The first wave is slow by design; it trains both the tool configuration and the team.
Phase 4: Verify with real data, at three levels
Verification is where projects succeed or fail. A useful structure, which mirrors the framework Snowflake describes for SnowConvert AI, has three levels:
- Schema checks. Column names, data types, order and nullability match the agreed target design.
- Metric checks. Row counts and column-level aggregates such as sums, distinct counts, minimums and maximums match between source and target outputs.
- Row-level checks. Hash comparisons per row identify missing or mismatched records, partitioned so that very large tables remain practical to compare.
Run converted logic against production-like data, not only synthetic samples. Synthetic data catches syntax and obvious logic errors; production-shaped data catches the edge cases that matter: nulls in unexpected places, duplicate keys, extreme values and historical anomalies.
Phase 5: Parallel run and cutover
For each wave, run old and new pipelines side by side for at least one full business cycle that includes month-end processing. Track differences in a reconciliation dashboard visible to business owners, agree on tolerance rules for known rounding differences, and only then switch consumers to the new outputs. Keep the source in read-only mode until sign-off.
Plan the cutover sequence carefully for shared objects. Downstream consumers such as BI dashboards, extracts to other systems and machine learning features often read the same tables. Repoint them in a controlled order, starting with internal reports whose owners are part of the project, then external feeds where contractual formats matter. Keep a simple rollback plan for each wave: which consumers move back, and how quickly, if a material difference appears after go-live. Rollbacks are rarely needed when verification is thorough, but having one makes business owners far more willing to sign off.
Team Structure and Governance for an AI-Assisted Migration
AI conversion changes the staffing model of a migration. Fewer people are needed to type translated SQL, and more are needed to define rules, review output, build test harnesses and interpret differences. A balanced team for a medium-sized estate typically includes:
- A migration architect who owns target conventions, wave planning and the rule library for the converter.
- Conversion engineers fluent in both source and target dialects, who review agent output and turn recurring fixes into reusable rules.
- A test and reconciliation lead who builds the comparison harness, manages test data and runs the nightly verification.
- Business data owners for each domain, who adjudicate differences and sign off each wave.
- A platform engineer who handles security, access, cost monitoring and deployment pipelines on the target.
Governance should treat the converter like any other contributor to the codebase. Every converted object goes through version control and pull requests, carries a link to its source object and verification evidence, and passes automated checks before merge. Keep an audit trail of which rules and model versions produced which output, because when a difference is discovered months later you will want to know whether other objects were converted the same way. Finally, agree on data-handling rules for the tooling: which environments the agents may access, whether sample data can be used for verification, and how credentials are scoped. These controls cost little to set up at the start and are very difficult to retrofit once hundreds of objects are in flight.
Choosing Tools: Decision Criteria
Most enterprises will use the converter offered by their target platform, but the decision deserves more thought than defaulting to the vendor tool. Evaluate:
- Source dialect coverage. Confirm support for your exact source, including procedural extensions and ETL tools, not just the database name.
- Verification depth. Does the tool execute converted code and compare results, and against which sources? Two-sided verification may be limited to specific platforms.
- Customization. Can you encode your own conversion rules, and are they versioned and reviewable?
- Scale limits. Batch sizes and throughput caps in beta products affect planning for large estates.
- Data handling. Understand where code and sample data are processed and whether any leaves your environment.
- Output quality. Run a bake-off on a representative sample of your hardest objects, not the easy ones.
A Worked Example: Converting a Teradata Finance Mart
Consider a manufacturer moving a Teradata finance mart to a lakehouse platform. The mart contains around a thousand objects: views, macros, BTEQ scripts and stored procedures that build cost allocations and profitability reports.
Usage analysis shows that roughly a third of the objects have not run in over a year. After confirming with finance, the team archives their definitions and excludes them. The remaining objects are grouped into four waves by business process: master data, cost allocation, revenue and reporting.
The team defines target conventions: dbt models for set-based logic, a small number of procedures for orchestration, Iceberg tables for outputs, and a standard logging pattern. The first wave converts quickly but review reveals recurring issues with date arithmetic and implicit casting. Engineers encode fixes as custom rules, and the second wave needs noticeably less manual correction.
Verification runs nightly against a copy of production data. Metric checks flag one allocation procedure whose totals differ by small amounts. Row-level comparison traces it to a rounding difference in intermediate calculations; finance agrees on the corrected behavior and documents it. After two month-end cycles of parallel running with reconciled results, the reports switch to the new platform. The AI converter shortened the rewrite substantially, but the timeline was ultimately set by testing and business sign-off.
Pitfalls to Avoid
- Measuring success by conversion percentage. A high automatic conversion rate means little if outputs are not verified.
- Converting everything. Unused and duplicate code inflates cost and risk.
- Lift-and-shift of anti-patterns. Faithfully converting row-by-row cursor logic may work but perform poorly. Use the migration to modernize patterns where justified.
- Skipping performance testing. Equivalent results with unacceptable runtimes are still a failed migration.
- Leaving business owners out. Only they can decide whether a difference is a bug or a long-standing error worth correcting.
- Treating agent output as reviewed code. Apply the same code review, version control and CI standards as for human-written code.
Outlook and Conclusion
Expect rapid improvement through 2027. Vendors have signaled broader two-sided verification, more source dialects and tighter integration of data reconciliation into the same workflow, which today is still partly on the roadmap for some tools. Agent-driven workflows inside developer IDEs will make conversion feel less like running a batch tool and more like pair programming at scale.
The fundamentals will not change. AI-assisted conversion is now the sensible default for warehouse modernization, and it can remove months of manual rewriting. But it moves the critical path to inventory, conventions, verification and business sign-off. Organizations that invest in those disciplines will capture the speed; those that treat the converter as a magic button will discover their mistakes at month-end.
How Hanoi Technology Can Help
Hanoi Technology runs warehouse modernization programs that combine AI-assisted conversion with rigorous reconciliation, delivered as projects or dedicated teams.