AI Agents and Cloud Migration: The 4 Stages They Actually Help With (And the 5 They Break)

Key Points:

• AI agents reliably help in four stages of a migration: application and dependency discovery, code and infrastructure-as-code translation (COBOL to Java, Java EE to Spring Boot, .NET Framework to modern .NET, CloudFormation to Terraform, VM to container), characterization test generation to prove parity, and post-migration rightsizing and cost analysis.
• They are unreliable in the five stages that decide success: target architecture sizing, data migration and cutover, network and identity design, compliance evidence, and the post-migration operating model. Those stay human decisions.
• The only safe pattern is propose-approve-apply. The agent holds read-only cloud credentials, its output lands as a pull request against the IaC repo, a policy engine (Open Policy Agent, HashiCorp Sentinel, Kyverno) or a human approves, and a deterministic pipeline applies it. An agent should never hold terraform apply rights in production.
• Vendor-reported refactoring gains are large, independent evidence is mixed. METR's 2025 RCT found experienced developers were about 19% slower with AI tools while forecasting a 24% speedup, and Gartner expects over 40% of agentic AI projects to be cancelled by end of 2027. Net saving is generation time minus review and remediation time.
• No single tool covers a full migration, so most teams chain three or four: assessment, code, IaC plus policy, and a developer platform for after cutover. Qovery is that destination and guardrail layer - git-push deploys, preview environments per PR, environment auto-stop, and per-environment RBAC inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster.

AI agents are genuinely good at the boring 60% of a cloud migration and unreliable in the 40% that decides whether it works. That is the honest framing after a year of watching teams throw agents at mainframe decomposition, Terraform generation, and cloud bill analysis. The agents earn their keep in the grunt work. They fall apart the moment the right answer depends on something they cannot read: your compliance obligations, your data gravity, your team's actual skills.

I have spent 15 years in cloud and interviewed more than 200 CTOs, and the migrations that go sideways almost never fail at the code translation step. They fail at sizing, cutover, and the operating model nobody designed. So let me be specific about where agents help, where they break, and the one pattern that keeps them from taking production down with them.

What can AI agents actually do in a cloud migration today?

AI agents are reliably useful in exactly four stages of a migration: discovery and dependency mapping, code and infrastructure-as-code translation, characterization test generation for parity validation, and post-migration cost and rightsizing analysis. In all four, the output is an artifact a human reviews - a report, a diff, a plan. Never an applied change.

Here is what each stage looks like in practice:

• Discovery. Parsing legacy codebases, config files, and runtime telemetry into a dependency graph and an application inventory. This is the step that normally costs consultants weeks of stakeholder interviews, and an agent collapses it to hours.
• Code and IaC translation. COBOL and mainframe to Java, Java EE to Spring Boot, .NET Framework to modern .NET, CloudFormation to Terraform, Dockerfile and Kubernetes manifest generation, and VM-to-container decomposition.
• Test generation. Agents writing characterization tests against legacy behavior so you can prove the migrated service behaves identically. This is the highest-value and least-discussed use, because parity is what actually makes a cutover safe.
• Post-migration operations. Rightsizing recommendations, idle and orphaned resource detection, cloud bill anomaly detection, and drift detection against your IaC.

A fifth low-risk win sits alongside these: runbook and architecture documentation generated from live infrastructure. Low risk, high time savings, nobody argues about it.

The rule that anchors everything below: the unit of agent output is a diff, a plan, or a report. The moment an agent's output becomes an applied change without a human or a policy gate in between, you have traded weeks of migration time for a production incident you cannot predict.

Where do AI agents still fail in infrastructure modernization?

Agents fail at every step where the correct answer depends on context they cannot read. Five steps still decide whether the migration works, and all five stay human: target architecture sizing, data migration and cutover, network and identity design, compliance evidence, and the operating model.

