AWS Transform is an AWS service designed to help companies modernize and migrate complex enterprise workloads using an “agentic” AI experience. It focuses on transforming infrastructure, applications, and code—especially things like .NET applications, mainframe workloads, and VMware estates—by orchestrating a series of AI‑driven tasks rather than leaving you to work through everything together manually. AWS first introduced Transform in 2024 and has continued to expand its capabilities through 2025 as part of its broader migration and modernization portfolio.
AWS Transform acts as your guided “brain” and orchestrator across the entire migration and modernization journey, helping you analyze VMware workloads, plan waves, and coordinate the underlying AWS migration services end-to-end. As of late 2025, it offers four main types of agents: VMware migrations, full-stack Windows modernization, mainframe modernization, and custom transformations that handle code, APIs, and framework upgrades.
AWS Transform evolved from the Amazon Q Developer “transformations” capability, which originally focused on applying AI to refactor and modernize individual codebases inside the IDE; that feature set grew far beyond a developer-side helper and warranted its own service, which is how AWS Transform came to life as a dedicated, agentic AI platform for large-scale modernization.
AWS Transform offers workspaces, which are web applications that users can access outside of the AWS Console. This enables teams to collaborate on migration and modernization projects through a unified web experience, organizing resources, progress, and permissions without requiring everyone to work directly inside the AWS Console.
Since launch, early adopters have tried Transform in real migration programs and shared strong, often enthusiastic feedback, particularly around its ability to analyze legacy workloads quickly, recommend sensible target architectures, and reduce the manual effort in planning and executing complex modernization waves. That real‑world feedback from my peers was exactly why I was so interested in attending the re:Invent hands‑on session dedicated to this service and trying it out myself.
AWS has been helping customers move to the cloud for a long time, but there is no single “standard” sequence that fits every workload. The steps you take depend heavily on which migration strategy you choose. A team doing a fast lift‑and‑shift will follow a different order than a team choosing to deeply refactor first and migrate later. That is exactly what the 7 Rs framework—Rehost (lift and shift), Replatform (lift, tinker, and shift), Refactor (re-architect), Repurchase (drop and shop), Retire, Retain, and Relocate—is meant to capture: different paths, all valid, chosen based on business goals, constraints, and the current state of each application. Even though there is no single canonical sequence as every migration project differs, the general flow—“discovery, assessment, right-sizing, planning, move, modernization”—is still very common in practice.
When you look at the broader landscape of AWS migration services, Transform sits above them as an orchestration and intelligence layer rather than “just another migration tool.” Services like Application Migration Service (MGN), Database Migration Service (DMS), Application Discovery Service, and Migration Hub still do the heavy lifting for replication, cutover, and tracking, while AWS Transform analyzes your workloads, proposes target architectures and migration waves, and then coordinates those underlying services to execute the plan.
What makes AWS Transform interesting is that it doesn’t throw away any of this hard-won experience. Instead, it leans heavily on the same “old, good” AWS migration services you already know and then adds an AI layer on top to make the whole journey faster, more guided, and less error‑prone. The result feels less like a brand-new product and more like the next logical step in how AWS expects large, complex migrations to be run.
Under the hood, AWS Transform still relies on the classic migration building blocks. You are still discovering servers and applications, mapping dependencies, designing landing zones, and using proven migration engines to move workloads from on‑premises data centers or other clouds into AWS. What changes is how much of that work can now be assisted, shaped, or even partially automated by AI. Instead of poring over server inventories, dependency maps, and configuration files by hand, you can lean on Transform to suggest migration waves (which is already a big piece of work!), identify low‑hanging fruit for rehost vs. replatform vs. refactor, and surface risks based on patterns AWS has seen across thousands of customer journeys. It is the same tooling stack, but with more intelligence and context layered on top.
One of the real strengths of AWS Transform is the variety of sources and targets it can help you reason about. On the source side, you might be coming from classic VMware workloads, bare‑metal data centers, Hyper‑V, or even other public clouds where you’re running Windows and Linux workloads, databases, and monolithic line-of-business applications.
AWS Transform surfaces migration strategy recommendations, readiness signals, complexity groupings, and modernization opportunities. Migration strategy recommendations focus on the “how” of moving each workload—whether it should be rehosted, replatformed, refactored, or even retired—based on technical characteristics and dependencies discovered during assessment. Readiness signals highlight how prepared a given application or environment is to move, calling out risks such as OS incompatibility, brittle dependencies, or configuration drift that may need remediation before migration. Complexity categorization groups applications by expected migration difficulty while taking into consideration architecture, coupling, data flows, and technical debt so teams can sequence waves intelligently, de‑risk early phases, and avoid overloading delivery teams. Modernization opportunity indicators then point to where a workload could go beyond lift‑and‑shift—such as adopting managed databases, containers, or serverless—to reduce heavy lifting while still leaving the detailed target design in the architects’ hands.
Networking is another area where AWS Transform seems to add a lot of value. Instead of expecting you to hand‑craft VPCs, subnets, and routing from scratch, Transform helps you design the networking for your target architecture based on its insights and generates guidance and example configurations to be used for deployment. In practice, that means you can take existing on‑prem or VMware network topologies, have Transform convert them into AWS‑native designs, and then use these recommendations in the form of CloudFormation templates (after reviewing them thoroughly) to produce safe and consistent networking configurations across accounts and regions.
Because AWS Transform is designed around AWS best practices, it works best once a few basics are in place. You need to have an AWS landing zone already and at least a set of accounts with core security baselines defined, and you’ve established secure connectivity from your source environments into AWS (for example, VPN or Direct Connect). This requirement is primarily about allowing Transform and its connectors or agents (Application Discovery, Application Migration services agents, etc) to communicate safely with your source systems and target AWS accounts, not about having every detail of your final application network designed up front.
The specific data collectors and agents you use depend on the scenario and the phase you are in. Early on, Transform relies on discovery data (for example, from its discovery tooling or connectors) to build a picture of CPU, memory, I/O, and network flows so it can understand utilization patterns and application communication. The AI agents sit on top of your discovery data, code, and environment metadata to propose target architectures, waves, and refactoring options.
Closer to cutover, AWS Transform shifts from planning into execution by coordinating the deployment of AWS Application Migration Service (MGN) replication agents to your source servers. If you choose the automated path, Transform uses the MGN connector and, after some minor configuration, instructs it to push the AWS Replication Agent out to all servers in the wave, surfaces any deployment errors directly in the job plan, and, once issues are resolved, lets you track replication progress for that wave from the same view. If you prefer more direct control, you can deploy the replication agents yourself and simply let Transform consume the results.
As soon as you start talking about AI‑assisted migrations, another natural question comes up: how does AWS Transform relate to Amazon Q Developer, and when would you use one versus the other? Both are part of AWS’s growing family of AI‑powered modernization tools, but they operate at different layers of the stack and are designed to work together rather than compete. Transform focuses on orchestrating migrations and modernization at the portfolio level, while Amazon Q Developer operates closer to the code and developer workflow, providing powerful AI-based assistance for refactoring, upgrading, and transforming individual applications. Amazon Q Developer enables teams to offload major code transformation tasks with AI agents, including .NET porting from Windows to Linux, Java upgrades, automated dependency mapping, selective transformation, and cross-language modernization, all accessible from IDEs or the CLI. Both of these services help teams safely modernize with less manual work and continuous feedback, bridging large-scale migration orchestration (AWS Transform) with precise and repeatable code-level transformations.
Depending on your use case, you might also see other AI features inside specific services. There is also a Titanium Agent, which is expected to be generally available later in 2026 to help new AWS customers establish solid landing zones from the start.
All of this makes AWS Transform an appealing option when you are facing a complex, multi‑wave migration and want both the comfort of familiar AWS services underneath and the acceleration of AI‑assisted planning on top. You still bring your architecture judgment, your regulatory and business context, and your understanding of what “good” looks like for your organization. What Transform changes is the amount of manual sifting and stitching you need to do. It lets you spend more time on the important trade‑offs—what to modernize, what to rehost, which dependencies really matter—and less time wrestling spreadsheets, ad‑hoc diagrams, and scattered tooling.
If your organization needs help figuring out complex migrations to AWS, contact us, and we will be happy to assist.