AWS Transform Explained: What It Does, What It Costs, and Where It Stops

Key Points:

• AWS Transform is an agentic AI transformation workbench, not a single migration tool. Cross-functional teams run jobs in a shared workspace where domain-expert AI agents handle discovery, propose migration plans, and write code changes that humans approve step by step.
• It covers a defined set of workload families today: infrastructure (VMware, bare metal, Hyper-V, Nutanix, KVM), Windows and .NET modernization, mainframe, storage arrays to Amazon EBS or FSx for NetApp ONTAP, AI workloads assessed against Amazon Bedrock, plus custom code upgrades and continuous modernization scanning.
• AWS Transform is mostly free to run. The migration and modernization agents (VMware, Windows/.NET, mainframe, assessment) carry no charge, and only custom code transformations and continuous modernization are metered, at $0.035 per agent-minute (AWS Transform pricing). Confirm the current model there before you budget.
• No, AWS Transform does not give you a developer platform. It lands workloads on EC2, ECS, EKS, Aurora PostgreSQL, EBS, FSx, and Bedrock, and stops there. Deployment pipelines, environment provisioning, preview environments, per-environment RBAC, cluster upgrades, and cost guardrails stay your engineering work.
• That day-2 gap is where an internal developer platform fits. Qovery adds git-push deployments, preview environments per pull request, environment auto-stop, managed cluster upgrades, and per-environment RBAC inside your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster - so the cloud bill and any Savings Plans stay in your name.

No, AWS Transform does not give you a developer platform. It is a strong migration and modernization service, and it will move a legacy estate onto AWS faster than a room full of consultants, but the day it finishes, your developers still cannot deploy, get a test environment, or ship a change without a ticket.

I have watched teams treat a migration as the finish line and then go quiet when they realize the thing slowing them down was never the old servers. It was everything that happens after the workload lands. So let me be fair about what AWS Transform is genuinely good at, and precise about where it stops.

Does AWS Transform give you a developer platform after the migration is done?

No. AWS Transform is a migration and modernization workbench that discovers, replatforms, and rewrites legacy workloads onto AWS services, then hands you raw AWS infrastructure plus your modernized source code. The developer-facing platform layer - self-service deploys, environments per pull request, RBAC, cluster lifecycle, cost controls - is not included and stays yours to build or buy.

Here is the answer block in four sentences you can quote on its own:

1. AWS Transform is AWS's agentic AI workbench for migrating and modernizing legacy workloads - VMware estates, Windows and .NET applications, mainframe code, storage arrays, and AI workloads - onto AWS.
2. It works as a shared workspace where domain-expert AI agents run discovery, propose a migration plan, and write code changes that your team approves at each gate, so humans stay in the loop instead of typing every command (AWS Transform User Guide).
3. Most of it is free to run: the migration and modernization agents carry no charge, and only custom code transformations and continuous modernization are metered, at $0.035 per agent-minute (AWS Transform pricing).
4. At the end you get modernized code in your repositories and workloads running on native AWS services (EC2, ECS, EKS, Aurora PostgreSQL, EBS, FSx for NetApp ONTAP, Amazon Bedrock) and nothing above that: no deployment pipeline, no environment model, no platform for your developers.

A migration is a finite project with an end date. A platform is a permanent product with an owner. AWS Transform owns the first one only, and it says so plainly on its own product page.

What is AWS Transform, exactly, and how does it work?

AWS Transform is AWS's agentic AI service for the transformation of infrastructure, applications, and code, run through a unified web experience where AI agents own the labor-intensive parts of discovery, planning, and execution (AWS Transform User Guide).

The model is a workbench, not a wizard. You work inside a workspace, which AWS defines as a permissions boundary that holds your connectors and jobs. A job is a long-running process - AWS describes it as running for weeks or months - made up of tasks the agents perform and collaborator requests, which are the points where the agent asks a human to do or approve something. Roles matter here: an administrator can approve the critical human-in-the-loop actions such as merging to main or deploying to production, while a contributor can work a job but cannot approve those gates. That approval structure is the whole point of the "agentic but supervised" design.

AWS Transform also absorbed the older migration plumbing rather than replacing it. As of June 2026, AWS Application Migration Service (MGN) is branded AWS Transform MGN and described as the replication engine powering the agentic service, with an agentic path and a self-directed path that share the same underlying replication and cutover engine (AWS). So Transform sits above and alongside AWS Migration Hub, Application Discovery Service, and MGN, and teams can work the agentic experience or drop to the manual one.

On scale and recognition, AWS reports that in its first year AWS Transform analyzed 4.5 billion lines of code and saved 1.6 million hours (AWS Transform one-year milestone), and AWS says it was named a Leader in the 2026 Gartner Magic Quadrant for AI-Augmented Code Modernization Tools, positioned highest for ability to execute (AWS). You reach it through the web experience and, since 2026, from your IDE and coding agents: AWS ships AWS Transform access in Kiro, Claude, Cursor, and Codex, plus an MCP server for custom integrations (AWS Transform developer tools). It runs in a set of commercial Regions including US East (N. Virginia), Frankfurt, London, Mumbai, Sydney, Tokyo, Seoul, and Canada (Central), with São Paulo for mainframe work (AWS Transform Regions); the agentic service is not listed for AWS GovCloud (US), where only the MGN replication engine carries the GovCloud compliance story.

