How AI Agents Actually Help With Cloud Migration and Infrastructure Modernization (And Where They Still Need Guardrails)

Key Points:

• AI agents help with cloud migration and infrastructure modernization across five concrete stages: application discovery and dependency mapping, application and database code refactoring, infrastructure-as-code generation, test and validation generation, and post-migration cost and performance tuning.
• One rule predicts agent reliability: agents are highly autonomous when they read and write files (inventory, code, SQL, Terraform, tests, runbooks) and only semi-autonomous when they mutate live state (cutover, DNS, data sync, rollback), which still needs human approval.
• AI agents do not replace a target platform. They produce artifacts (Dockerfiles, Kubernetes manifests, Terraform modules, migration plans) that someone still has to deploy, secure, and operate consistently.
• Agents fail in four predictable ways: incomplete discovery, plausible-but-wrong infrastructure config (over-permissive IAM, wrong CIDRs, no resource limits), non-determinism between runs, and unbounded blast radius when an agent holds long-lived admin credentials. Scoped short-lived identities, plan-then-approve, ephemeral environments, and policy-as-code gates remove most of it.
• Qovery is the destination runtime and guardrail layer for agent-generated changes: code is pushed, Qovery deploys it into your own AWS, GCP, Azure, or Scaleway account (or your existing Kubernetes cluster) with per-environment RBAC, a preview environment per pull request, environment auto-stop for non-production, and managed cluster upgrades, while the cloud bill and any Savings Plans stay in your name (BYOC).

AI agents are excellent at reading and rewriting your migration, and genuinely dangerous when they mutate live state. That one sentence predicts almost everything about where they help and where they hurt, and it is the honest version of a story that vendors keep overselling.

Agents are already mainstream, so this is no longer a "should we" conversation. 84% of developers now use or plan to use AI tools in their workflow (Stack Overflow Developer Survey 2025), and Google Cloud's DORA research puts AI use at work at 90% of respondents (DORA 2025). The interesting question in 2026 is governance: what do you let an agent do unsupervised, and where do you keep a human in the loop.

I have spent the last few years interviewing CTOs and running Kubernetes in production, and I have watched teams point an agent at a legacy estate with real enthusiasm, then go quiet when it granted itself an admin role "to make the deploy work." Here is where agents genuinely earn their keep, where they break, and the guardrails I would put in place before one touches your infrastructure.

How do AI agents help with cloud migration and infrastructure modernization?

AI agents help across five stages of a migration: discovery and dependency mapping, application and database code conversion, infrastructure-as-code generation, test and validation generation, and post-migration cost and performance optimization. They compress assessment and refactoring the most, while cutover and day-2 operations still need a human-owned platform.

An AI agent, in one sentence, is a tool-using LLM system that can read a repository, call APIs and CLIs, and propose or apply changes. AWS Transform, GitHub Copilot app modernization, Google Migration Center with Gemini Cloud Assist, and custom agents built on MCP or LangGraph all fit that definition.

The five stages, each liftable on its own:

1. Discovery and dependency mapping: the agent parses repositories, build files, IaC, and runtime telemetry into a service graph and a disposition per application.
2. Application and database code refactoring: the agent upgrades runtimes and frameworks, containerizes services, and converts SQL dialects.
3. Infrastructure-as-code generation: the agent scaffolds and refactors Terraform, CloudFormation, or Bicep and runs policy checks against it.
4. Test and validation generation: the agent writes the regression and equivalence tests that prove behavior did not change.
5. Post-migration cost and performance tuning: the agent finds idle resources, rightsizes workloads, and flags commitment and Savings Plan opportunities.

What agents do not do is just as important. Agents do not own the runtime, do not guarantee behavioral equivalence, and do not remove the need for a target platform. They hand you artifacts. Someone still deploys, secures, and operates those artifacts consistently.

The vendor-reported numbers are real and worth knowing, as long as you read them as vendor claims. AWS says its Transform agent modernizes .NET applications up to 4x faster with up to 40% licensing savings (AWS, vendor-reported). GitHub says Copilot app modernization gets Java and .NET upgrades done "in days instead of months" (GitHub, vendor-reported). IBM reports one customer cut the time to understand complex applications by 79% with watsonx Code Assistant for Z (IBM, vendor-reported). Big gains, all in the reading-and-rewriting half of the work.

Which migration tasks can AI agents genuinely automate today?

AI agents reliably automate anything that is reading and rewriting text: inventory, application code, SQL, Terraform, tests, and documentation. They only semi-automate anything that changes live state, which is why cutover, DNS changes, data sync, and rollback stay human-approved.

Application discovery is where agents shine first. An agent parses repositories, build files, IaC, and runtime telemetry into a dependency graph, then proposes a 7R disposition per application (retire, retain, rehost, replatform, refactor, repurchase, relocate). That inventory used to take a consulting team weeks.