• Target architecture sizing. Whether a monolith becomes 3 services or 30, and whether you need Kubernetes at all. An agent will happily propose microservices you have no team to run.
• Data migration and cutover. Replication lag, consistency guarantees, rollback windows, and regulated data residency. Get this wrong and you lose data, not time.
• Network and identity design. VPC and VNet topology, IAM trust boundaries, private connectivity, and secrets handling. This is where a plausible-looking plan quietly opens a security hole.
• Compliance evidence. An agent can draft a control mapping. It cannot be accountable for it in a SOC 2 or ISO 27001 audit. Accountability does not delegate to a model.
• The operating model. A perfectly migrated workload with no paved road for developers is legacy again within 18 months.

The concrete failure modes are worth naming so you recognize them in review: hallucinated resource types, deprecated API versions, and plausible-looking Terraform that replaces a stateful resource on apply instead of updating it in place. That last one has deleted production databases.

Two structural limits make this worse. Non-determinism means the same prompt can produce a different plan twice, which is disqualifying in a change-managed environment. And context limits mean an agent reasons well about one service and poorly about a 400-service estate with undocumented coupling - exactly the estates that most need migrating.

What is the safe pattern for letting an AI agent touch infrastructure?

Use propose-approve-apply: the agent proposes a diff with read-only credentials, a policy engine or a human approves, and a deterministic pipeline applies it. Every agent-suggested change should be indistinguishable in your pipeline from a human-written one - same review, same plan, same audit trail.

The non-negotiables:

• Credentials. Read-only cloud access by default, zero write scope. Writes only ever land as a pull request against the IaC repo.
• Plan before apply. terraform plan and kubectl diff reviewed by a human or checked by policy as code. HashiCorp Sentinel enforces policy between plan and apply, and Open Policy Agent or Kyverno do the same job for Kubernetes.
• Scope by blast radius. Free rein in ephemeral preview environments, a single approval in staging, two approvals plus a change window in production.
• Full attribution. Who prompted, what the agent proposed, who approved, what was applied, and when - immutable and queryable.
• Validate in a throwaway environment first. This is the strongest practical argument for preview environments per pull request: the agent's change runs somewhere real before it runs somewhere that matters.
• Rollback is deterministic. One click, defined in advance, never something the agent improvises mid-incident.

The policy matrix most teams converge on looks like this:

This is where Qovery fits, and it is worth being precise: Qovery is not the agent. It is the pipeline and validation surface the agent's output flows through. Preview and ephemeral environments per PR let you test agent-authored changes in a real environment before merge, per-environment RBAC bounds what any actor can touch, and git-push deployments mean agent and human changes follow one identical path to production.

The rule of thumb I give every team: if you would not let a new contractor run it unreviewed on day one, do not let an agent run it either.

Which AI agents and tools should you use for each migration stage?

No single vendor covers a full migration, so most teams chain three or four tools: one for assessment, one for code refactoring, one for IaC generation and policy enforcement, and one developer platform for life after cutover. Here is who is genuinely good at what, and where each one stops.

A few honest notes on the table:

• The Terraform MCP server gives agents structured read access to the registry, modules, and Sentinel policies, which is the right way to let an agent reason about IaC without handing it write access.
• Vendor migration agents are optimized for landing on that vendor's cloud. That is fine if landing there is your decision, and a problem if the agent is quietly making that decision for you.
• Oracle has its own database and application migration tooling for Oracle-to-Oracle and Oracle-off-prem paths, and Docker remains the standard containerization target with AI-assisted Dockerfile and Compose generation.

Where Qovery sits is deliberately narrow: not a migration agent, the destination. Git-push deployments, preview environments per PR, environment auto-stop, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services - all inside the customer's own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster. Because it runs BYOC, the cloud bill and any Savings Plans stay in the customer's name. The build-your-own alternative, Terraform plus Argo CD plus Backstage, works well if you staff a dedicated platform team.

How much time and money do AI agents actually save on a migration?

