Does AWS Transform Give You a Developer Platform, or Just Workloads Running on AWS?

AWS Transform gets your workloads onto AWS. It does not hand you a developer platform, and AWS never says it does. Everything below is about the gap between those two outcomes and how to close it.

Key points:

• No, AWS Transform is not an internal developer platform. AWS documents it as an agentic AI service that migrates and modernizes VMware and other virtualized servers, mainframe (IBM z/OS and Fujitsu GS21), and .NET workloads through discovery, wave planning, code and configuration transformation, and cutover. Its deliverable is running workloads on AWS plus migration artifacts.
• On day two you own the estate. Accounts, VPCs, IAM and SSO, the Amazon EKS, Amazon ECS, or EC2 runtime, CI/CD, observability, backups, patching, and Kubernetes upgrades. Developers still file tickets or write Terraform to get an environment, because nothing in AWS Transform creates golden paths, self-service, or guardrails.
• Closing the gap is a separate project with three paths: AWS-native primitives (Service Catalog, CDK, Control Tower customizations), a DIY open-source stack (Backstage plus Terraform or OpenTofu, Crossplane, Argo CD, Kyverno), or a commercial internal developer platform (Qovery, Humanitec, Port, Northflank). AWS Proton reached end of support on October 7, 2026, so it is no longer an option.
• Backstage is a developer portal framework, not a finished platform. Spotify created it and donated it to the CNCF, where it is still an incubating project. It ships a software catalog and a plugin system and still needs an owning team. Terraform covers provisioning, not runtime or environment lifecycle.
• They are sequential, not competing. AWS Transform moves the workload onto AWS; an internal developer platform makes that workload usable by developers every day after. Qovery fits when you want Kubernetes-based self-service inside your own AWS account - or GCP, Azure, Scaleway, or an existing cluster - without staffing a platform team to build a control plane.

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

AWS Transform is an agentic AI service that automates the migration and modernization of VMware and other server estates, mainframe applications, and .NET applications onto AWS. It delivers migrated running workloads plus migration artifacts: discovery data, dependency maps, wave plans, landing zone and network configuration, transformed code, and generated documentation.

AWS's own wording is precise, so I will use it. The AWS Transform User Guide describes "a service that helps you accelerate and simplify the transformation of infrastructure, applications, and code with an agentic AI experience." Work happens in a web experience organized around workspaces, connectors that reach your source code, servers, and networks, and long-running jobs that AWS describes as lasting "weeks/months+". Humans stay in the loop by design: only Administrators and Approvers can approve critical actions such as "merging to main, performing graph decomposition, or deploying code to production environments."

Per workload class, the documented outputs look like this:

• VMware, Hyper-V, and other server platforms: discovery, migration planning into prioritized waves, landing zone creation, network migration into "production-ready AWS VPC architecture," server rehost to EC2, and source code containerization onto Amazon ECS or Amazon EKS.
• Mainframe: modernization and migration of IBM z/OS and Fujitsu GS21 applications, including code analysis, decomposition, refactoring, and documentation.
• .NET: porting .NET Framework applications to "Linux-ready cross-platform .NET."

At its stated job, AWS Transform is good. AWS claims it modernizes "Windows, mainframe, and VMware applications up to 5x faster" (AWS Transform), and its June 3, 2026 write-up reports migration planning "in an hour" for estates that take architects six to eight weeks, and containerization dropping from "five to ten days per application" to "one to two hours" (AWS Migration and Modernization Blog). Those are AWS's numbers with AWS's qualifiers. My critique is about scope, not quality.

The service is young and moving fast. AWS previewed it at re:Invent 2024 as Amazon Q Developer transformation capabilities and announced general availability on May 15, 2025 (AWS News Blog). Check capability claims against the current docs, not launch-day posts.

AWS Transform's output is migrated workloads and migration artifacts, full stop.

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

