AWS Transform at 1 Year: Agentic Legacy Modernization in Production

AWS Transform is not a magic modernization button. It is an agentic orchestration platform that coordinates static code analysis, transformation generation via language models (primarily through Amazon Bedrock), automated test execution, and a feedback loop for iterative refinement. The internal architecture resembles a Step Functions workflow with specialized agents: an analysis agent that builds a dependency graph of the source code, a transformation agent that generates target code, and a validation agent that runs test suites and interprets failures.

The primary use case at launch was Java 8/11 to Java 17/21 migration, with Maven and Gradle support. That is deliberately narrow — and that narrowness is an engineering virtue, not a marketing limitation. Systems with well-defined scope, known toolchain, and reasonable test coverage are exactly where agentic automation delivers real value. The problem starts when organizations try to extrapolate this to more complex scenarios: COBOL to Java, PL/SQL to Aurora, or monoliths with circular dependencies and zero tests.

The custom transformations support added at the one-year mark changes the game in an interesting way: it is now possible to define your own transformation recipes — refactoring rules, API substitution patterns, naming policies — that the agent applies as constraints during generation. This moves Transform closer to a modernization governance framework, not just a migration tool.

The Java 8/11 to Java 17/21 migration is a structurally well-suited problem for agentic automation for three reasons: the transformation space is finite and well-documented (removed APIs, JPMS module changes, new language patterns), the build toolchain is deterministic (Maven/Gradle produces reproducible results), and validation is objective (the code either compiles or it doesn't, tests either pass or they don't). This triangle — finite space, deterministic build, objective validation — is the ideal profile for a transformation agent.

In projects with test coverage above 70% and well-managed dependencies (no proprietary third-party JARs without a modern equivalent), Transform can process the migration with minimal human intervention. The internal feedback loop — where the validation agent interprets compilation failures and passes context back to the transformation agent — is genuinely useful for common migration errors such as sun.misc.Unsafe usage, removed reflection APIs, and serialization incompatibilities.

The custom transformations support adds a governance layer that makes a real difference in financial environments: you can codify policies like 'never use java.util.Date, always replace with java.time.LocalDate' or 'every call to library X must be replaced by library Y with this specific API mapping'. This turns Transform into an architectural standards enforcement vehicle during migration — something that normally requires extensive manual review in code reviews.

The fundamental problem with Transform in mission-critical financial systems is not technical — it is epistemic. The agent has no way of knowing what the legacy code should do when the original intent has been lost. In core banking systems with 15 years of accumulated patches, there is often critical business logic — compound interest calculations, credit eligibility rules, regulatory exception handling — that is correct not because it follows a recognizable pattern, but because it was manually fixed after production incidents and never properly documented.

In this scenario, Transform can produce code that compiles, passes existing tests, and is still wrong — because the existing tests don't cover the edge cases discovered in production. This is not a failure of Transform specifically; it is a failure of the modernization process without adequate test coverage. But it is a failure that the service's marketing tends to gloss over.

Another critical limit is the handling of proprietary dependencies. In banking environments, it is common to have HSM (Hardware Security Module) SDKs, connectivity libraries for clearing systems (SWIFT, SPB, CIP), and mainframe system adapters that have no documented modern equivalent. The agent cannot transform what it doesn't know — and has no mechanism to clearly signal 'this dependency has no known mapping' in a way that integrates with a structured human review workflow. The custom transformations documentation for this case is still insufficient.

Finally, the agent's iteration model has a configurable attempt limit. In projects with high cyclomatic complexity and cross-cutting dependencies, the agent may exhaust the iteration budget without converging — and the intermediate state left behind is not easily resumable by a human engineer.

The custom transformations feature is, in my assessment, the most architecturally significant addition of the first year. The core idea is that you can define a set of transformation rules — in a format that Transform interprets as generation constraints — and the agent applies them consistently across the entire codebase. This solves a real problem that any modernization architect knows: pattern drift over a long migration.

In an 18-month migration with 50 developers, it is practically impossible to ensure that everyone applies the same refactoring decisions consistently. Custom transformations let you codify those decisions once and apply them automatically. Concrete examples of use in financial environments: systematic replacement of java.util.logging with SLF4J with MDC configured for correlation IDs (mandatory for traceability in payment systems), migration of checked exception handling patterns to unchecked with standardized wrappers, and replacement of direct cryptography API calls with AWS KMS SDK calls with specific key policy configuration.

The rule application mechanism still has limitations: there is no native support for complex conditional rules (if class implements interface X, apply transformation Y, else apply Z), and the documentation of how rules interact with the analysis agent's dependency graph is insufficient. For advanced use cases, you will need a dedicated engineer to iterate on transformation recipes — which is an operational cost that must be factored into planning.

One of the least-discussed aspects of AWS Transform is the observability of the modernization process itself. In regulated financial environments, you cannot simply run a transformation and trust the result — you need to be able to demonstrate, to internal and external auditors, exactly what decisions the agent made, why, and how they were validated.

Transform emits reasoning traces to CloudWatch Logs when properly configured. These traces include: the dependency graph built by the analysis agent, the candidate transformations considered by the generation agent, the results of each iteration of the validation loop, and the custom rules applied (or that failed to be applied). This is valuable audit material — but only if you configure adequate retention and structure the logs for querying.

My recommendation is to create a dedicated CloudWatch Log Group for Transform with 90-day retention, export to S3 with S3 Object Lock (WORM) for compliance, and create CloudWatch Insights queries to detect: iterations that exhausted the budget without converging (signal of unmanageable complexity), custom rules violated by the agent (signal of poorly defined recipe), and modules that had a test failure rate above 20% after transformation (signal of insufficient coverage).

For OpenTelemetry integration — which I use in all my platform projects — Transform does not yet emit OTLP traces natively. The current solution is to parse CloudWatch Logs and create synthetic spans via a processing Lambda. It is not elegant, but it works for creating end-to-end visibility in Datadog or Grafana alongside the rest of the CI/CD pipeline.