AWS Transform: What It Does, What It Costs in 2026, and Where It Stops

Key Points:

• AWS Transform is an agentic AI service from AWS that automates discovery, wave planning, and code or configuration conversion for three workload families: VMware estates, mainframe applications (mostly COBOL), and .NET Framework apps ported to cross-platform .NET on Linux. It reached general availability on 15 May 2025 and runs as a browser-based, multi-agent experience with human approval gates.
• The core migrations are free; the newer bits are metered. As of September 2026, the AWS Transform pricing page lists migration and modernization of Windows, VMware, and mainframe systems "at no cost," and prices custom transformations and continuous modernization as paid features at "$0.035 / agent minute." So the service is close to free for the classic three, but not a flat zero across the board.
• The tool fee is the smallest line item in a real project. The budget is dominated by target-state EC2/EBS/RDS, Windows and SQL Server licensing (a license-included Windows instance runs close to double the Linux rate), the parallel-run window where you pay source and target at once, and the engineering time to validate what the agents generated.
• AWS Transform covers the one-time lift only. It gives you inventory, dependency graphs, wave plans, network config conversion, COBOL decomposition, and .NET refactoring. It gives you no CI/CD, no preview environments, no per-environment RBAC, no cluster upgrades, and no developer self-service after cutover. That day-2 platform layer is a separate, recurring build-or-buy decision.
• AWS Transform only targets AWS. If you want to keep the option of running on GCP, Azure, Scaleway, or your own Kubernetes cluster, pick a cloud-agnostic platform layer for day 2 so the modernization work does not have to be redone.

---

If you searched "how much does AWS Transform cost," you are building a business case, so here is the number first: AWS charges no separate fee for the migration and modernization of Windows, VMware, and mainframe workloads, and meters the newer custom and continuous-modernization features at $0.035 per agent minute, per the official pricing page I checked on 21 September 2026. The tool is the cheapest part of the project.

I have sat in enough migration planning meetings to know where the real money goes, and it is never the migration software. It is the AWS bill you inherit on the other side, the Windows and SQL Server licensing riding on top of it, the months you pay for both the old estate and the new one, and the engineers who read every line the agents wrote. Let me walk through what AWS Transform actually does, what it costs once you add all of that up, how it stacks against Azure, Google Cloud, and Broadcom, and the second project most teams forget to budget.

What is AWS Transform, and what does it actually do?

AWS Transform is an agentic AI service from AWS that automates the discovery, planning, and code or configuration conversion phases of moving VMware, mainframe, and .NET workloads onto AWS. It is a multi-agent web experience with human-in-the-loop approval steps: it produces plans, converted configs, and refactored code, and it does not host or run anything.

The capabilities were previewed as Amazon Q Developer transformation features at re:Invent 2024, then repackaged and shipped as a standalone service that reached general availability on 15 May 2025. Three agents went GA together: VMware, mainframe, and .NET. AWS has since widened the product scope to include Windows and SQL Server modernization, database transformations, and even AI-workload migration from OpenAI, Gemini, and Anthropic to Amazon Bedrock, with several of those still marked preview. Verify the current list on the AWS Transform page before you scope a project, because the packaging keeps moving.

The concrete deliverables are worth naming, because they are what you are paying engineers to review:

• Inventory: a hardware and application inventory of the source estate, assembled from connectors into your accounts.
• Dependency graphs: application dependency maps so you know what breaks if you move a given server.
• Wave plans: grouped migration waves so you cut over related workloads together instead of one server at a time.
• VMware network conversion: on-premises VMware network configurations translated to AWS equivalents, which AWS says runs up to 80 times faster than doing it by hand.
• COBOL decomposition: monolithic z/OS COBOL broken into components with generated business-logic documentation, "in minutes instead of months" in AWS's own words.
• .NET refactoring: Windows-based .NET Framework apps ported to cross-platform .NET on Linux, which AWS states is "up to four times faster" and can deliver "up to 40% savings in licensing costs."