Where is it genuinely strong? Large VMware estates, .NET Framework debt nobody can hand-upgrade, undocumented COBOL business rules, and storage arrays coming off support - the exact work that otherwise burns months of manual discovery. This is a good product for that job.

What are the AWS Transform agents, and what does each one migrate?

AWS Transform ships a set of workload-specific capabilities - infrastructure, Windows/.NET, SQL Server, mainframe, storage, AI workloads, custom code, and continuous modernization - and each one takes a source estate, proposes a plan, and produces AWS-native targets plus modernized code under human review. Worth a caveat: AWS markets VMware, .NET, and mainframe as named agents, while SQL Server modernization is a named capability and the AI-workloads and custom-code paths are documented as "custom transformations." This snapshot is from September 2026, and AWS ships to this lineup often, so check the AWS Transform docs for the current list.

• Infrastructure / VMware. Sources include VMware, bare metal, Hyper-V, Nutanix, and KVM; it does discovery, dependency mapping, wave planning, landing-zone and network mapping, and cutover to EC2 (AWS Transform FAQ).
• Windows / .NET. Transforms .NET Framework and .NET Core through .NET 10 up to modern cross-platform .NET, across class libraries, console apps, ASP.NET (MVC, Web API, Web Forms), and WCF services, targeting Linux-ready runtimes on EC2 and ECS (.NET docs).
• SQL Server modernization. Converts SQL Server schemas and stored procedures to Aurora PostgreSQL, migrates the data through AWS DMS, and rewrites the .NET data layer including Entity Framework and ADO.NET (SQL Server modernization docs).
• Mainframe. Runs an "Assess and reimagine" workflow that assesses the COBOL, JCL, CICS, and DB2 estate, extracts business logic, and generates requirements traceable back to the original source code, then reforges it into idiomatic Java on Spring Boot, with developer review in Kiro (mainframe workflow docs).
• AI workloads. A model-to-model assessment that maps workloads built on OpenAI, Google Gemini, Anthropic, or open-source model APIs to Amazon Bedrock, with SDK translation guidance and a cost comparison (AWS). Read it as a migration plan, not a one-click cutover.
• Storage. Moves block storage from NetApp, Dell, Pure Storage, and VMware environments to Amazon EBS or FSx for NetApp ONTAP, as part of the same migration wave (AWS).
• Custom code transformations. Version upgrades such as Java 8 to 17, Python 3.9 to 3.13, and Node.js 12 to 22, plus organization-specific rules applied consistently across many repositories (custom docs).
• Continuous modernization. Scans repositories for end-of-life dependencies and off-standard frameworks and runs as an ongoing service across the portfolio, not a one-time project phase (AWS).

The published customer numbers are real and worth respecting. AWS cites Grupo Tress Internacional cutting about 70% of its .NET modernization effort, Nomura Research Institute compressing a mainframe analysis from roughly a month to about a week, and SourceFuse reporting up to 90% faster VMware execution (AWS Transform GA). AWS also markets .NET modernization as up to four times faster and VMware discovery and wave planning as up to 80 times faster than manual work (AWS Transform for VMware).

Is AWS Transform free, and what does it actually cost?

Yes, most of AWS Transform is free to run. The migration and modernization agents - VMware, Windows/.NET, mainframe, and assessment - carry no charge, and only two things are metered: custom code transformations and continuous modernization, both billed at $0.035 per agent-minute, where an agent-minute is a unit of work the agent performs during a transformation (AWS Transform pricing). AWS gives illustrative examples on that page, such as an SDK upgrade landing around $0.70 and a Java upgrade around $2.52, and you are not billed for local build or test wait time. So starting costs nothing, and even a large modernization program's Transform bill tends to be small relative to what comes next.

The trap is confusing three very different cost buckets:

• AWS Transform usage is the metered agent work above. Mostly free, occasionally a few dollars per transformation.
• The run-rate AWS bill of the landed workloads (EC2, ECS/EKS, Aurora, EBS, FSx, Bedrock) is permanent and dwarfs the migration cost within the first quarter.
• The platform engineering to make those workloads shippable - pipelines, environments, RBAC, cluster upgrades - is also permanent, and it is paid in salaries, not in the AWS console.

Migration spend is one-off. Run-rate and platform cost never stop. That distinction is where cloud budgets go wrong: McKinsey found 75% of businesses ran their public-cloud migration over budget and 38% ran over schedule (McKinsey), and most of that overrun is the recurring cost nobody sized, not the migration itself.

To size it honestly, skip fake dollar figures and estimate in three parts: metered agent-minutes from the size of the code you will custom-transform, plus the steady-state run-rate of the landed infrastructure, plus the headcount (or platform license) to build and run the day-2 layer.

Where does AWS Transform stop, and what still lands on your platform team?