No. AWS Transform migrates and modernizes workloads onto AWS and stops at cutover, and a developer platform is a separate layer it does not build. Self-service environments, golden paths, guardrails, a service catalog, and day-two operations all remain your job, and AWS does not claim otherwise.

The CNCF Platforms White Paper defines a platform as "an integrated collection of capabilities defined and presented according to the needs of the platform's users," with attributes including platform as a product, self-service, reduced cognitive load, and secure by default (CNCF TAG App Delivery). Put that list next to AWS Transform's documented outputs and the overlap is zero. AWS Transform's users are migration teams. A platform's users are application developers, every day, for years.

What AWS Transform does not produce:

• On-demand environment creation for a developer without a ticket
• Preview environments per pull request
• Per-environment RBAC that maps to teams instead of IAM policies
• Cost guardrails and auto-stop for non-production
• A software catalog of services, owners, and dependencies
• A deployment abstraction usable without AWS expertise

The honest nuance: a finished migration puts you in a far better position to build a platform. You have consistent accounts, a real inventory, IaC artifacts, and dependency maps that most teams never get. The build itself is still entirely ahead of you.

The failure mode is predictable. Hand raw AWS accounts to application teams right after cutover and within two quarters you have ticket queues, snowflake environments, and cost drift. Flexera's 2026 State of the Cloud report shows wasted cloud spend rising to 29%, "for the first time in five years," with 85% of organizations naming cloud spend management a top challenge (Flexera).

What do you actually own on day two after an AWS Transform migration?

On day two you own a landing zone, a spread of accounts and VPCs, migrated workloads, infrastructure-as-code of uneven quality, and a developer workflow that in most organizations still runs on tickets. Every one of those becomes your team's permanent operational responsibility the morning after cutover.

AWS Transform can create the landing zone and translate the network, which is real help. Creating them is a one-time event; operating them is forever. AWS Organizations structure, transit routing, IAM Identity Center permission sets, the Amazon EKS or Amazon ECS runtime, CI/CD, observability, backups, OS patching, tagging, and cost allocation all land on your team.

Then comes the ticket problem. A developer needs a database, a staging environment, a DNS record, or an IAM role, and waits for someone who understands AWS to provide it. DORA's research found that letting developers complete work without help from an enabling team "resulted in a 5% improvement in productivity at both the team and individual levels" (DORA). That is the gain a ticket queue gives away.

Cost drift follows lift-and-shift almost by default: staging environments running nights and weekends, oversized instances sized for on-premises peaks, orphaned EBS volumes and load balancers from failed cutover rehearsals. Flexera's 29% waste figure is the baseline you start from, before anyone touches a rightsizing recommendation.

The upgrade burden is the line item almost nobody writes down. Amazon EKS gives each Kubernetes minor version 14 months of standard support, then 12 months of extended support, and auto-upgrades the control plane after that (Amazon EKS docs). Extended support is enabled by default and costs $0.60 per cluster per hour instead of $0.10 (Amazon EKS pricing). That is about $438 per cluster per month instead of $73, an extra $365 per cluster per month or $4,380 per year. With ten clusters that slipped an upgrade, you pay $43,800 a year for not upgrading. Managed node groups and add-ons do not upgrade with the control plane, so someone still does that work, roughly every four months as upstream ships new minors.

Staffing is the last surprise. DORA's 2025 research reports 90% of organizations using an internal developer platform and 76% with dedicated platform teams (DORA), and Gartner predicted 80% of large software engineering organizations would establish platform engineering teams by 2026 (Gartner). The migration budget rarely includes that team.

A Monday-after checklist to run against your own estate:

• Count clusters on Amazon EKS extended support today: aws eks describe-cluster-versions plus your cluster list.
• Measure median time from "I need an environment" to a working environment.
• List non-production environments running outside working hours.
• Name the owner, by person, of every row in the table above.

How do you close the gap between a finished migration and real developer self-service?