Here is where AWS Transform sits next to the rest of the AWS migration stack, so you know what it is not doing. AWS Application Migration Service (now branded AWS Transform MGN) does the block-level replication and cutover. AWS Mainframe Modernization runs the refactored or replatformed mainframe workload afterward. AWS Migration Hub tracks progress across the portfolio. AWS Transform does the analysis and conversion, and then hands off.

Say it plainly: AWS Transform is not a PaaS, not a CI/CD system, not a Kubernetes platform, and not a runtime. It only targets AWS. It is a modernization workbench, not a place your apps live.

How much does AWS Transform cost in 2026?

As of 21 September 2026, the official AWS Transform pricing page lists no charge for migrating and modernizing Windows, VMware, and mainframe systems, and prices the newer custom transformations and continuous modernization at "$0.035 / agent minute." The AWS-managed .NET transformation includes "up to 50,000 agent minutes/month" at no additional cost, and unused minutes do not roll over. Budget the project, not the tool: the post-migration AWS bill, Windows and SQL Server licensing, the parallel-run overlap, and engineering validation time are where the money actually goes.

The cost stack breaks into layers you can drop straight into a spreadsheet:

• AWS Transform service fee: free for the core three workload types; $0.035/agent minute for custom or continuous work beyond the included .NET allowance.
• AWS Transform MGN replication: free for 2,160 hours (90 days) per source server, then roughly $0.042/hour per server after that, and you pay for the EC2 and EBS the replication provisions the entire time, free period included.
• Target EC2/EBS/RDS: the recurring compute, storage, and database bill for everything you moved. This is the real number, and it runs forever.
• Windows and SQL Server licensing: license-included Windows instances cost close to double the Linux rate for the same hardware (more below).
• AWS Mainframe Modernization runtime: for mainframe targets, AWS charges $0.31 per AWS CPU core per hour for the AWS Transform managed runtime, with third-party engines like Rocket priced far higher.
• Data transfer and support: egress and inter-AZ traffic, plus AWS Business or Enterprise Support, which is priced as a tiered percentage of your monthly AWS spend (up to about 10% at the low end), not a flat fee.
• Partner/SI fees: the humans running the project (below).
• Day-2 platform: the pipelines, environments, and access control you build after cutover, which is recurring cost forever.

The parallel-run trap is the single biggest one-time surprise. For weeks or months you keep paying VMware or mainframe maintenance while the AWS bill ramps, because you cannot switch off the source until the target is validated. Two full infrastructure bills at once, and the longer validation drags, the worse it gets.

The licensing premium is easy to quantify. An m5.xlarge (4 vCPU, 16 GiB) in us-east-1 runs $0.192 per hour on Linux, on-demand. The identical instance with a license-included Windows build costs close to double that, because AWS bakes the Windows Server license into the hourly rate. Multiply that gap across a few hundred Windows servers running 24/7 and it dwarfs anything the migration tool ever charged you.

Here is a worked illustration, and I want to be clear about what it is: numbers assembled only from published AWS list prices (us-east-1, on-demand, September 2026), not a quote and not a real customer. Take a 100-VM VMware estate and map each VM to an m5.xlarge as a rough average. On Linux that is $0.192 x 730 hours x 100 = about $14,000 per month in compute. Add 200 GB of gp3 storage per VM (20,000 GB at $0.08/GB-month) for another $1,600 per month. Call it roughly $15,600/month, near $187,000 per year, before data transfer, RDS, or support. Move the same estate to license-included Windows and the compute line alone climbs to about $28,000/month. A real estate mixes instance sizes and would apply Savings Plans, but the shape holds: the run cost, not the migration, is the project.

On the human side, published day rates give you a verifiable anchor. AWS Professional Services' own G-Cloud 14 rate card on the UK Digital Marketplace lists a Staff Consultant (SFIA Level 5) at £2,736 per day, with senior and principal consultants running higher. A migration wave that needs a couple of consultants for a few months is a six-figure line before you count your own engineers' time.

Two things worth knowing. First, AWS Savings Plans and EDP commitments frequently fund these projects, and that discount lives in your own AWS account, which matters a lot for what you choose to run on top later. Second, the risk is real: Flexera's 2025 State of the Cloud Report found 84% of organizations struggle to manage cloud spend, with budgets running about 17% over. A migration is exactly the moment that gap opens up.

