AWS Transform processed 4.5B lines, then moved modernization agents into Codex and Claude

AWS said on May 14, 2026 that AWS Transform agents can now be reached from Kiro, Claude Code, Cursor, and Codex. The access paths are Kiro powers, agent plugins, and the AWS Transform MCP server. One day later, AWS' first-anniversary post for Transform claimed more than 4.5 billion lines of code processed, hundreds of thousands of VM migrations, and more than 1.6 million manual hours saved over the service's first 12 months. Read together, the two announcements make AWS' direction plain: modernization agents are moving out of a standalone AWS console workflow and into the agentic IDEs and CLIs developers already use.

This is not just another AWS migration product update. devlery has recently covered AWS agent infrastructure through SageMaker's OpenAI-compatible API, AgentCore Optimization, and the AWS Nova Act Service Card. The new part here is that Transform is being pushed into the same surfaces as Codex, Claude Code, and Cursor. Agents are no longer framed only as tools for greenfield feature work. AWS is putting them next to enterprise legacy code, infrastructure migration, database conversion, and framework upgrade work.

AWS Transform was built for enterprise modernization from the start. AWS' anniversary post describes the initial use cases as VMware infrastructure migration, IBM z/OS COBOL application modernization, and .NET upgrades. At re:Invent 2025, AWS added custom transforms so organizations could handle code, language, API, and framework upgrades at a broader program level. The May 2026 developer-tool update extends that workflow from the web console into IDEs, CLIs, and MCP integrations. A developer can start a transformation in an agentic IDE, a program manager can track it in the web console, and the developer can return to the IDE to inspect results.

The reported scale is aggressive. AWS says Transform processed more than 4.5 billion lines of code in 12 months, migrated hundreds of thousands of VMs, and reduced customer manual effort by more than 1.6 million hours. The post also describes a 250,000-line mainframe application's full transformation and testing being completed in six weeks. For infrastructure teams, AWS says migration planning for thousands of servers can move from weeks to hours, with assessments finding average compute savings of 35% and licensing savings of 45%. These are not independent benchmark results. They are AWS-published customer and service metrics. Still, the decision to publish numbers at this scale shows that enterprise modernization has become a sales target for agent products.

The technical change to watch is job state. AWS' What's New post says IDE, web console, and MCP integrations operate over the same underlying job and share state. Older migration tools often split the work across a console assessment, exported files, ticketing systems, and repository changes. When Transform agents enter the IDE, a developer can start a modernization job in the codebase while an architect or program manager tracks approval and progress in the console. The unit of collaboration is not just the diff an agent produces. It is the transformation job itself.

The awslabs/agent-plugins GitHub repository reinforces the same direction. Its README says Agent Plugins for AWS support Claude Code, Codex, and Cursor, and that plugins can bundle agent skills, MCP servers, hooks, and references. The aws-transform plugin description lists .NET to .NET 8/10, mainframe COBOL to Java, VMware to EC2, SQL Server to Aurora, and language or SDK upgrades. That catalog is wider than "give the coding assistant some AWS docs." Legacy application conversion, database migration, VM migration, and language upgrades are being packaged as capabilities inside a coding assistant.

Kiro is part of the context. On April 30, 2026, AWS announced that Amazon Q Developer IDE plugins and paid subscriptions will reach end of support on April 30, 2027. New Q Developer signups stopped on May 15, 2026, and AWS said Opus 4.6 would be removed from Q Developer Pro on May 29, 2026. AWS also said the latest coding models would be available first in Kiro. The developer-tool direction is therefore not to preserve the old Q Developer plugin shape. AWS is rearranging around spec-driven Kiro, Transform agents, agent plugins, and MCP.

In this rearrangement, spec-driven development is not just positioning language. It is a control surface. AWS' Q Developer end-of-support post says Kiro uses structured specifications to plan, implement, and verify work. Specs, hooks, steering files, custom subagents, and powers are core parts of the environment. Once Transform agents enter as a Kiro power, a legacy modernization task becomes more than "edit these files." It can be represented as requirements, design decisions, a task list, and validation conditions. That difference matters for COBOL, PL/I, .NET Framework, and SQL Server migrations, where teams need audit trails and approval evidence.

AWS' mainframe path shows what kind of agent work the company is describing. Transform analyzes code, runtime behavior, business rules, and data lineage to build an execution graph. AWS says it links business rules in the original legacy code to the transformed code. PL/I support has also been added. AWS describes Transform extracting PL/I business logic into a syntax-independent specification, with Kiro then handling interactive forward engineering. The agent is not simply generating code in one step. The claimed flow is to turn legacy intent into a specification and then move that specification into cloud-native patterns.

Windows modernization has also moved beyond a plain .NET upgrade. AWS mentions ASP.NET Web Forms to Blazor UI modernization and SQL Server to Aurora PostgreSQL migration. A database modernization beta appears in the same context, covering schema, stored procedures, and application data-access code. AWS describes validation in three layers: syntax validation, semantic equivalence, and functional verification with synthetic data. For a development team, the model name is not the adoption question. The decision depends on what evidence the transformation leaves, what test corpus supports semantic equivalence, and how well synthetic data covers real edge cases.

The code-modernization catalog is even more direct. AWS lists out-of-the-box transforms for Vue.js, Scala and Glue, Spring Boot, Log4j to SLF4J, Angular to React, and Angular to Flutter. The same list includes Progress 4GL to Java, PHP replatforming, ColdFusion to React and Java, DataDog to CloudWatch Monitors, and JBoss to Spring Boot. That list looks like an enterprise backlog. Security teams see Log4j and end-of-life dependencies. Platform teams see runtime upgrades. Finance and operations teams see monitoring migration and licensing reduction. The agent is shifting from a feature-productivity tool toward a technical-debt portfolio tool.

