AWS Transform Says It’s Processed 8 Billion Lines of Legacy Code
Legacy modernization keeps landing back on the CIO’s desk. Older platforms cost more to maintain, block access to modern development practices, and depend on specialists who are getting harder to find. AWS Transform is AWS’ answer: a set of AI-assisted tools for assessing, migrating, and modernizing those systems.
I sat in on an analyst briefing with AWS in July 2026 to see how the service works and what CIOs need to verify before putting production workloads on it.
AWS Transform spans multiple modernization paths, including mainframe applications, Windows and .NET estates, SQL Server databases, VMware environments, custom code, and infrastructure migration. AWS reported more than 4.5 billion lines of code processed after the service’s first year; a later figure put the total more than 10 billion. That’s the scale AWS wants CIOs to notice, not an independently audited number.
The pitch is less manual work. Less application discovery, dependency analysis, documentation, transformation planning, and code modernization. AWS calls Transform a workbench: specialized agents and shared workspaces built around infrastructure, application, and code modernization workflows.
Pricing May Make It Easier to Start
AWS told analysts that standard migration and modernization capabilities are free, while continuous modernization and custom transformation work cost extra. Infrastructure consumption, storage, implementation services, testing, and other AWS services bill separately.
Transform can lower assessment and code-transformation software costs, but it doesn’t touch the rest of the migration bill. CIOs still need to model internal labor, partner services, target infrastructure, testing, security review, and cutover. The software fee is a small piece of the total program cost.
AWS frames continuous modernization as post-migration support that reviews code, identifies technical debt, recommends fixes, and feeds them into development workflows. It remains unclear whether this lowers long-term application maintenance cost and risk or simply moves more of the operating model onto AWS. CIOs should also challenge portability: if business needs change, can the code, assessment data, and modernization outputs move to other tools?
How AWS Transform Handles Mainframe Modernization
Transform analyzes mainframe code, extracts business rules, documents dependencies, and supports multiple modernization paths. AWS documentation identifies refactoring, replatforming, replacement, and reimagining as options, and Transform supports legacy assets including COBOL, PL/I, Job Control Language, Customer Information Control System transactions, Db2 databases, and Virtual Storage Access Method data.
In the briefing, AWS said that the analysis produces a knowledge graph intended to represent components and execution flow and that Blu Age technology supports parts of the analysis and refactoring process.
This assessment work can be useful even before an organization picks a final target architecture. Many companies depend on experienced mainframe specialists who understand business rules that may not be written down anywhere else. AWS itself names retirement and declining access to mainframe expertise as a challenge in modernization work. Start discovery while those specialists are still on staff. They can review the extracted business rules, flag missing context, explain unusual dependencies, and catch incorrect assumptions before code is changed.
Windows and Database Modernization Can Move Together
Transform also handles coordinated modernization of Microsoft SQL Server databases and their dependent .NET applications, converting them to Amazon Aurora PostgreSQL. This covers schema conversion, stored-procedure transformation, data migration, and updates to the calling application code. There’s also an offline-source option that allows customers to upload a schema definition instead of connecting Transform to a live production database.
This avoids a common failure mode: changing the database without updating every application that depends on it. Testing, data reconciliation, and rollback planning are still required, but Transform can reduce one way these projects go off track.
Require Workload-Specific Validation Before Cutover
Validation is the decision that matters most before cutover on transaction-critical systems.
AWS said at the briefing that it keeps investing in ways to compare a modernized application’s behavior against the legacy system, including System Management Facility records and synthetic test data. Its published material also covers automated test planning, test-data collection, test automation, and source-to-output traceability for mainframe work, plus structural, semantic, and functional validation for SQL Server.
These are control points, not proof. The CIO still has to demand evidence that the modernized system produces the right business results under normal transactions, edge cases, integrations, and recovery scenarios, not just the ones the test plan happened to cover. Traceability shows what changed in the code. It doesn’t show whether the production system behaves correctly.
Availability and deployment targets vary by workflow. Current SQL Server documentation covers deployment to Amazon Elastic Container Service and EC2, and other Transform paths carry different limits. Regulated organizations should confirm data residency, service certifications, GovCloud support, and where source code and transformation artifacts get processed before locking in a migration schedule. Government agencies carrying large custom legacy portfolios may still hesitate here. Even a clean answer on each point doesn’t guarantee the risk tolerance needed to hand a modernization workload to an AI-assisted platform.
Ask How AWS Measures Agent Readiness
Transform’s continuous modernization offering includes what AWS calls agent-readiness analysis: an assessment of application codebases with recommendations meant to prepare them for more use of AI agents.
Ask AWS to explain the assessment criteria, how findings get weighted, and whether the resulting data can be exported or reused on other development platforms. AWS provides both the assessment and remediation service. Understand how portable the results are before making the assessment part of ongoing engineering governance.
Choose the Capabilities That Match the Migration Plan
AWS presents Transform as a set of specialized agents and workflows to help customers migrate, modernize, and stay modern, reachable through a web console, command-line tools, development environments, and Model Context Protocol integration. That structure supports a phased rollout instead of one big-bang program. Start with discovery and documentation, pilot a database-conversion workflow on one system, or run a targeted custom transformation before committing the rest of the portfolio.
The right path depends on the condition of the system. Some applications suit rehosting or direct refactoring. Others need a rebuild because the existing architecture no longer fits the business. Make that decision before large-scale code changes start, not after.
Our Take
AWS Transform gives CIOs a structured way to attack legacy estates that have resisted documentation, migration, and modernization for years. It helps them stay ahead, modernize their IT estate, and remediate technical debt at scale by migrating infrastructure and modernizing applications. CIOs also have to consider risk mitigation: using discovery to extract business rules and map dependencies before specialists in legacy technologies retire and leave the workforce, so those who remain can still verify the output.
The central risk doesn’t go away. The target system still has to reproduce the required business behavior, with data intact, under failure conditions. AWS describes testing, traceability, and validation capabilities; CIOs should test those claims against their own workload rather than take functional equivalence on faith. Accountability for that proof doesn’t move to AWS just because the transformation work does. QA teams need to build fluency in how these agents translate and modernize code, not just in the outputs, so they can catch failures a legacy-only test plan wouldn’t anticipate.
Start the assessment before institutional knowledge leaves the building. Use experienced legacy specialists to verify the extracted rules and dependencies. Modernize in controlled phases. Require an independent acceptance gate before moving regulated data or production transactions.
AWS Transform doesn’t make legacy migration automatic. It cuts some of the manual work of understanding the old system and mapping a path forward. Final proof that the new system is production-ready still lands on the CIO’s desk.