Is AWS Transform free, and what are you really paying for?

AWS Transform is free for the workloads most people mean when they ask, the Windows, VMware, and mainframe migrations, which carry no separate service fee. It is not free in the sense that matters to a business case, because every dollar moves to the AWS resources it provisions and to the engineers who review what the agents produced.

This is the same commercial pattern as AWS Transform MGN and AWS Migration Hub, both of which carry no tooling fee. AWS monetizes the destination, not the migration path. That is a rational strategy on their part and a trap on yours if you read "no service charge" as "no cost."

During the transform phase itself, the meter runs on agent-provisioned compute, storage for artifacts and inventories, replication servers, and the staging and test environments you spin up to validate each wave. None of it is exotic, and all of it adds up while the project is live.

The most underestimated line item is not a machine at all. It is engineer review hours on generated output, especially business-logic-heavy COBOL decomposition and .NET refactors, where a passing build tells you the code compiles and nothing about whether it still does what the business needs. AI-generated conversion is fast to produce and slow to trust, and the trusting is where your senior people spend their weeks.

A budgeting rule of thumb I would give any team: model 12 months of target-state run cost before you model the migration itself. The migration is a one-time hump. The run cost is the thing you signed up to pay every month after, and it dominates the total.

One real offset worth chasing is the AWS Migration Acceleration Program (MAP), which AWS describes as offering financial investment and incentives to offset initial migration costs. The terms are negotiated case by case with AWS and your partner, so treat it as a lever to pull, not a number to plug in. For the full picture of where the money lands, the cost-layer table above is your map.

How does AWS Transform compare to Azure Migrate, Google Cloud Migration Center, and Broadcom VCF?

AWS Transform is the strongest option for automated, AWS-targeted modernization of legacy VMware, mainframe, and .NET estates. Azure Migrate plus GitHub Copilot app modernization wins on Windows and .NET affinity, Google Cloud Migration Center is the equivalent play for GCP, staying on Broadcom's VMware Cloud Foundation wins if you do not want to move at all, and partner-led manual migration still wins on estates too non-standard to automate.

AWS Transform vs. Broadcom VMware Cloud Foundation. This is modernize-away-from-the-hypervisor versus keep-it. The push factor is well documented: after the acquisition, Broadcom moved VMware to subscription-only, per-core licensing with a 16-core-per-CPU minimum, which raised the floor price for smaller clusters sharply and sent a lot of teams looking for the exit. If VMware renewal sticker shock is your trigger, AWS Transform is built to answer it.

AWS Transform vs. Azure Migrate plus GitHub Copilot app modernization. Comparable automation ambition, mirror-image lock-in. Azure Migrate tooling is "available at no additional charge", the same monetize-the-destination model as AWS. GitHub Copilot app modernization for .NET and Java is a feature of a paid Copilot subscription rather than a standalone product, consuming your plan's premium-request allowance. If your estate is Windows and .NET heavy and you are already a Microsoft shop, this is the natural mirror of the AWS play, pointed at Azure instead.

AWS Transform vs. Google Cloud Migration Center and Migrate to Virtual Machines. The third hyperscaler option, same commercial pattern. Migration Center runs assessments and cost estimates "at no cost," and Migrate to Virtual Machines is "provided at no charge for migrations into Google Cloud," with charges only for the target resources. Included for completeness, and the right starting point if GCP is your destination.

AWS Transform vs. manual or SI-led migration. Speed and consistency versus control and auditability. Agents are excellent on estates that fit a pattern and weak on the ones that do not. If your environment is full of undocumented custom integrations and one-off network topologies, a partner-led manual move still handles the weird cases better than any agent does today.

Where does Qovery fit here, and where does it not? Qovery is not a mainframe or VMware migration tool, and it has no equivalent to COBOL decomposition. I will say the unflattering thing directly: for a COBOL estate there is no Qovery alternative to AWS Transform, and pretending otherwise would waste your time. Qovery is the platform layer underneath containerized apps once they land, running on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster. It solves the day-2 problem AWS Transform does not touch, which is the next section.

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