Code modernization is the highest-volume win. Java 8 to 17 or 21, .NET Framework to modern .NET, Oracle PL/SQL to PostgreSQL, and COBOL estates are all pattern-heavy rewrites that agents handle well. This matters because the legacy pile is enormous: IBM estimates 250 billion lines of COBOL are still in production (IBM). AWS Transform, GitHub Copilot app modernization, and IBM watsonx Code Assistant for Z all target exactly this work.

IaC generation and drift analysis are strong but supervised. Agents scaffold Terraform, CloudFormation, and Bicep, refactor modules, and run policy-as-code checks. They emit plans that humans review. They do not own apply.

Test and equivalence generation is the highest-value step teams skip. The regression suite is what proves the migration did not change behavior, and an agent will happily write hundreds of tests you would never have budgeted the time for. Skip it and you are shipping hope.

Post-migration work is a natural fit for scheduled agents: rightsizing, idle resource detection, commitment and Savings Plan analysis, and Kubernetes request and limit tuning are all read-heavy and repeatable.

The reusable heuristic: if the task reads and writes files, give the agent high autonomy; if it mutates production, keep a human in the approval path.

Where do AI agents fail during infrastructure modernization?

AI agents fail in four predictable ways: incomplete discovery that misses undocumented dependencies, infrastructure config that looks correct and is subtly wrong, non-determinism that destroys reviewability, and unbounded blast radius when an agent holds long-lived cloud credentials.

Incomplete discovery is the quiet killer. Agents miss what the code does not state: cron jobs on a forgotten box, shared file mounts, hardcoded IPs, undocumented internal services, license-bound components, and batch windows that only the ops team remembers. The agent maps what it can read, and no one wrote the rest down.

Plausible-but-wrong config is worse than obviously-broken config, because it passes casual review. Over-permissive IAM policies, wrong network CIDRs, missing PodDisruptionBudgets, default security groups left wide open, and containers with no resource requests or limits all look fine until they are not. This is not hypothetical: Veracode found that 45% of AI-generated code samples introduced an OWASP Top 10 security vulnerability (Veracode 2025 GenAI Code Security Report). Infrastructure code gets the same treatment.

Non-determinism destroys reviewability. Run the same prompt twice and you can get two different Terraform layouts. That breaks code review, because the diff no longer maps to intent, and it creates drift against the real estate.

Cost blowups are the default, not the exception. Agents provision generously: oversized node groups, no auto-stop on non-production, memory limits set to "whatever works." Kubernetes is already the poster child for waste. CAST AI's analysis of thousands of clusters found organizations used only 13% of provisioned CPU and 20% of provisioned memory before optimization (CAST AI). Hand that same provisioning judgment to an agent optimizing for "make it run" and the number gets worse.

Credential risk is the one that ends careers. An agent with admin keys can delete a state file, drop a database, or exfiltrate secrets in a single tool call. Least privilege applies to agent identities exactly as it does to humans.

Every one of these is fixable, and the fixes are the subject of the next section: scoped identities, plan-then-approve, ephemeral environments, policy gates, and human sign-off on production.

What do AWS, Microsoft, IBM, Google, and the consultancies actually offer for agent-assisted migration?

The market splits cleanly: hyperscalers ship assessment and code-transformation agents biased toward their own cloud, IBM and Broadcom target mainframe and VM estates, HashiCorp provides the IaC substrate agents write into, and firms like Ampcus and Newt Global deliver human-plus-agent services. None of them hands you a portable target runtime you keep operating afterward. To their credit, several do things Qovery does not, and I will say so plainly.

• AWS Transform and AWS Migration Hub are strong on .NET, VMware, and mainframe transformation, with the vendor-reported speedups above. The limitation is destination bias: the output assumes you are landing on AWS.
• Microsoft Azure Migrate plus GitHub Copilot app modernization is excellent for .NET and Java assessment and upgrade. Same caveat: the happy path lands on Azure.
• IBM watsonx Code Assistant for Z and watsonx Orchestrate are the strongest options for COBOL and hybrid mainframe estates, full stop. Qovery does not do mainframe conversion. The limitation is enterprise scope, cost, and narrow applicability.
• Google Cloud Migration Center with Gemini Cloud Assist does good assessment and TCO modeling. The destination bias is GCP.
• HashiCorp Terraform with Sentinel policy is the auditable artifact layer agents emit into, and it is genuinely valuable. The limitation is that you still design, build, and operate the platform yourself.
• Broadcom VMware Cloud Foundation is relevant for large VM estates and cloud-adjacent paths, less so for application modernization.
• Ampcus and Newt Global are useful for one-off large estates delivered as human-plus-agent services. The limitation is that the capability leaves when the engagement ends.

Qovery differs by not competing on assessment or code conversion at all. Qovery is the destination runtime and guardrail layer that keeps agent-generated deployments consistent across AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, with BYOC so the cloud bill and any discounts stay in your account. That matters because most enterprises are not single-cloud: Flexera's latest report puts 73% of organizations on hybrid cloud (Flexera 2026 State of the Cloud), and a single-hyperscaler migration tool does not serve that reality.