There are three realistic paths after an AWS Transform migration: build on AWS-native primitives, assemble an open-source stack around Backstage and Terraform, or adopt a commercial internal developer platform that runs inside your own cloud account. The choice is mostly a function of how many engineers you have and whether you can permanently fund a platform team.

Path 1, AWS native. Service Catalog for approved products, a shared CDK construct library, and Control Tower customizations for account vending. You get no new vendor, deep IAM integration, and one bill. You also become the platform product team, and nothing ships until you build it. Two AWS options that older articles still recommend are gone: AWS Proton reached end of support on October 7, 2026, after which "you will no longer be able to access the AWS Proton console or AWS Proton resources" (AWS Proton docs), and Amazon CodeCatalyst "is no longer open to new customers" (CodeCatalyst docs).

Path 2, DIY open source. Backstage as the portal, Terraform or OpenTofu plus Crossplane for provisioning, Argo CD for delivery, Kyverno or OPA Gatekeeper for policy. You get full control, portability, and no license fee. You pay for it in integration work that never finishes, because Backstage is a framework you extend with plugins you write and maintain.

Path 3, commercial IDP. Qovery, Humanitec, Port, or Northflank. You get golden paths in days, opinionated defaults, and no control plane to run. You pay a license, accept some opinionation, and integrate with the Terraform you already have.

My rules, stated plainly:

• Under roughly 50 engineers with no dedicated platform team, a commercial IDP almost always wins.
• A funded platform team of four or more with genuinely unusual requirements can justify DIY.
• A hard "no third-party control plane" policy points to AWS native.

On timelines, I will be directional rather than invent numbers: weeks for a commercial IDP pilot, quarters for a credible Backstage build, and ongoing maintenance in both cases.

How do AWS, Backstage, HashiCorp, IBM, Humanitec, Port, Northflank, and Qovery compare for the post-migration platform layer?

Each option solves a different slice of the problem: AWS gives primitives you assemble, Backstage gives a portal shell you must fill, HashiCorp gives provisioning and secrets, IBM gives consulting-led modernization on Red Hat OpenShift, and Qovery gives a running self-service platform deployed inside your own cloud account. None of them replaces AWS Transform, because none of them performs the migration.

The most common misreading in this space concerns Backstage. Spotify created it, the CNCF accepted it on September 8, 2020, and it remains an incubating project with more than 7,500 contributors (CNCF). That community is real strength. It is still a developer portal framework: a catalog, templates, and a plugin system that someone on your team must assemble into a platform.

HashiCorp covers provisioning with Terraform, secrets with Vault, and golden-path templates with HCP Waypoint. It leaves the runtime, environment lifecycle, and the developer portal to you. IBM pairs consulting-led modernization with Cloud Pak and Red Hat OpenShift as the runtime, which suits large hybrid enterprises willing to depend on services. Humanitec orchestrates platform configuration across your existing infrastructure. Port is a portal and catalog with workflow automation on top of tools you already run. Northflank is a runtime-first PaaS that can deploy into your own cloud account.

Qovery is a control plane that deploys into your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Developers get git-push deployments, preview environments per pull request, and per-environment RBAC. The platform side gets environment auto-stop for non-production, managed cluster upgrades, and databases backed by managed cloud services. Because everything runs in your account, the cloud bill, Savings Plans, and committed-use discounts stay in your name.

AWS Transform moves the workload onto AWS; an internal developer platform makes that workload usable by developers every day after. They are sequential, not competing.

When does it make sense to run AWS Transform and an internal developer platform together?

The sequence that works: use AWS Transform for the migration mechanics, stabilize the landing zone and runtime, then put a developer platform on top before you hand AWS accounts directly to application teams. Building the platform first usually backfires, because the runtime target keeps moving while the migration is in flight.

