Google Cloud has spent more than two years teaching Gemini to read Oracle stored procedures and rewrite them for PostgreSQL. On August 11, 2026, it extended that work again, giving Gemini in Database Migration Service the ability to map an entire schema’s relationships before converting a single line of code. The update looks incremental on its own. The race it belongs to is not.
A Capability Two Years in the Making
The newest version of Google Cloud’s Database Migration Service (DMS) adds what the company calls full schema context analysis. Instead of translating one stored procedure at a time, Gemini now reviews table relationships, data types, and cross-procedure dependencies across an entire database before generating converted code. The console displays source and target code side by side, marks each converted object as Converted, Warning, or Action Required, and requires a person to review and validate the output before anything moves to staging or production.
The kind of conversion Gemini handles is the part that used to require a database specialist fluent in both dialects. Oracle’s DECODE function, a common way to write conditional logic inside a stored procedure, has no direct PostgreSQL equivalent; Gemini rewrites it as a CASE expression and explains why. Oracle’s NVL becomes PostgreSQL’s COALESCE. Multiply that pattern across the stored procedures a legacy Oracle or SQL Server database accumulates over ten or fifteen years, and the appeal of automating it becomes obvious.
None of this is Google’s first attempt at the problem, either. The company introduced Gemini-assisted code conversion for Oracle-to-PostgreSQL migrations in preview at Google Cloud Next in April 2024, extended it to SQL Server sources a year later, and took the core conversion features to general availability in September 2025. A related GA milestone, Gemini-powered conversion quality assessments, followed in May 2026. August’s update is closer to a fourth or fifth iteration than a debut. “Google Cloud’s Database Migration Service simplifies the process of modernizing databases,” Shashank Srivastava, a software engineering manager at Wayfair, said when Google added SQL Server support in 2025. “This makes the migration process less manual and time-consuming, allowing teams to spend more time on development and less on infrastructure.”
The Last Mile Every Cloud Vendor Is Now Fighting Over
Database migrations rarely stall on tables and columns. Rule-based conversion tools have handled that part well for years. They stall on procedural code: the stored procedures, triggers, and custom functions written in a vendor’s proprietary SQL dialect, dense with business logic nobody wants to rewrite by hand. Amazon built its own answer into AWS Database Migration Service in December 2024, adding generative AI through Amazon Bedrock to its Schema Conversion tool. In one example AWS published at launch, rule-based conversion alone translated 100% of storage objects but only 57% of code objects; adding generative AI brought code coverage to 100%. AWS says the AI-assisted tool now automatically converts up to 90% of schema objects from commercial databases, and it has since extended the feature to additional source databases and regions through 2025 and into 2026.
Microsoft has approached the same problem from the application layer. Its GitHub Copilot modernization tooling, updated as recently as June 2026, now helps Java applications rewrite Oracle SQL for PostgreSQL and swap in managed-identity authentication as part of the same migration. That feature remains in preview. Separately, Microsoft previewed an Azure Copilot Migration Agent in March 2026 that automates VMware discovery and landing-zone planning for broader infrastructure moves, though it still hands the actual cutover to Azure Migrate. Three hyperscalers have now built generative AI directly into the point where migrations traditionally got stuck, converging on the same technical answer within roughly two years of each other. A bottleneck that stubborn, fixed by every major cloud provider in the same short window, was costing all three of them real enterprise deals, not just engineering time.
Whoever Converts Your Code First Usually Keeps It
Framing matters here. Gemini in DMS does not convert Oracle or SQL Server code into some neutral, portable format. It converts it into PostgreSQL running on AlloyDB or Cloud SQL, both Google products. AWS’s tool converts into Aurora or RDS. Microsoft’s modernization tooling points at Azure. Each hyperscaler’s AI migration assistant solves a real technical problem, and it also happens to be the most effective tool available for making a switching decision permanent before a customer has finished evaluating alternatives. The engineering is genuine. So is the incentive behind it.
For most IT teams facing a genuine deadline, that trade is reasonable. It still deserves more scrutiny than a new AI feature usually gets. Oracle’s PL/SQL and PostgreSQL’s PL/pgSQL differ in how they handle NULL comparisons, exception scoping, and implicit transaction boundaries, differences that rarely surface in a demo but can quietly change what a financial calculation or an inventory check returns once the code is running in production. Google’s own interface concedes the point: the side-by-side code review, the Warning and Action Required labels, and the requirement that a person approve every converted object before deployment are all implicit admissions that Gemini’s output still needs someone who understands the source database checking its work. That is a sensible design choice, and a quiet admission too: automated conversion of business-critical logic is not yet something to approve on faith, whichever cloud is doing the converting.
None of this makes AI-assisted migration a bad bet. Three hyperscalers converging on the same fix within about two years says the underlying problem, converting years of accumulated stored procedures without months of manual labor, was real and expensive enough to justify the investment each of them made. What is worth watching next is which cloud proves its conversion accuracy under independent scrutiny rather than in a launch post, because that is the claim that will actually move enterprises still running on Oracle and SQL Server. A fast, confident migration to the wrong database is still a migration. It is just a more expensive mistake to undo.
The post Database Migration Was Cloud’s Last Manual Bottleneck. AI Just Made It a Battleground appeared first on DataFLOQ.
