Accelerating database migrations with AI

Article content

Organizations still running SQL Server 2016 are already past the deadline. Microsoft ended extended support on July 14, 2026. The options now are Extended Security Updates, which cover critical security fixes only and stop in July 2029, or a move.

That deadline arrived in the same year AI changed how migration work gets done, and the question we hear from technology leaders has changed with it. It used to be “how long will this take?” Now it is “can’t the AI just do it?”

Part of the answer is yes. The rest of the answer is where migrations still succeed or fail.

How AI reshaped migrations

Anyone who has led a SQL Server to PostgreSQL migration knows where the majority of the time went. T-SQL had to be translated to PL/pgSQL. Conversion action items were worked through one at a time. Legacy stored procedures, often with little documentation and years of accumulated business logic, had to be understood before anyone could safely rewrite them.

That is the part of the work that has shrunk the most. In our own delivery, AI assistants now draft much of the conversion and fix-up code, and our engineers now spend their time reviewing it rather than producing it from scratch. That step is faster, but it cannot be skipped.

AWS has built the same shift into its tooling. In July 2026, AWS added an AI agent to AWS DMS Schema Conversion that can run an entire conversion project from a coding agent such as Kiro or Claude Code. In AWS’s own testing, one session converted 200 database objects in under 15 minutes, against roughly 45 minutes of manual work, and early customer pilots cut conversion cycle time by 60 to 70 percent. AWS Transform now converts SQL Server schemas to Amazon Aurora PostgreSQL offline, including stored procedures and dependent .NET code.

200 objects converted in under 15 minutes. 60 to 70 percent shorter conversion cycles in early pilots. None of it covers moving the data, proving it, or cutting over.

The detail we find most useful is what AWS says the conversion agent does not do: it does not migrate the data, validate the converted code against the target, or perform the cutover. That tells us where the risk in a migration now lies. Conversion is no longer the hard part. Moving the data, proving it is correct, and cutting over safely still depend on people.

Planning migrations for the AI era

With conversion this fast, it is tempting to treat the AI as the migration: point an agent at the database, let it run, and plan everything else around it. Two things change once we look closer.

The estimate needs a new baseline. 

For years, migration estimates were scaled with object counts: the number of procedures, views, and functions determined the time taken for migrations. When conversion takes a fraction of the time it used to, the effort moves to validation, performance, and cutover, and the plan has to follow it there.

Trust has to be designed in. 

Developers are clear about where their confidence in AI stands. In Stack Overflow’s 2025 Developer Survey, 84 percent said they use or plan to use AI tools, while 46 percent said they distrust the accuracy of what those tools produce, up from 31 percent a year earlier. Many of us also remember July 2025, when an AI coding agent deleted a company’s production database during a declared code freeze.

Neither point is a reason to hold back on AI. Both are reasons to put as much care into how the work is structured.

The role of humans in the loop

AI now carries the volume in a migration. People still own the decisions that determine whether it succeeds, and four of them stand out.

Four decisions that stay with people in a database migration with AI: proving the data, tuning performance, cutover, and defining modern

Proving the data is right. 

A perfect schema with the wrong data in it is still a failed migration. That means row counts and checksums, and above all business reconciliation: does last quarter’s revenue match to the cent on both sides? AWS DMS data validation and data resync help here, but a business or application owner still has to sign off on the data.

Making it fast on the new engine. 

A query that performed well on SQL Server can slow down badly on PostgreSQL, and those issues only show up under real workloads, not during conversion. Indexes, statistics, and query plans need a database engineer who knows both engines well.

Calling the cutover. 

The migration team keeps source and target in sync with change data capture, agrees the cutover window with the business, and rehearses the rollback. The final go or no-go decision belongs to a named owner, typically the application or data owner, and it is made by them every time, never by an agent.

Deciding what “modern” means. 

Converted is not the same as modernized. On one recent migration of a SQL Server operational system to Aurora PostgreSQL, the schema moved cleanly and the old conventions moved with it: the dbo schema, quoted mixed-case table names, and T-SQL patterns rewritten line for line. None of that breaks on day one, but it adds friction for every developer and analyst who works with the system afterward. Deciding what to clean up now and what to leave for later is a judgment call, not a conversion step.

