End-to-End Agentic Migrations to Azure: What AI Agents Can Actually Do (and Where They Break)

Key Points:

• An end-to-end agentic migration is one where AI agents drive the full loop - discovery, dependency mapping, code and config refactor, Terraform or Bicep generation, deploy, test, rollback - and humans approve at gates instead of typing every command. Autonomy is a dial, and most teams should cap it at "open a pull request", not "apply to production".
• Agents automate the mechanical phases well: workload inventory, Dockerfile and CI rewrites, runtime and framework upgrades, swapping cloud SDK calls (S3 to Azure Blob, SQS to Service Bus, Secrets Manager to Key Vault), scaffolding IaC, drafting runbooks. They stay unreliable on target-architecture choices, network and identity design, stateful data cutover, and compliance sign-off.
• Microsoft ships real first-party pieces: Azure Migrate for discovery and assessment, GitHub Copilot modernization for Java, .NET and C++ upgrades plus Azure-readiness fixes, and the Azure MCP Server so agents read and act on Azure resources through the Model Context Protocol instead of guessing.
• Qovery ships agentic migration today. Qovery Skills (github.com/Qovery/qovery-skills) plug into Claude Code, Cursor, Codex and 30+ other tools, so your agent can plan and execute the migration onto your own cloud account in one command instead of you wiring up MCP servers and prompts by hand.
• What breaks a migration is rarely the model. It is an agent with unscoped permissions, no environment isolation, and no reversible deploy. Qovery is the execution layer that deploys into your own Azure subscription (or AWS, GCP, Scaleway, or an existing Kubernetes cluster) with git-push deploys, per-PR preview environments, non-prod auto-stop, managed cluster upgrades, and per-environment RBAC.

Agents can already do most of the mechanical work of an Azure migration. The thing that breaks your migration is not the model. It is the permissions you handed it.

I have watched teams get very excited about pointing an AI agent at a cloud estate, and then get very quiet when the agent granted itself a Contributor role "to make the deploy work". So let me be honest about where this technology is genuinely good, where it is not, and what you actually have to put in place before you let an agent touch anything.

What does an "end-to-end agentic migration to Azure" actually mean?

An end-to-end agentic migration to Azure is one where an AI agent, or a small crew of agents, owns the full migration loop - discover, assess, refactor, generate IaC, deploy, validate, roll back - using real tools and real feedback, while engineers act as reviewers approving at defined gates rather than operators running each command.

It is not three things it keeps getting confused with:

• A copilot that autocompletes Terraform in your editor.
• A lift-and-shift tool that only replatforms VMs.
• A one-shot LLM prompt that emits a wall of Bicep with no feedback loop.

The whole article hangs off one numbered spine, the 7 phases of the loop:

1. Discovery and inventory
2. Dependency and data-flow mapping
3. Target architecture decision (AKS vs App Service vs Container Apps vs VMs)
4. Code and config refactor
5. IaC generation (Terraform or Bicep)
6. Deploy and validate in an ephemeral environment
7. Cutover and rollback

Three properties separate an agentic workflow from a generative one: it uses tools, it closes a feedback loop (read the plan output, read the test results, retry), and it carries state across steps. A model that writes Bicep once and never reads whether it applied is not doing an agentic migration. It is guessing in a nicer font.

What made this practical in 2025 and 2026 is plumbing, not model IQ: the Model Context Protocol, an open standard now supported across Claude, ChatGPT, VS Code, Cursor and many others, plus MCP servers that expose cloud APIs to agents, coding agents that run against a repo in CI, and Terraform or Bicep as the machine-writable interface to Azure.

One rule I would tattoo on every migration: autonomy is a dial with four levels - suggest, propose a PR, apply to non-production, apply to production. Level 3 is the practical ceiling for most teams today. Nobody sane hands level 4 to an agent yet.

And because the target here is Azure, Azure leads the examples. The exact same loop lands on AWS, GCP, Scaleway, or an existing Kubernetes cluster.

Which migration phases can AI agents genuinely automate today - and which still need humans?

