AWS Automated the Migration. Nobody Automated the Day After.

Key points:

• AWS Transform automates migration, not operations. Its published outputs are portfolio assessments, wave plans, containerized workloads on Amazon ECS and EKS, servers rehosted to EC2, Landing Zone Accelerator configurations, and IaC templates. It does not produce an environment model, developer self-service, preview environments per pull request, per-team RBAC, or per-team cost attribution.
• The reported speedups are real. AWS reports portfolio assessment in days instead of a three-month engagement, wave planning in about an hour instead of six to eight weeks, and containerization in one to two hours per application instead of five to ten days. I checked each figure on AWS's own pages before writing this.
• Every hyperscaler draws the same line. Azure Migrate and Google Cloud Migration Center both stop at planning and migration too. Day-two operations is an industry-wide gap, not an AWS gap.
• Rehosting stopped winning on arithmetic. At five to ten engineer-days per app, replatforming 500 applications cost roughly 16 engineer-years. At one to two hours per app it costs roughly 0.4 engineer-years. That flip means far more estates will land on Kubernetes by default than by decision.
• The test after cutover is operational. Can an agent create an environment, deploy a service, provision a database, and tear all of it down inside scoped permissions with an audit trail, without a human approving routine cases? Chat-driven kubectl and IaC generation both fail that test. An internal developer platform, built on Backstage or bought as Humanitec, Port, or Qovery, is what passes it.

---

Did AWS actually automate cloud migration?

Yes. AWS Transform uses AI agents to run portfolio assessment, wave planning, and containerization, and AWS reports each one collapsing from months or weeks down to hours in its own write-up of the service.

I do not think this is hype, and I do not think the manual version of these three steps is coming back. The numbers AWS publishes are specific. A migration business case that "used to require a three-month consulting engagement" now completes "in days." Migration planning that "takes a team of architects six to eight weeks" completes "in an hour," even for estates with tens of thousands of VMs. Containerization "tasks that previously took five to ten days per application now take one to two hours." All three figures are on the AWS Migration and Modernization blog, and the underlying replication technology "can rehost 1000 servers in less than 24 hours."

Agentic migration here means something concrete. Agents read the estate, group dependencies into ordered waves, and rewrite build files, project files, and manifests, with a human reviewing the output rather than producing it. Per the AWS Transform user guide, the work spans several tracks, including .NET and Windows modernization, VMware migration, and mainframe (IBM z/OS) transformation, each targeting EC2, ECS, or EKS.

My read is simple. The part that got automated is the part with a start date and an end date. AWS did that part well. The disagreement is about scope, and it starts in the next section.

If migration is solved, why did the bottleneck move instead of disappear?

Because migration has a finish line and operations does not. In AWS's own CSL case study, the company worked through 1,072 applications running on over 5,000 VMware servers across 29 data centers, and somebody now has to deploy, isolate, and pay for those applications next Tuesday, and the Tuesday after that.

The published CSL results are genuinely strong. AWS reports the wave-planning exercise "saved a minimum 10.5 weeks of effort for 1072 applications," brought "the application discovery process time to five minutes from one to two hours per application," and is projected to deliver "30% operational cost savings" from licensing, hardware, and data-center costs. I am not criticizing CSL or AWS here, and CSL is not a Qovery customer. I am pointing at the shape of the numbers: every figure describes the move, and none of them describes the operating years that follow it.

That is the structural point. Migration was the visible slice because it had a Gantt bar and a named end date. Day-two operations is the larger slice with no end date and, in most organizations, no named owner. At 1,072 applications, "day two" means deploys and rollbacks, secrets rotation, standing up a database for a new service, spinning a staging environment for a contractor, onboarding a team that joined after cutover, and decommissioning environments nobody remembers creating.

The unbounded side has numbers too, and they are not flattering:

• 29% of public cloud spend is wasted, per the Flexera 2026 State of the Cloud Report, the first increase in five years. Idle non-production environments are a large part of that.
• Reducing waste was the single highest priority for FinOps practitioners in the State of FinOps 2024, ahead of every other goal. It stays a top priority in the 2025 data.
• 76% of teams say Kubernetes complexity has inhibited their adoption, per the Spectro Cloud 2024 State of Production Kubernetes report. Cutover does not remove that complexity. It hands it to whoever is on call.

Migration compressed from months to hours. The operating burden it feeds into did not compress at all.

What does AWS Transform actually produce, and what does it leave out?

AWS Transform produces infrastructure artifacts. Per the user guide, that means discovery and portfolio assessments, prioritized migration waves, applications containerized from source code to Amazon ECS or EKS, servers rehosted to EC2, landing-zone creation, and IaC generated as CloudFormation, AWS CDK, and Terraform. It produces nothing about how an application team gets an environment on its own, and that is a deliberate scoping decision, not a defect.