Use AWS Transform if you have a large VMware estate, a mainframe, or a sizeable .NET Framework portfolio, and you have already committed to AWS as the destination. Skip it if your workloads are already containerized, if you have a multi-cloud or sovereignty mandate, or if your real bottleneck is shipping speed rather than legacy infrastructure.

Good-fit profiles, with thresholds you can test against:

• A VMware estate above roughly 100 VMs, where manual discovery and wave planning would take a team weeks, and where the Broadcom licensing changes have made staying put expensive.
• A COBOL mainframe whose in-house expertise is retiring. There are still more than 800 billion lines of COBOL in daily production use per the Micro Focus/Vanson Bourne survey, and the pool of people who can read it keeps shrinking. Automated decomposition and documentation is genuinely valuable here.
• A large Windows .NET Framework portfolio, where moving to cross-platform .NET on Linux cuts licensing and AWS quotes up to 40% savings.
• An existing AWS EDP or Savings Plan commitment to burn down, which turns the target-state run cost into spend you had already committed anyway.

Poor-fit profiles: teams already on containers or Kubernetes, a contractual or regulatory multi-cloud requirement, small estates where a partner-led manual move costs less than the process overhead, and teams whose pain is deployment velocity rather than legacy hosting. If you already ship containers, AWS Transform has nothing to convert.

A five-question checklist you can run in five minutes. If most answers are yes, AWS Transform is worth a serious look:

1. Do you have legacy VMware, mainframe, or .NET Framework workloads that are not yet containerized?
2. Have you already committed to AWS as the destination cloud?
3. Is manual discovery and dependency mapping a real bottleneck for your team?
4. Are you facing VMware renewal costs or mainframe skills attrition that force a decision now?
5. Do you have an AWS EDP or Savings Plan commitment you need to put to work?

One constraint pushes hard against the AWS-only answer: sovereignty. European teams facing EU data-residency and sovereignty pressure increasingly want the option of Scaleway or on-prem Kubernetes rather than committing everything to a single US hyperscaler. If that is you, a one-way AWS modernization is a strategic bet you may not want to make. And one practical note for later: with a bring-your-own-cloud platform like Qovery, the cloud bill and any AWS Savings Plans or EDP discounts stay in your own account, which matters when a commitment funded the migration in the first place.

What do you still have to build after an AWS Transform migration?

After cutover you own a pile of workloads on AWS and none of the developer workflow around them: pipelines, environments, access control, cluster upgrades, and non-production spend control. This day-2 platform layer is the second project most teams forget to budget, and unlike the migration it is recurring cost forever.

The day-2 checklist, each item real work in its own right:

• Deployment pipelines to get code from a merge to production without a human running commands.
• Ephemeral preview environments per pull request, so reviewers see the change running instead of imagining it.
• Auto-stop for non-production, so dev and staging are not billing you overnight and on weekends.
• Per-environment RBAC, so who can touch production is defined and enforced, not tribal knowledge.
• Managed Kubernetes cluster upgrades, because EKS versions age out and someone has to keep them current.
• Managed databases, observability, and cost attribution, the plumbing that makes the platform usable and accountable.

Build versus buy comes down to headcount. A homegrown internal developer platform is a standing team, not a one-off, and the trend is unmistakable: Gartner projects that by 2026, 80% of large software engineering organizations will have platform engineering teams, up from 45% in 2022. That is a lot of salaries. The visible AWS baseline underneath it is simple to price: EKS charges $0.10 per cluster per hour for the control plane, before a single workload runs, and $0.60 per hour once a version hits extended support.

The auto-stop point is not cosmetic. Flexera's 2026 State of the Cloud Report puts wasted cloud spend at 29%, and non-production environments running around the clock are a big slice of that. Turning them off when nobody is working is one of the cleanest savings levers there is.

This is the layer Qovery covers, inside your own cloud account: git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. And because Qovery is Kubernetes-native and runs on AWS, GCP, Azure, Scaleway, or your own cluster, a later change of destination does not invalidate the modernization work. Flexera's 2026 data shows 73% of organizations already run hybrid cloud, so pinning your day-2 layer to one provider is a bet against where most of the industry is heading.