Agents reliably automate the high-volume, low-judgment phases - inventory, code and dependency rewrites, IaC scaffolding, test generation, runbook drafting - while humans still own target architecture, network and identity design, stateful data cutover, and the go/no-go call. Those are exactly the decisions where being wrong is irreversible.

Here is the phase-by-phase verdict.

What agents automate well: repo and workload inventory, Dockerfile and CI pipeline rewrites, the Java and .NET runtime upgrades App Service or AKS force on you, swapping cloud-specific SDK calls (S3 to Azure Blob, SQS to Service Bus, Secrets Manager to Key Vault, IAM policy shapes to RBAC role assignments), generating IaC modules, writing smoke and health-check tests, and drafting the cutover runbook.

What they only assist with: sizing and cost estimates, network topology and private endpoint design, identity mapping (AWS IAM roles to Entra ID workload identity), performance regression triage, and quota planning.

What stays human-owned: the stateful data migration and the cutover window, the DNS switch, data residency and regulated-data decisions, anything touching customer PII, and the final go/no-go.

The failure modes are specific, not vague. Agents hallucinate resource properties and API versions. They write IaC that plans clean and drifts on apply. They spin in retry loops when Azure Resource Manager returns HTTP 429 with a Retry-After header under its per-region write throttle. They grant over-broad role assignments to "make it work". And they produce confident, wrong dependency maps for anything discovered only at runtime.

This is where I want the measurement, not the marketing. In a METR randomized controlled trial, experienced open-source developers were actually 19% slower on real tasks when allowed to use AI tools, even though they believed the tools had sped them up. The 2025 Stack Overflow survey found 84% of developers use or plan to use AI tools, yet 46% distrust their accuracy, and the top frustration is code that is "almost right, but not quite". The 2025 DORA report is the sharpest framing: AI raises delivery throughput and raises instability at the same time, and it acts as an amplifier of whatever discipline you already have. No automated tests and no fast feedback loop means the agent amplifies your mess.

What tools do you actually need for an agentic Azure migration?

A working agentic Azure migration needs four layers, and no single product covers all four: a discovery and assessment source of truth, a coding agent with scoped repo write access, a machine interface to Azure (an MCP server plus Terraform or Bicep), and an execution layer that turns the agent's pull request into a safe, reversible deploy.

Layer 1, discovery. Azure Migrate is a free service that discovers and assesses servers, SQL databases, and web apps, and produces Azure-readiness, right-sizing, cost estimation, and dependency analysis. It also now ships an Azure Copilot migration agent in preview for planning. What it does not do is refactor code or run your deploy pipeline.

Layer 2, code agents. GitHub Copilot modernization is an agentic solution that upgrades Java, .NET and C++ apps and helps migrate them to Azure - dependency upgrades, Azure-readiness fixes, build-error remediation, CVE fixes, and IaC generation, with humans in the loop. The IDE upgrades are GA; the CLI modernization agent is in public preview. Alongside it, repo-wide agents like Claude Code, Cursor, or Codex do the general refactor and open PRs. None of them isolate an environment or give you a reversible deploy.

Layer 3, the machine interface. The Azure MCP Server lets an agent read and act on real Azure resources (Key Vault, Cosmos DB, Monitor, RBAC, AI Search and more) through MCP instead of hallucinating state. On the IaC side: pick Terraform if you are multi-cloud or already have state and modules, pick Bicep if you are Azure-only and want first-party ARM fidelity.

Layer 4, execution and guardrails. This is the layer most agentic-migration writeups skip, and it is the one that decides whether the agent is useful or dangerous. It must provide five things: environment isolation, scoped short-lived credentials, reversible deploys, a human-approvable diff, and an audit trail of every action.

This is where Qovery sits, and it is also where Qovery closes the gap between Layer 2 and Layer 4 with Qovery Skills, an open-source, MIT-licensed skill pack that follows the Agent Skills standard and works with Claude Code, Cursor, OpenAI Codex, VS Code Copilot, Gemini CLI, and 30+ tools in total. You install it with one command:

curl -fsSL https://skill.qovery.com/install.sh | bash

That gives the agent a documented playbook and a scoped interface to Qovery - onboarding and BYOK setup, deploy, per-PR preview environments, Terraform generation from an existing setup, and least-privilege policy tokens - instead of raw cloud credentials and a pile of hand-written prompts. The agent still writes the code. Qovery Skills gives it the map and the API. Qovery does the deploy under guardrails.

The Qovery capabilities I will actually stand behind: it runs inside your own Azure subscription (BYOC, so the Azure bill, reservations, and any Enterprise Agreement discount stay in your name), git-push deploys, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. The identical setup lands on AWS, GCP, Scaleway, or an existing Kubernetes cluster, which matters because a large share of "Azure migrations" quietly end up hybrid or multi-cloud.

To be fair about the rest of Layer 4: Azure Landing Zones and the Cloud Adoption Framework give you the subscription, RBAC and policy scaffolding, but they are a design framework and reference IaC, not an agent execution layer. Terraform plus Atlantis gives you PR-based plan and apply with approvals for infrastructure, and stops there - no app deploy model, no ephemeral app environment per PR. Humanitec is a platform orchestrator for teams building their own internal developer platform, powerful but heavier to adopt. Northflank and Render are app platforms (Render runs on Render's own cloud rather than your account; Northflank offers BYOC). Coolify is a lightweight open-source, self-hosted PaaS, great on your own VMs, lighter on managed multi-cloud Kubernetes and enterprise RBAC and audit. On AWS, AWS Transform is the closest agentic-migration analogue, but it targets AWS, not Azure.

How do you run an agentic migration to Azure step by step?

Run it as a repeatable 6-step loop on one low-risk pilot service, with a human approval gate after every step and the rollback path written before the agent gets any write access. The loop is what makes agents useful, not the model you picked.

• Step 0 - pick the pilot and write success criteria first. One stateless service with real traffic and low blast radius, plus explicit thresholds for p95 latency, error rate, and cost delta. If you cannot define "good", you cannot let an agent chase it.
• Step 1 - give the agent read-only context and a playbook. Repo access, the Azure Migrate assessment output, an Azure MCP connection scoped to read, and the target architecture already decided by a human. This is where installing Qovery Skills in Claude Code, Cursor, or Codex saves the most setup time: the agent gets the migration playbook and the Qovery API surface in one command instead of you writing prompts from scratch.
• Step 2 - have the agent produce the plan as a pull request. Inventory, dependency map, proposed Azure services, and an explicit open-questions list. Read the open questions first. That list is the best signal you have of whether the agent actually understood the system.
• Step 3 - refactor in small, single-concern PRs. SDK swap, secrets moved to Key Vault references, health and readiness probes, Dockerfile, CI pipeline. Reject any PR that mixes two concerns, because you cannot roll back a mixed PR cleanly.
• Step 4 - deploy every PR to an ephemeral environment and let the agent read the real failures. Without this feedback loop the agent is guessing. With it, most IaC and config errors are caught before a human ever reviews them.
• Step 5 - shadow or canary traffic and compare against the Step 0 criteria, not against vibes.
• Step 6 - cutover with a human on the DNS switch, and keep the source environment warm for a defined rollback window. Write down who can call the rollback and how long the window lasts.

The honest cost: the agent compresses the mechanical weeks, but the first pilot still takes a couple of sprints because you are building the guardrails at the same time. The good news is the guardrails are reusable, so service number two and everything after goes far faster.

What guardrails keep an AI agent from breaking your Azure environment?

Scope the agent to the smallest permission set that still lets it be useful, keep it entirely out of production write paths, and make every action reviewable and reversible. An agentic migration is a permissions and platform problem before it is an AI problem.

• Least privilege. A separate identity per environment, Entra ID workload identity instead of long-lived client secrets, and zero standing production write access for the agent. This is not theoretical hygiene: Datadog's 2025 State of Cloud Security found 40% of Microsoft Entra ID applications had an access key older than a year. Long-lived credentials are the thing an over-eager agent will happily reuse. Anchor the separation in the Azure landing zone design principles, which use subscriptions to segregate dev, test and production.
• Environment isolation. Agents iterate in ephemeral non-production environments. Production changes arrive only as a reviewed pull request, never as an agent-issued API call.
• Reversibility. Every deploy revertible in one action, and every Terraform or Bicep change reviewed as a human-readable diff before apply. No auto-apply on infrastructure.
• Auditability. Log every tool call the agent made, its inputs, who approved it, and what changed. That is the record your incident review and your auditor will ask for, and it is the main reason to route agent actions through a platform instead of raw cloud APIs.
• Cost guardrails. Subscription budgets and alerts, quotas, and auto-stop on non-production, because retry loops and silent over-provisioning are the two ways agentic migrations blow the budget. Flexera's 2025 report already pegs 27% of cloud spend as wasted, with 84% of organizations struggling to manage it. An agent in a retry loop does not help.
• Secrets discipline. The agent never sees production credentials. Use Key Vault references and injected environment variables so the secret value stays outside the agent's context window.

Tie this back to Qovery plainly: per-environment RBAC, audit logs, one-action rollback, per-PR preview environments, and non-prod auto-stop are exactly the primitives an agent needs. Qovery Skills gives the agent a scoped, documented interface to them (including least-privilege policy tokens) instead of raw cloud credentials, running inside your own Azure subscription, or AWS, GCP, Scaleway, or your existing Kubernetes cluster.

How much time and money does an agentic migration to Azure actually save?

The realistic saving lands on the mechanical phases - dependency and runtime upgrades, IaC authoring, test scaffolding, runbook drafting - and it only materializes if you already have CI, IaC, and containerized workloads. Agents do not shorten discovery accuracy, the cutover window, or your organization's decision-making speed.

Set expectations with real numbers, not invented ones. AI adoption is near-universal but trust is not: 84% of developers use or plan to use AI tools while 46% distrust the output, and the METR trial measured a 19% slowdown on real tasks for experienced developers. Agentic migration works best on containerized estates, and 82% of container users now run Kubernetes in production per the 2025 CNCF survey, so most teams are eligible.

Where the money actually goes in a migration: rearchitecting effort, dual-running during cutover, data egress, and the post-migration Azure spend nobody rightsized. What agents do not fix: bad data models, undocumented cron jobs and glue scripts, missing test coverage, and slow approval chains.

The setup-time saving is real but bounded. A prebuilt skill pack like Qovery Skills removes the days you would otherwise spend wiring MCP servers, credentials, and prompts for each agent. It does not change the cutover window or the architecture decisions.

On FinOps, BYOC matters. If the migration lands in your own Azure subscription, you keep your reservations, savings plans, and Enterprise Agreement pricing. If it lands on a vendor's account, you pay their margin on top of the cloud bill. Same logic on AWS, GCP, and Scaleway.

A quick readiness check before you point an agent at the estate:

• Containerized?
• IaC in place?
• CI green?
• Automated tests exist?

Two or more "no" answers means fix those first. The agent will amplify whatever state you are in.

When should you not use an agentic migration to Azure?

Skip the agentic approach when the estate is stateful and heavily regulated, when there is no automated test coverage to give the agent a feedback signal, or when you are moving only a handful of services. In those cases the guardrail setup costs more than the work it saves.

Bad fits:

• Mainframe and legacy VM estates that need physical replatforming.
• Regulated data with residency constraints.
• Systems with zero automated tests.
• One-off migrations of 1 to 3 services.

Good fits:

• 20 or more containerized services.
• Monorepos needing the same mechanical change repeated many times.
• Framework and runtime version upgrades across many repos.
• Multi-cloud or hybrid targets where the same refactor has to be done twice.

The middle path most teams should take fits in one sentence: humans own the architecture and the cutover, agents own the repetitive refactor, and the platform owns the deploy.

If you want your agent to run the mechanical part on infrastructure you control, install Qovery Skills in your agent and spin up Qovery on your own cloud account.