AWS Transform stops the moment a workload runs on AWS. Everything your developers touch after that is unsolved and permanently yours: deployment pipelines, environment provisioning, preview and ephemeral environments per pull request, per-environment RBAC, secrets and config promotion, managed Kubernetes cluster upgrades, environment auto-stop for non-production, per-team cost attribution, and on-call runbooks.

This is where the ROI story quietly collapses. You modernize the estate, cut over cleanly, and then a developer still files a ticket to get a staging environment and waits two days for it. Lead time does not move, and lead time is one of the four measures DORA uses to separate elite from low performers - elite teams deploy on demand with change lead times under a day, low performers measure both in weeks or months (DORA metrics guide). A migration that leaves that number untouched has not changed how the business ships.

The idle-spend bill is just as real. Flexera's 2025 report puts wasted cloud spend at 27% of the total, and non-production environments left running 24/7 are the most common source (Flexera 2025 State of the Cloud). And the clusters themselves need owners: 82% of container users now run Kubernetes in production (CNCF 2025 survey), and none of those clusters upgrade, scale, or patch themselves.

So budget the platform layer as a product with an owner, not as leftover migration scope. You close the gap one of three ways: build a bespoke platform on Terraform, Argo CD, and Backstage; adopt an internal developer platform; or stay ticket-driven and accept the lead time. Each has a real cost, and the last one is the most expensive even though it never shows up on an invoice.

How do you get a developer platform after an AWS Transform migration?

You close the gap by choosing one of those three paths, and the middle one - adopting an internal developer platform that runs inside your own cloud account - is where Qovery fits. Qovery is an internal developer platform that deploys and operates your applications inside your own cloud account (BYOC), so the cloud bill, your Savings Plans, and any negotiated discounts stay in your name. It sits on top of the exact AWS account AWS Transform just landed workloads in, and it works the same way on GCP, Azure, Scaleway, or an existing Kubernetes cluster.

The capabilities map directly onto the day-2 gap: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. That matters because the DORA research is honest about the risk of getting this wrong - its 2024 report found internal developer platforms lifted individual productivity by about 8% and team performance by about 10%, but a poorly built one dragged throughput and stability down at the same time (DORA 2024). Building the platform badly is worse than not building it, which is the strongest argument for adopting one that already works.

Sequence the two clearly. AWS Transform moves and rewrites the workload. Qovery gives your developers the interface to ship and operate it afterward. They are complementary, not competing - one ends, the other runs for as long as the app lives.

One more point I will make twice because this article is AWS-heavy by topic: none of this is AWS-only. Most post-migration realities end up partly multi-cloud, and Qovery runs identically on AWS, GCP, Azure, Scaleway, or your own self-managed Kubernetes cluster, on-prem or any distribution.

Be fair to the alternatives, because each does its own job well. Backstage is a developer portal and service catalog with no runtime and no deployment engine of its own. Argo CD is excellent GitOps delivery to Kubernetes, but it syncs manifests to clusters you already run and has no environment model. Humanitec is a platform orchestrator aimed at platform teams building their own IDP. And a note on the two AWS-native options: AWS Proton is template-driven and AWS-only but reaches end of support on October 7, 2026, and AWS App Runner is a narrow managed container runtime that stopped accepting new customers on April 30, 2026. If you were counting on either to be your platform layer, that is worth knowing now.

How does AWS Transform compare to AWS Migration Hub, MGN, and other migration tooling?

AWS Migration Hub tracks a migration portfolio, AWS Application Migration Service (now AWS Transform MGN) lifts and shifts servers block by block with no code change, and AWS Transform adds the agentic layer that plans waves and rewrites application code - so they solve adjacent problems and are usually used together, not instead of each other.

Migration Hub is portfolio discovery and progress tracking across your migration tools; it does not refactor anything itself. MGN is the rehost engine that replicates servers to EC2 as-is. AWS DMS and the Schema Conversion Tool handle the database side - data movement and schema conversion - which is exactly what Transform's SQL Server to Aurora work builds on (AWS DMS). The decision rule is simple: rehost with MGN when the app is fine as-is, and reach for AWS Transform when the code or the platform itself is the blocker.

Who should use AWS Transform, and who should skip it?

Use AWS Transform if you have a large legacy estate on its target list - hundreds of VMs, .NET Framework apps nobody can hand-upgrade, mainframe business rules with no living owner, storage hardware coming off support, or third-party LLM APIs you want on Bedrock - and a committed AWS destination. That is the work it was built for, and it will save you real months.

Skip it, or at least deprioritize it, if your applications are already containerized and running on Kubernetes, if your estate is small enough that discovery overhead exceeds the work, or if your destination is GCP, Azure, Scaleway, or a self-managed cluster. AWS Transform targets AWS services by design, so it is the wrong tool when the destination is not AWS. And if your real complaint is that developers wait days for an environment, a migration will not touch that - your bottleneck is the platform layer, not the estate.

A short readiness checklist you can run today: inventory the estate, map it to the agent list above, price the metered agents, and decide who owns the platform layer before the first wave ships. Do that last step in the same document as the migration plan, or you will finish the migration and your developers will feel like nothing changed.

If you want the platform layer handled the day the migration lands, spin up Qovery on your own cloud account and give your team self-service deploys and preview environments on the infrastructure AWS Transform just built.