ADR: AWS Transform & AI Agents vs Traditional Modernization Factory

Large-scale modernization programs fail with predictable frequency for well-documented reasons: silently growing scope, regressions discovered too late, loss of tacit knowledge from original systems, and team fatigue on multi-year projects. The traditional factory — dedicated engineering teams manually rewriting or refactoring code — offers granular control and clear ownership, but scales poorly: cost grows linearly with code volume, and quality is heavily dependent on team seniority and consistency.

AWS Transform represents a different bet. The service orchestrates AI agents specialized by domain: one agent for upgrading .NET Framework to .NET 8, another for COBOL analysis and conversion, another for VMware VM migration planning to EC2, and a general-purpose agent for custom code. Each agent operates in a pipeline that includes static analysis, transformed code generation, test generation, and production of traceable change reports. The model does not eliminate the engineer — it shifts work from writing transformations to reviewing and validating transformations.

The central force that makes this decision non-trivial is risk asymmetry. In critical financial or industrial systems, an undetected regression in AI-transformed code can have consequences that far outweigh any cost savings. The architecture team needs to answer honestly: does the AI agent produce code that passes existing tests or code that is genuinely correct? These are different questions, and the answer depends directly on the quality of test coverage in the legacy portfolio — which, in most real cases, is low.

A frequently underestimated aspect in discussions about AI-assisted modernization is what I call the diffuse ownership problem. When a senior engineer rewrites a COBOL module in Java or C#, they carry the intellectual responsibility for that code. They understand the decisions, can explain them in a security review, and can be held accountable. When an AI agent generates the equivalent, who is the owner? The team that ran Transform? The architect who approved the report? AWS?

This question is not philosophical — it has practical consequences in SOX audits, penetration reviews, and production incidents. A responsible modernization program needs to explicitly define that AI-generated code is owned by and is the responsibility of the engineering team that reviewed and approved it. This requires that the review process be genuine — not a rubber-stamp of automatically generated 500-page reports.

AWS Transform produces detailed transformation reports and traceable code diffs. This is a real governance asset: every change has provenance, every transformation decision is documented. The operational challenge is building a review process that is proportional to the risk of each transformed module. Financial calculation modules need deep human review; logging utilities can be approved with superficial review and automated tests. This risk triage is architecture work, not AI work.

AWS Transform operates by analyzing source code. In financial and industrial systems, that code frequently contains — or references — secrets, hardcoded connection strings, proprietary business logic, and in pathological cases, production data embedded in test scripts. Before running any modernization agent, the program needs a code sanitization phase that identifies and removes or replaces these elements.

AWS Transform's security model uses per-account and per-execution isolation — customer code is not used to train models, and processing occurs within the customer's AWS perimeter. This is materially different from sending code to a public LLM API without controls. Even so, the security team needs to review: what data is transmitted during analysis? What IAM permissions are required? Transform needs access to code repositories — that access should be temporary, minimally scoped, and audited via CloudTrail.

A pattern I recommend is running Transform in an isolated AWS account (a 'modernization sandbox') with controlled connectivity to the code repository, with no access to production environments. The generated artifacts — transformed code, reports, migration plans — are exported for review in a separate CI/CD pipeline before any merge. This isolation is not paranoia: it is the same least-privilege principle we apply to any CI/CD pipeline that touches production code.