Vendor-reported gains for AI-assisted code transformation are large, independent evidence is far more mixed, and the net saving is always generation time minus review and remediation time. Budget for review, or the savings are accounting fiction.

The counterweights matter because the hype does not mention them. Gartner expects over 40% of agentic AI projects to be cancelled by end of 2027 on cost, unclear value, or weak risk controls. And adoption is not the bottleneck - 84% of developers now use or plan to use AI tools per the 2025 Stack Overflow survey, while 46% say they do not trust the accuracy of the output. Trust is the constraint, not access.

Where savings are real and boring: discovery documentation, test scaffolding, IaC boilerplate, runbook writing. Where they evaporate: unvalidated refactors that surface as production incidents two quarters later, and cloud bills nobody rightsized. For context, McKinsey found roughly 75% of cloud migrations run over budget, so the review discipline you add is not overhead, it is the thing that keeps you in the other 25%.

The framing I give teams to quote in a planning meeting: net saving = generation time saved - (review time + remediation time + incident cost). If you cannot estimate the last three, you cannot claim the first.

What should your team do after the migration so modernization sticks?

A migration only counts as modernization if developers end up with a self-service path to production. Decide the operating model before cutover, because the platform you hand over on day one determines whether the estate stays modern or becomes the next legacy.

• Define the paved road. Exactly how a developer ships a new service on day one post-migration without filing a ticket. If the answer is "ask the platform team," you have rebuilt the bottleneck you just paid to escape.
• Golden paths beat bespoke Terraform. Templates that encode the right defaults win over per-team hand-rolled modules every time.
• Control non-production cost structurally. Environment auto-stop, ephemeral environments per PR, and rightsizing as a recurring job rather than a one-off project.
• Assign cluster lifecycle ownership. Who upgrades Kubernetes, who patches, who is on call. Kubernetes supports only the most recent three minor versions and cuts a new minor roughly every four months, so this is permanent work, and it is where in-house platforms quietly fail.
• Bound permissions with per-environment RBAC so humans and agents both operate inside limits set once.

Qovery is the concrete option here: an internal developer platform running in the customer's own cloud account or existing Kubernetes cluster, with git-push deploys, preview environments per PR, environment auto-stop, managed cluster upgrades, and databases backed by managed cloud services. The fair contrast is build-your-own with Terraform, Argo CD, and Backstage, which is viable with a dedicated platform team - though most teams under 100 engineers do not have one.

This ties straight back to agents: a paved road is also the only sane place to let an agent deploy, because the guardrails are already encoded. The RBAC, the policy checks, and the rollback are not something you bolt on per agent. They are the platform.

Can AI agents operate infrastructure in sovereign, regulated, or air-gapped environments?

Yes, but only with self-hosted or region-locked models plus a strict propose-approve-apply loop, and in most regulated setups the agent should hold no write credentials at all. The blocking issues are prompt data residency and immutable auditability of actions, not model capability.

• Treat prompts as sensitive data. Infrastructure topology, secret names, IAM policies, and architecture diagrams all leave your perimeter the moment you prompt a hosted model.
• Rank your options. Self-hosted open-weight models first, then sovereign or EU-region model endpoints with contractual residency commitments, then aggressive context redaction if neither is available.
• Know the air-gapped reality. Agents work offline for code transformation and IaC generation, and barely at all for anything that needs live cloud APIs.
• Make auditability a hard control. Immutable logs of prompt, proposal, approver, applied diff, and rollback. This is exactly what an auditor will ask for.

This is where BYOC does real work: with Qovery, workloads and data stay in the customer's own cloud account or on-prem Kubernetes cluster, which separates the control-plane question from the data-residency question. On certifications, I will not assert specifics on your behalf - check vendor compliance and residency documentation directly, because it is what your auditor will hold you to.

One caveat on timing. Model residency options, MCP tooling, and vendor agent GA status move faster than any other part of this landscape. This article is accurate as of October 2026, and the tool rows above are the parts most likely to have shifted by the time you read it.