What guardrails should you put around AI agents before they touch your infrastructure?

Six guardrails make agent-driven infrastructure work safe: a narrow revocable identity per agent task, plan-then-approve on anything that mutates cloud state, an ephemeral environment that proves every change before merge, policy-as-code gates in CI, full attribution and reversibility of every action, and one standardized deployment path.

1. Scoped short-lived credentials per task. Separate read-only discovery roles from write and apply roles, and never hand an agent a shared admin key. The agent gets exactly the permissions its current task needs, for as long as the task runs.
2. Plan-then-apply for all IaC. Every change touching data stores, IAM, or networking needs a human approval, and production always does. The agent proposes; a person approves the mutation.
3. An ephemeral environment per change. The agent's output has to run in a throwaway, production-like environment before it merges. If it cannot stand up clean, it does not ship.
4. Policy-as-code gates in CI. Check IAM permissiveness, encryption at rest, tagging, budget caps, and image provenance automatically, so an over-permissive policy fails the build instead of reaching the account.
5. Full auditability. Every agent action is attributed, logged, and reversible. Treat the agent as a junior engineer with commit access and no production keys.
6. One standardized ship path. A single templated deployment mechanism shrinks the surface an agent can get wrong, because there is exactly one correct way to deploy.

This is the layer Qovery was built for. Agents produce the artifacts; Qovery owns how they run: git-push deployments, preview and ephemeral environments per pull request, per-environment RBAC, environment auto-stop for non-production, managed cluster upgrades, and databases backed by managed cloud services, on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster. The agent opens a pull request, Qovery spins up a preview environment to prove it, and nothing reaches production without the gate.

What does an agent-assisted cloud migration look like end to end?

An agent-assisted migration runs in six phases: inventory, disposition, refactor, target platform setup, validated cutover service by service, then continuous cost and reliability tuning. Agents do the heavy reading and writing in phases 1, 2, 3, and 6, and humans own phases 4 and 5.

• Phase 1, inventory: the agent builds the service and dependency graph from repos, CI configs, IaC, and runtime telemetry. A human validates the gaps it could not see.
• Phase 2, disposition: the agent proposes a 7R decision and an effort estimate per application. Humans decide retire versus refactor.
• Phase 3, refactor: the agent handles runtime upgrades, 12-factor config extraction, Dockerfiles, and schema conversion, delivered as pull requests reviewed like any other change.
• Phase 4, target platform: you set the runtime once, on managed Kubernetes on AWS, GCP, Azure, or Scaleway, or your existing cluster, plus databases backed by managed cloud services. This is the long pole of the whole program, and it is where Qovery removes months of platform build.
• Phase 5, cutover per service: preview environment, regression suite, traffic shift, documented rollback, in small batches. Never a big bang.
• Phase 6, continuous modernization: scheduled agents handle rightsizing, idle detection, dependency upgrades, and auto-stop policies on non-production. Idle spend is real money: Datadog reports most workloads consume less than 25% of the CPU they request (Datadog), and Flexera pegs wasted cloud spend at roughly 27% (Flexera 2025 State of the Cloud).

Be honest about timelines. The code phase compresses hard with agents; the platform and validation phases mostly do not. Refactoring 300 services faster does not help if standing up the runtime and proving each cutover still takes the same careful weeks.

Should you use AI agents for your cloud migration in 2026, or is it too early?

Use AI agents now for assessment, code and database conversion, IaC drafting, and test generation, where they pay for themselves on large legacy estates. Do not let them own cutover or production operations, and pair them with a standardized platform so their output arrives as reviewable pull requests rather than decisions.

Where the ROI is clearest: 1,000+ file legacy codebases, framework and runtime upgrades, database engine migrations, COBOL estates, and large VM fleets. The bigger and more repetitive the rewrite, the more an agent earns.

Where the ROI is thin: small, modern, already-containerized apps. That migration is platform work, not code work, so an agent has little text to rewrite and the value sits in the runtime you deploy to.

The honest trade-off: agents move effort from writing to reviewing. DORA's 2025 research already sees AI adoption correlate with higher throughput but continued pressure on delivery stability (DORA 2025). Budget the review capacity, or the bottleneck simply relocates from typing to approving.

A five-item checklist you can apply this week:

1. Estate size: more than a few hundred files or services, an agent pays off; a handful, do it by hand.
2. Test coverage: thin coverage means you cannot trust an agent's rewrite, so fund test generation first.
3. Credential model: if you cannot issue scoped, short-lived, revocable identities today, fix that before an agent gets any key.
4. Target platform readiness: if the runtime is not standardized, the agent's output has nowhere consistent to land.
5. Review bandwidth: count the engineers who can approve infrastructure changes; that number caps your real throughput.