I have had this conversation with a lot of CTOs, and the pattern repeats: the migration succeeds on paper, the workloads land on AWS, every dashboard is green, and six months later developers are shipping slower than before because nobody built the workflow around the new infrastructure. The migration was the visible project. The developer experience was the one that actually decided whether the whole thing was worth it.

What is AWS Transform and how does it work?

AWS Transform is an agentic AI service from AWS that automates discovery, planning, and code or configuration conversion for VMware, mainframe, and .NET workloads moving to AWS. It runs in the browser as a set of specialized AI agents that produce inventories, dependency graphs, wave plans, converted network configs, decomposed COBOL, and refactored .NET, with humans approving each step at defined gates. It does the analysis and conversion; it does not host or run your applications afterward.

How much does AWS Transform cost in 2026?

As of 21 September 2026, the AWS Transform pricing page lists no charge for migrating and modernizing Windows, VMware, and mainframe systems, and prices custom transformations and continuous modernization at $0.035 per agent minute, with the managed .NET transformation including up to 50,000 agent minutes per month at no cost. The service fee is the smallest part of the bill. The real spend is target-state EC2/EBS/RDS, Windows and SQL Server licensing, the parallel-run overlap, and engineering validation time.

Is AWS Transform free to use?

For the three core workload families, VMware, mainframe, and Windows, AWS charges no separate service fee, the same model as AWS Transform MGN and Migration Hub. It is not free overall: custom and continuous-modernization features are metered at $0.035 per agent minute, and every migration provisions AWS resources you then pay for every month. Read "no service charge" as "you pay for the destination," not "no cost."

What workloads, languages, and source platforms does AWS Transform support?

AWS Transform supports VMware estates (discovery, dependency mapping, network conversion, EC2 optimization), mainframe applications (z/OS COBOL decomposition and refactoring toward Java), and .NET Framework applications ported to cross-platform .NET on Linux. AWS has extended the product toward Windows and SQL Server modernization, database transformations, and AI-workload migration, with some capabilities in preview. Check the current supported source versions and dialects in the AWS Transform documentation before scoping, since the list changes.

What is the difference between AWS Transform and AWS Application Migration Service (MGN)?

AWS Transform does analysis and conversion: it decides what moves, in what order, and rewrites code and config. AWS Application Migration Service, now branded AWS Transform MGN, does the mechanical lift-and-shift: block-level replication of source servers and cutover to EC2. You use Transform to plan and modernize, MGN to actually replicate the bits, and Migration Hub to track the portfolio. MGN is free for 2,160 hours (90 days) per source server, then charges per hour.

Can AWS Transform migrate workloads to Azure, Google Cloud, Scaleway, or an on-prem Kubernetes cluster?

No. AWS Transform only targets AWS, by design. If you need Azure, its closest equivalent is Azure Migrate plus GitHub Copilot app modernization; for Google Cloud it is Migration Center and Migrate to Virtual Machines. For Scaleway or an on-prem Kubernetes cluster there is no equivalent hyperscaler tool, and you would run a partner-led or agent-assisted migration into that target. To keep the destination open after modernization, put a cloud-agnostic platform layer like Qovery on top so the containerized workloads can run on AWS, GCP, Azure, Scaleway, or your own cluster without being redone.

Do I still need an internal developer platform after using AWS Transform?

Yes. AWS Transform hands you migrated workloads and stops; it delivers no CI/CD, no preview environments, no per-environment RBAC, no managed cluster upgrades, and no developer self-service. Someone has to build and operate that day-2 platform, and it is recurring cost, not a one-time project. You either staff a platform team to build it, or buy a platform like Qovery that provides git-push deploys, per-PR preview environments, non-production auto-stop, cluster upgrades, RBAC, and managed databases inside your own cloud account.

The lesson I keep coming back to: a migration that lands your workloads on AWS but leaves your developers slower than before was not really a success, it was a lateral move with a big invoice. AWS Transform is a genuinely good tool for the legacy lift, COBOL decomposition and VMware network conversion are real problems it solves, and I would recommend it for the right estate. Just budget the day after cutover with the same seriousness you budget the migration, and keep your options open on where the modernized apps ultimately run.