1. Migrate with AWS Transform, wave by wave.
2. Stabilize the landing zone, network, and Amazon EKS or Amazon ECS runtime.
3. Define golden paths for your top two or three workload shapes, such as a containerized API, a worker, and a web frontend.
4. Onboard one pilot team and measure.
5. Expand by workload shape, not by org chart.

Platform-before-migration fails for concrete reasons: the runtime is undecided, network topology changes wave to wave, and you build abstractions against infrastructure that will not exist in six months.

Segment the estate honestly. Mainframe applications and many rehosted VMware VMs that AWS Transform moves will never sit on a container-based IDP, and forcing them there is a waste of everyone's time. The platform layer applies to the containerizable and greenfield slice, which is usually where developer velocity matters most.

Commit to metrics before you start. DORA now tracks five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate (DORA). Add two of your own: the share of infrastructure requests served by self-service instead of tickets, and non-production spend as a share of total.

Qovery slots in after step 2. Point it at the Amazon EKS cluster the migration left you, or let it provision a cluster in your own account, and keep Terraform for the surrounding infrastructure. In my experience, non-production auto-stop and preview environments per pull request are the two capabilities that pay for themselves first.

How do I set this up from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy into your own AWS account. The skills cover onboarding, deployment, troubleshooting, cost optimization, and preview environments, and the MCP Server operates what already exists.

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

# Or scope the install to a single repository
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Enable write access only when you want it (also enable write in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

You approve the OAuth login in your browser. The skills are qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, and qovery-terraform. Then ask: "deploy this service to my AWS account with Qovery and give me a preview environment per pull request." The AI agent quickstart and the Claude Code integration cover the rest.

FAQ

Does AWS Transform give you an internal developer platform after the migration?

No. AWS Transform migrates and modernizes VMware, mainframe, and .NET workloads onto AWS and stops at cutover, per the AWS Transform User Guide. It does not provide self-service environments, preview environments per pull request, per-environment RBAC, or non-production auto-stop. You add those with a separate internal developer platform.

What does AWS Transform actually do, and which workloads does it support?

AWS Transform is an agentic AI service that handles discovery, migration planning, landing zone creation, network migration, server rehost, and containerization onto Amazon ECS or Amazon EKS. It supports VMware, Hyper-V, and other server platforms, IBM z/OS and Fujitsu GS21 mainframes, and .NET Framework applications ported to cross-platform .NET. Humans approve critical steps such as merging to main or deploying to production.

What is the difference between AWS Transform, AWS Migration Hub, and AWS Application Migration Service?

AWS Transform runs the agentic assessment, planning, and transformation work end to end. AWS Application Migration Service (MGN) performs lift-and-shift replication of servers onto EC2. AWS Migration Hub tracked migrations across tools and has been closed to new customers since November 7, 2025, with AWS pointing new users to AWS Transform.

Is Backstage an internal developer platform or just a developer portal?

Backstage is a developer portal framework, created at Spotify and now a CNCF incubating project. It provides a software catalog, templates, and a plugin system, but it does not deploy or run workloads on its own. Turning Backstage into a full internal developer platform takes a dedicated team to build and maintain the integrations.

Do I still need a platform engineering team after an AWS Transform migration?

Someone has to own Amazon EKS upgrades, environments, CI/CD, and cost controls after an AWS Transform migration, because AWS Transform stops at cutover. Large organizations usually fund a platform team; DORA reports 76% of organizations have one. Smaller teams can use a commercial internal developer platform such as Qovery to cover that work without hiring a dedicated team.

Can Qovery run on the AWS environment AWS Transform just migrated me to, and does it also work on GCP, Azure, Scaleway, or my own Kubernetes cluster?

Yes. Qovery can connect to the Amazon EKS cluster an AWS Transform migration leaves you with, or provision a new cluster in your own AWS account. Qovery also runs on your own GCP, Azure, or Scaleway account, or on any existing Kubernetes cluster you already operate. Workloads stay in your account, so your cloud bill and Savings Plans stay in your name.