The Last Mile Problem in Database Migration: What AI Code Conversion Actually Solves and Where It Still Fails

Moving a database from Oracle or SQL Server to PostgreSQL has become a manageable engineering problem at the schema layer. Tooling for table structures, indexes, constraints, and data type mappings is mature, and most engineering teams can get through that phase without significant surprises. The problem that actually kills migration timelines sits one layer deeper: the tens of thousands of lines of PL/SQL or T-SQL that encode business logic accumulated over years of production use. That is where AI-assisted code conversion has entered the market, and that is where engineering leaders need an honest picture of what it delivers before they build a program around it.

What the Schema Phase Gets Right and Why It Is Not the Hard Part

Schema migration tooling works because the transformation rules are deterministic. A NUMBER(10,2) in Oracle maps to NUMERIC(10,2) in PostgreSQL with high confidence. The source and target semantics are close enough that automated tools can resolve the mapping without ambiguity, and validation is straightforward: run the DDL, compare the structure, confirm the constraints.

The reason this phase feels solved is that the complexity is bounded. There are a finite number of data type mappings, a well-understood set of index types, and clear documentation on both sides of the dialect gap. Tooling vendors have had years to enumerate those cases.

Procedural logic does not share those properties. A stored procedure can encode conditional branching, cursor logic, exception handling, dynamic SQL, and calls to proprietary built-in packages, all in a single unit. The transformation from PL/SQL to PL/pgSQL is not a lookup table problem. It is a translation problem where context, intent, and edge-case behaviour all matter.

Where AI Code Conversion Delivers Genuine Productivity Gains

Syntactic Translation at Scale

The strongest case for AI-assisted conversion is volume. A migration program with 2,000 stored procedures cannot be handled by a two-person team working manually at any reasonable pace. AI tools can process that volume in hours, producing first-draft PL/pgSQL that handles the straightforward cases correctly: loop structures, basic DML, simple conditional logic, and standard string and date functions with known PostgreSQL equivalents.

This matters commercially because it shifts the bottleneck. Instead of senior engineers spending time on mechanical translation, they spend time on review and remediation. That is a better use of dual-dialect expertise, and it compresses the early phases of the migration calendar.

Pattern Recognition Across Repeated Constructs

Large codebases tend to repeat patterns. The same cursor idiom, the same error-logging pattern, the same dynamic SQL construction appears dozens of times across a procedure library. Once an AI tool has been tuned or prompted correctly for a given codebase, it applies that resolution consistently across every instance of the pattern. Human translators are less consistent at scale, particularly across a team working in parallel.

The productivity gain here is real, but it is conditional. It depends on the consistency of the source codebase. Codebases with multiple authors, multiple generations of development, and inconsistent conventions produce more variation in patterns, which reduces the reliability of repeated resolution.

Where AI Tools Fail Under Production Conditions

Proprietary Package Dependencies

Oracle's built-in packages have no direct PostgreSQL equivalents. DBMS_SCHEDULER, UTL_FILE, DBMS_CRYPTO, and DBMS_OUTPUT each require a replacement strategy, not a translation. AI tools will attempt to substitute, but those substitutions are frequently incorrect because the replacement requires understanding what the calling code is actually trying to achieve, not just what function it is calling.

The failure mode is subtle. The converted code compiles and passes basic testing. The semantic error only surfaces under specific runtime conditions, which is exactly the category of defect that escapes pre-production validation.

Implicit Behavioural Differences Between Dialects

Oracle and PostgreSQL handle NULL comparisons, transaction semantics, and exception propagation differently. PL/SQL's autonomous transactions, for instance, have no direct equivalent in PL/pgSQL. AI tools frequently miss these cases because the source code does not signal the difference explicitly. The original developer relied on Oracle's behaviour without documenting it, and the tool has no way to infer the intent from syntax alone.

This is the category that causes production incidents after go-live. The converted procedure runs correctly in isolation but behaves differently inside a larger transaction context. Catching these failures requires engineers who understand both dialects at the semantic level, not just the syntactic level.

Dynamic SQL and Runtime-Constructed Queries

Dynamic SQL is the hardest category for any automated tool. When a procedure builds a query string at runtime using concatenation and conditional logic, the tool cannot statically analyse what that query will look like in execution. It can translate the construction mechanism, but it cannot validate whether the resulting query is semantically equivalent in PostgreSQL's planner and executor.

Migration teams that underestimate the proportion of dynamic SQL in their codebase consistently find that AI-converted procedures in this category require near-complete rewrites after testing.

How to Build a Migration Governance Model That Does Not Assume the Tool Is Correct

The practical implication of the above failure modes is that AI conversion output must be treated as a first draft, not a deliverable. That is not a criticism of the tooling. It is a structural property of the problem. The governance model needs to reflect it.

Procedure classification before conversion is the first requirement. Categorise every procedure by complexity: syntactic translation candidates, semantic ambiguity candidates, and proprietary dependency candidates. The first category can move through an AI-assisted pipeline with lightweight review. The second and third categories need senior dual-dialect engineers assigned before conversion begins, not after failures surface.

Regression testing at the procedure level, not just the application level, is the second requirement. Application-level testing catches obvious failures. It does not catch the NULL-handling edge case or the transaction boundary difference that only manifests under specific call sequences. Procedure-level test suites, built against the source system before migration begins, are the only reliable mechanism for catching semantic drift.

Governance of the AI tool's output also needs a formal sign-off gate. We have written about this in the context of large-scale code migration more broadly: the role of senior engineers in AI-assisted programs shifts from production to review, and that review function needs to be resourced explicitly rather than assumed to happen informally. See Large-Scale AI Code Migration: Engineering Org Design for how that workflow redesign and quality gate structure plays out at scale.

Structuring the Migration Program Around These Constraints

The migration programs that complete on schedule are the ones that treat AI conversion as an acceleration layer for a human-governed process, not as a replacement for dual-dialect expertise. The tool handles volume. The engineers handle ambiguity. Those two responsibilities need to be separated explicitly in the program structure.

Budget allocation should reflect the classification output. If 40 percent of procedures fall into the semantic ambiguity or proprietary dependency categories, then 40 percent of the engineering effort budget needs to be allocated to those procedures, regardless of what the AI tool produces. The tool does not reduce the effort required in those categories. It only reduces it in the straightforward category.

Timeline planning needs to account for the discovery phase honestly. Classification takes time. Building procedure-level regression tests against the source system takes time. These are not optional steps that can be compressed to accelerate the conversion phase. Teams that skip them find the time again later, at higher cost, under production pressure.

The honest framing for engineering leaders evaluating this tooling is that AI code conversion is a genuine productivity multiplier for a well-structured migration program. It is not a substitute for one.