Here is what it does not output, because it was never meant to:

• An environment abstraction an application team can reason about.
• Self-service for those teams, so they deploy without a ticket.
• Preview or ephemeral environments per pull request.
• RBAC an application team can live inside day to day.
• Per-team or per-environment cost attribution.
• A repeatable answer for application number 200, six months after the migration team disbanded.

I want to be fair about one thing. AWS also ships continuous modernization, and the instinct behind it is correct. It runs a "read-only scan of your code" from GitHub, Bitbucket, or GitLab and proposes remediation, so modernization keeps going after the first wave. The precise line is this: it operates on repositories. Modernizing code is not operating an estate.

This boundary is an industry norm, not an AWS quirk. Azure Migrate is scoped to "decide on, plan, and execute your migration," which means discovery, dependency analysis, assessment, and replication. Google Cloud Migration Center is scoped to discovery, assessment, TCO estimation, and planning, and its own docs say the tools let you plan "without making changes to your applications or workloads." All three end at the same place.

The right-hand column is the whole argument. Most of it reads "platform team or nobody yet," and "nobody yet" is where the cost hides.

Is rehosting still cheaper than replatforming in 2026?

No, not on the arithmetic that made rehosting the default. At five to ten engineer-days per application, replatforming 500 applications cost roughly 16 engineer-years, and the spreadsheet always said rehost. At one to two hours per application it costs roughly 0.4 engineer-years, so the cost argument for lift-and-shift is gone and the cost moves to day two.

Here is the multiplication in full, so you can rerun it with your own portfolio:

• 500 applications. A conservative large-enterprise estate. The MuleSoft 2023 Connectivity Benchmark puts the average organization at 1,061 applications, so 500 is on the low side.
• 7 engineer-days per app, pre-agentic (midpoint of AWS's five-to-ten-day figure), at 8 hours a day: 500 x 7 x 8 = 28,000 hours.
• 1,760 productive hours per engineer-year: 28,000 / 1,760 = about 16 engineer-years.
• 1.5 hours per app with agentic tooling (midpoint of AWS's one-to-two-hour figure): 500 x 1.5 = 750 hours, or about 0.4 engineer-years.

Rehosting has historically won that comparison by default. AWS's own migration guidance, building on Gartner's original migration taxonomy, has long said the majority of applications in large legacy migrations are rehosted, because it was the fastest and cheapest path. Agentic tooling removes the "expensive" half of that trade-off. When replatforming an application costs an afternoon, far more estates will land on containers and Kubernetes by default rather than by decision, operated by teams who never chose Kubernetes and have no platform above it.

The operational surface those teams inherit is not small. The Spectro Cloud 2024 report finds the typical adopter now runs more than 20 clusters, and the CNCF 2023 Annual Survey finds 46% of organizations early in their cloud-native journey name lack of training as the biggest barrier. The migration line item goes away and four new ones replace it: cluster upgrades, RBAC design, non-production cost sprawl, and on-call for a platform nobody staffed. This flip is cloud-neutral. It happens on AWS, GCP, Azure, Scaleway, and on the self-managed Kubernetes clusters a lot of teams already run.

What should agentic modernization mean after cutover, and can an AI agent safely operate a live estate?

It should mean agents keep operating the estate, not that one agent migrated it once. An agent can operate production safely only with four things in place: an environment object it can act on, scoped permissions it cannot exceed, an audit trail of every action, and a guaranteed teardown path. Without those, agent access to production is an incident waiting for a prompt.

Apply that four-part test to the common options:

• Chat-driven kubectl fails it. The blast radius is unbounded, there is no environment object to scope to, no teardown guarantee, and no per-team boundary. One confidently wrong command reaches everything the credential can reach.
• IaC generation alone fails it. A generated Terraform or CDK template is not a running environment, and plan-apply loops still put a human in the middle of every routine case. You get faster authoring, not autonomous operation.
• GitOps with Argo CD or Flux passes part of it. It gives you an audit trail and a declarative desired state, but it does not give an agent an environment abstraction or scoped self-service on its own. You still build the layer above it.

The credible day-two options split by team shape. If you have a staffed platform team, you can build the abstraction in-house on Backstage and own it forever. If you want to buy the orchestration layer, Humanitec and Port both sit on top of your existing clusters. If you want the environment layer and the runtime managed for you inside your own account, that is where a platform like Qovery fits.

Here is the one honest paragraph on Qovery. Qovery treats environments as first-class objects an agent or a developer can create, deploy to, and tear down: git-push deploys, preview environments per pull request, environment auto-stop for non-production, per-environment RBAC, and managed cluster upgrades, with databases backed by managed cloud services. It runs inside your own AWS, GCP, Azure, or Scaleway account, or an existing self-managed Kubernetes cluster, under bring-your-own-cloud, so the cloud bill and any Savings Plans stay in your name. And the Qovery MCP server gives an agent that same governed API to act through, which is the practical form the four-part test takes. If you want the wider category context, Qovery keeps a hub on agentic infrastructure.

I will concede the obvious. A well-staffed internal platform team building on Backstage, Humanitec, or Port is a legitimate answer, and for some organizations the right one. The argument is that something has to own day two, not that it has to be Qovery. The fact that 90% of organizations now report using an internal developer platform, per DORA, tells you the market already reached that conclusion.

What should a CIO decide before a data center exit, not after?

Three things, all decided before cutover: rehost or replatform on 2026 arithmetic, who operates the result on day one as a named team with a budget line, and how an application team gets an environment without filing a ticket. All three get made anyway. They just get made badly, in month seven, by whoever happens to be on call.

• Decision 1: rehost or replatform, per application tier, on current agentic costs. The five-to-ten-day penalty that made rehost the default is gone. Decide tier by tier, not as a program-wide reflex carried over from 2019.
• Decision 2: who operates the result on day one. A named team with a named budget line, staffed before cutover, not recruited after the migration consultants have rolled off.
• Decision 3: how an application team gets an environment without a ticket. Written down and rehearsed with a real team before the last wave moves.

A short checklist you can lift into a migration steering doc:

• Rehost-or-replatform decision recorded per tier, with the 2026 cost math attached. Artifact: a signed tiering sheet.
• Day-two operating team named and funded. Artifact: a headcount and budget line, not a vacancy.
• Self-service path proven. Artifact: a real app team deploying to a fresh environment with no ticket, before cutover.

The corollary is blunt. If you cannot answer decision 3, you have not finished the migration. You have relocated the queue from the old data center to the new cloud account.

The migration was the easy half, and the industry just proved it.

Does AWS Transform handle post-migration operations or day-two management?

No. AWS Transform automates assessment, wave planning, containerization, rehosting, and landing-zone and IaC generation, per the AWS Transform user guide. It does not provide developer self-service, an environment abstraction, preview environments, per-team RBAC, or per-team cost attribution. Operating the estate after cutover is left to your platform team or an internal developer platform.

What does AWS Transform actually produce as output?

AWS Transform produces portfolio assessments, prioritized migration waves, applications containerized to Amazon ECS or EKS, servers rehosted to EC2, landing-zone configurations including Landing Zone Accelerator format, and IaC as CloudFormation, AWS CDK, and Terraform. It also runs continuous modernization as a read-only scan of source code in GitHub, Bitbucket, or GitLab. Every output is an infrastructure artifact, not a running self-service platform.

How long does a data center exit take with agentic migration tooling like AWS Transform?

Faster than before, though the total still depends on estate size and testing. AWS reports portfolio assessment in days instead of a three-month engagement, wave planning in about an hour instead of six to eight weeks, and containerization in one to two hours per application instead of five to ten days, in its own write-up. The planning and cutover compress dramatically. The operating years that follow do not.

Is rehosting still cheaper than replatforming in 2026?

No, not on the arithmetic that made it the default. When replatforming cost five to ten engineer-days per application, a 500-app estate ran to roughly 16 engineer-years and lift-and-shift almost always won. With agentic tooling at one to two hours per application, that drops to roughly 0.4 engineer-years, so the cost advantage of rehosting is gone and the real cost moves to day-two operations.

Who operates applications after a cloud migration is complete?

In a well-run organization, a named platform team with its own budget, ideally staffed before cutover. In practice it often falls to whoever is on call, because migration tooling from AWS, Microsoft, and Google all end at cutover and no vendor hands you an operating model. This is why 90% of organizations now report running an internal developer platform, per DORA.

Can an AI agent safely create, deploy to, and tear down environments in production?

Yes, but only with four things in place: an environment abstraction the agent can act on, scoped permissions it cannot exceed, an audit trail of every action, and a guaranteed teardown path. Chat-driven kubectl and raw IaC generation lack most of these, so they are not safe for autonomous production use. An internal developer platform that exposes environments as governed objects, such as one reached through an MCP server, is what makes it safe.

How is an internal developer platform different from AWS Transform, Azure Migrate, or Google Cloud Migration Center?

The migration tools move you to the cloud and then stop. An internal developer platform runs after cutover, giving application teams self-service environments, preview environments per pull request, per-team RBAC, and cost attribution. Azure Migrate and Google Cloud Migration Center draw the same boundary AWS Transform does, so an IDP, whether built on Backstage or bought, is a separate layer you add on top.