AWS has introduced Transform custom, a tool designed to automate the modernisation of legacy code at scale. Announced at re:Invent 2025, the service extends AWS Transform’s existing capabilities to handle custom programming languages, frameworks, and organisation-specific code that companies have accumulated over decades. It’s Amazon’s latest attempt to address what’s become a multibillion-rand problem for enterprises: technical debt.
The pitch is straightforward. Give Transform custom some code snippets, documentation, or wiki links, and the service creates a transformation plan. Then it executes that plan across hundreds or even thousands of applications simultaneously. AWS claims organisations can modernise code five times faster than manual efforts, which sounds compelling until you remember that manual modernisation has always been deliberately slow, expensive, and avoided.
According to AWS vice president Asa Kalavade, who presented the announcement at re:Invent, companies typically spend about 30% of their IT budgets on modernisation work. That’s not innovation. It’s maintenance dressed up as progress. The real cost isn’t just financial though. It’s the opportunity cost of having engineers fix yesterday’s problems instead of building tomorrow’s solutions.
Air Canada appears to be AWS’s flagship example. The airline used Transform to modernise thousands of Lambda functions in days, achieving what AWS describes as an 80% reduction in time and cost compared to manual migration. That’s the kind of metric that gets CIOs’ attention, particularly at airlines where legacy systems can ground operations if they fail.
Full-stack Windows modernisation gets the AI treatment
Transform isn’t just targeting custom code anymore. AWS has expanded the service to handle full-stack Windows modernisation, which means organisations can now modernise their .NET applications, SQL Server databases, and user interface layers all within the same tool. The company claims this approach eliminates up to 70% of maintenance and licensing costs, which translates to significant savings for enterprises stuck paying for Windows licences they’d rather not.
Thomson Reuters has apparently been using Transform to modernise 1.5 million lines of .NET code monthly, resulting in 30% cost savings from moving off Windows to Linux. That’s a substantial commitment to migration at scale, and it suggests the technology works well enough for production environments at companies where downtime isn’t an option.
The full-stack approach matters because partial modernisation often creates more problems than it solves. Moving application code to .NET Core whilst leaving databases and UI frameworks untouched doesn’t actually reduce technical debt. It just redistributes it. Transform’s ability to coordinate changes across the entire stack should, in theory, avoid that trap.
Mainframe modernisation still requires human expertise
AWS has also introduced six new agents for mainframe modernisation, which is perhaps the most complex migration challenge enterprises face. Mainframes have been running critical business systems for decades, often with minimal documentation and code written by developers who’ve long since retired. Moving these systems to modern infrastructure typically takes years and costs millions.
Transform’s mainframe agents now handle activity analysis, blueprint creation for reimagining legacy code, and automated test planning. Testing alone traditionally consumes up to half of mainframe modernisation project timelines, so any automation that reduces that burden matters. Companies like ADP, Itaú, and BMW have apparently completed mainframe projects in months rather than years using Transform.
But Kalavade was careful to note that Transform isn’t fully autonomous. The service combines specialised AI agents with human oversight, requiring experts to validate plans and complete tasks that need contextual understanding. That’s a sensible approach given the stakes involved in mainframe migration, though it does mean organisations still need to retain or hire people with mainframe expertise.
Partners can now build custom workflows
AWS has introduced what it calls “composability” to Transform, allowing global systems integrators and partners to create their own workflows on top of the platform. Accenture, Capgemini, and Pegasystems are the first partners building custom agents, particularly for regulated industries like financial services and healthcare where compliance requirements complicate migration.
This move acknowledges that off-the-shelf modernisation tools rarely handle the edge cases and industry-specific requirements that enterprises actually face. By opening Transform to partner customisation, AWS is betting that a platform approach will prove more valuable than trying to build every possible transformation workflow itself.
QAD, a manufacturing software company, is using Transform to help customers migrate customisations when QAD upgrades its ERP platform. The company has saved over 7,500 hours on that specific use case, which suggests Transform works for vendors trying to bring customers along during platform modernisation, not just enterprises migrating their own systems.
VMware workload migration gets simpler
Transform now includes enhanced capabilities for VMware migrations, with new agents that handle discovery, planning, and network migration. That’s particularly timely given Broadcom’s acquisition of VMware and the subsequent licensing changes that have prompted many organisations to reconsider their VMware commitments.
The service maps virtual machines to appropriate AWS infrastructure, whether that’s EC2 instances, containers, or other compute options. It also translates networking configurations and security groups, which are typically the most tedious parts of infrastructure migration. AWS’s focus here seems to be on reducing the manual coordination work that makes large-scale migrations take so long.
The bet on agentic AI for infrastructure
AWS Transform represents a particular vision of how AI should work in enterprise settings. Rather than a single large language model trying to handle everything, Transform uses multiple specialised agents coordinated by an orchestrator. Each agent focuses on a specific task like code analysis, dependency mapping, or test generation.
That architecture aligns with how AWS builds most of its services: composable, specialised tools that organisations can combine to solve complex problems. Whether that approach proves more effective than monolithic AI systems remains to be seen, but it does offer more transparency about what each agent is doing and why.
Transform also demonstrates AWS’s belief that migration and modernisation represent a substantial market opportunity, not just a cost centre for enterprises. By automating tasks that have traditionally required expensive consulting engagements, AWS could capture revenue that currently goes to systems integrators whilst also accelerating cloud adoption.
What this means for South African enterprises
For South African organisations, Transform potentially addresses a familiar problem: aging infrastructure that nobody wants to touch because migration seems too risky or expensive. Banks, insurance companies, and government agencies all operate systems built decades ago that would benefit from modernisation but struggle to justify the investment. The challenge isn’t unique to legacy code either. As enterprise security requirements evolve, organisations face mounting pressure to modernise entire technology stacks simultaneously.
If Transform delivers on its promises, it could make modernisation projects more financially viable by reducing both timeline and cost. That’s particularly relevant for organisations facing pressure to adopt AI capabilities but unable to do so because their underlying infrastructure can’t support modern workloads.
The question isn’t whether Transform works in principle. AWS has enough credibility and customer validation to suggest the technology is sound. The question is whether organisations have the appetite to undertake large-scale modernisation projects even with better tools. Technical debt persists not just because it’s hard to fix, but because fixing it requires stopping other work, accepting short-term disruption, and convincing boards that paying down invisible debt matters as much as building visible features.