Guardrails for AI agents

The same agents that convert schemas can now build pipelines, query warehouses, and troubleshoot jobs. Since August 2026, Amazon Redshift works with the Agent Toolkit for AWS, so agents like Claude Code, and Kiro can build, query, and migrate Redshift warehouses directly. That makes governance a design decision for every stage of a migration, not something added at the end.

We need to think of an AI agent the way we’d think of a capable contractor in their first week. It gets a badge, a defined scope, and a reviewer.

Five guardrails for every AI agent: its own identity, read-only first, spec before code, review every change, and full audit trail

Some of this is already built into AWS tooling. The AWS Data Processing MCP Server starts read-only, and write access and sensitive-data access each need their own explicit flag. AWS Agent Registry, keeps track of which agents and tools are in use across an organization. Our own teams work from written specs and steering files in Kiro, so an agent starts every task with the architecture, naming, and data rules of the project in front of it.

Google’s 2025 DORA report explains why the discipline around the agent matters as much as the agent. It found that about 90 percent of technology professionals now use AI at work, and that AI “amplifies what’s already there”. Teams with strong testing and fast feedback get faster. Teams without them see more instability. An agent works within whatever discipline it is given, so that discipline has to be deliberate.

The modern migration lifecycle

Put together, a data migration today works less like a single project plan and more like a series of gates. The agent does the heavy lifting at each stage, and a human owns the decision at each gate.

Six-stage database migration lifecycle showing what the AI agent does and what a person decides at each stage, from assess to keep current

Two stages are worth a closer look.

The target comes first, because not every SQL Server should become PostgreSQL. A database with heavy use of SSIS packages, SSRS reports, or CLR code may be better served for now by Babelfish for Aurora PostgreSQL or a license-included Amazon RDS for SQL Server instance, while the applications catch up. Choosing the target deliberately works better than defaulting to the most ambitious option.

The modernize stage is where the long-term value is. Once the data is in Aurora PostgreSQL, zero-ETL integration can replicate it into the Amazon SageMaker lakehouse without a pipeline to build or maintain. This is the lowest-cost moment to connect operational data to analytics and AI. A migration that stops at landing the data leaves most of that value unrealized.

Migrate once, modernize continuously

The bigger change is not any single tool. It is that migration no longer has to be a large, disruptive event that happens once a decade.

In June 2026, AWS previewed continuous modernization in AWS Transform, which scans repositories for technical debt and proposes fixes on an ongoing basis . AWS Glue 6.0 uses AI to upgrade older Spark jobs and checks the results with data quality rules. Upgrades that used to wait years for a budget cycle can become a steady flow of small, reviewed changes.

That shifts the business case. The goal is no longer to get through one big move. It is to stop accumulating the debt that made the move difficult in the first place, with the same guardrails in place every time an agent works on the data estate.

How BizCloud Experts can help

This work depends on judgment at the right moments, and that is where experienced teams make the biggest difference.

We usually start with one database that matters to the business. It is not necessarily the easiest one, and it is not the whole data estate. It is one where a successful move builds confidence for the ones that follow. We choose the target deliberately, convert with AI, validate the data with the business owners involved, run a rehearsed cutover with change data capture, and connect the result to the lakehouse. Every agent involved works under the guardrails described above, and we set those up in the customer’s own AWS accounts so the team keeps them.

From there, the rest of the migration moves in waves. Each wave goes faster than the last, because the patterns, the validation approach, and the guardrails already exist. When the application layer needs to change too, our Migrations and DevOps practice works alongside our Data and Analytics team. Many of these engagements might also qualify for AWS migration funding programs, which can offset part of the cost.

AI has made schema conversion faster and more consistent than ever. What decides whether it succeeds is still human: validating the data, approving the cutover, and shaping what the modernized system should look like.

 For teams with SQL Server 2016, or any database migration that keeps getting pushed, we would be glad to help. Reach out at bizcloudexperts.com/contact.

About BizCloud Experts. BizCloud Experts is an AWS Premier Tier Services Partner that designs and builds data, analytics, and AI platforms on AWS, from database migrations and governed data foundations to the agents that run on top of them.