The immediate developer change is the starting point for work. Until now, agentic coding tools have been strongest inside repository-local tasks. They become weaker once a migration program needs source inventory, target accounts, approvals, partner delivery, and cost tracking. AWS Transform binds environments, workspaces, and transformation jobs to AWS credentials and IAM roles. When a developer calls the aws-transform plugin from Codex or Claude Code, the actual transformation work can be attached to an AWS account and a job record. If that structure holds, the generated diff is no longer only an artifact from an agent conversation. It is output from an enterprise modernization job.

The risk grows at the same time. The AWS GitHub README warns that generative AI can make mistakes and that users should review generated output and cost. Its best practices call for reviewing generated code, treating plugins as accelerators rather than replacements for judgment, keeping plugins updated, applying least privilege, and scanning generated infrastructure code. Those are not boilerplate cautions when Transform agents can touch VMware migrations, mainframe modernization, database conversion, and IAM-authenticated workspaces. "The agent handled it" is not an operational answer. Teams need records of who approved the run, which role executed it, which artifacts landed in S3, and how far a failed migration can be rolled back.

The "What's new" section in the AWS Agent Plugins README is also worth reading closely. It says Agent Toolkit for AWS is live and is the successor to AWS Labs MCP servers, plugins, and skills. The listed direction includes IAM condition keys that separate agent actions from human actions, CloudWatch and CloudTrail visibility, and skills evaluated for accuracy and effectiveness. That language moves the plugin ecosystem away from hobby extensions and toward production governance. Once an agent can call AWS APIs, operations starts with separating a human API call from an agent API call.

Community reaction around this area is still centered more on Kiro and AWS developer-tool trust than on AWS Transform itself. Hacker News discussion around Kiro has questioned why Kiro is a separate IDE instead of a VS Code plugin, whether Q Developer CLI offered enough value for its price, and how long AWS will keep developer tools alive. The Q Developer end-of-support announcement can intensify those questions. AWS has drawn a boundary by offering a 12-month transition window, preserving access for existing customers during that window, and continuing first-party Q Developer surfaces such as the console and Slack or Teams integrations. Even so, teams moving to Kiro and Transform plugins have to ask how long these new surfaces are intended to last.

The competitive shape is different from a normal coding-assistant race. GitHub Copilot's app ties issues, branches, validation, and pull requests into GitHub. Claude Code emphasizes dynamic workflows and parallel subagents. OpenAI Codex spans a local CLI, cloud sessions, and ChatGPT. Cursor and the Windsurf/Cognition line focus on fast code changes and review loops inside the IDE. AWS Transform does not need to beat each of them as a general-purpose coding assistant. It can sit inside those agentic IDEs as an enterprise modernization specialist. That fits AWS' domain strength: accounts, IAM, migration history, target cloud architecture, and partner delivery workflow.

The strategy also connects to the Q Developer sunset. Q Developer IDE plugins acted as AWS assistants inside multiple IDEs. Kiro is now a separate agentic IDE, while Transform agents are being exposed to Claude Code, Codex, and Cursor as well. AWS appears to be moving from "every developer should use an AWS IDE assistant" toward "AWS modernization expertise should be callable from whichever agent surface a developer uses." If that reading is right, the durable advantage is not the chat UI. It is the transformation catalog, IAM-aware orchestration, cloud migration evidence, and partner delivery process.

Teams evaluating the feature should start with three questions. First, define a small modernization scope for the agent. A Log4j to SLF4J migration, a Node.js runtime upgrade, or one service's .NET upgrade is easier to validate and roll back than a broad program. Second, decide where Transform job artifacts live and who can access them. S3 connectors, IAM roles, workspace permissions, and source repository permissions are all audit surfaces. Third, define the automated gates that block a generated result before merge. Unit tests, integration tests, semantic-equivalence checks, synthetic-data validation, and security scans should be chosen before the agent starts changing code.

An exaggerated reading of the announcement would be "legacy modernization is now automatic." AWS' own materials are more cautious than that. The anniversary post describes architects adjusting transformation plans, DBAs reviewing and approving assessments, and human-in-the-loop interaction expanding across surfaces. The actual product direction is closer to a collaborative enterprise foundation than unattended automation. Agents connect discovery, planning, transformation, and testing, but approval and review remain in human and organizational processes.

The developer-relevant change is that agents are being aimed at old code, not only new code. AI coding tools have usually explained their value through greenfield prototypes, feature implementation, and unit test generation. AWS Transform is talking about 20-year-old payroll systems, claims systems, mainframes, .NET Framework applications, SQL Server estates, and VMware inventories. Those systems have high failure costs, and their requirements often live in code and runtime behavior rather than clean documentation. Transform's competitive question is therefore not "can it generate code well?" It is "can it trace and verify the change well enough for a regulated enterprise?"

AWS Transform agents entering IDEs is a quiet but large move in the enterprise AI agent market. If Codex or Claude Code can call AWS Transform, the agentic IDE becomes more than a general editor. It becomes an orchestration surface for vendor-specific domain agents. The 4.5 billion-line figure is AWS attaching scale language to that market. The next validation point is narrower and more practical: whether a real migration job created through the aws-transform plugin leaves cost, permission, test evidence, and rollback records in one workflow. If it does, agentic coding will be judged less by how quickly it writes new code and more by how safely it changes old systems.