I let AWS Transform
analyse a legacy Java codebase.
Here's what it found.

Most "assessment tools" scan for known CVEs, produce a PDF with a heat-map, and call it done. AWS Transform does something different. It deploys an agentic loop — reading every source file, navigating the dependency graph, generating diagrams, and writing structured documentation — then tells you exactly which named transformation to run next. Assessment feeds pipeline.

I ran it against a real app. This is what happened.

What AWS Transform is — and what custom transformations do

AWS Transform is a managed modernisation service built on Amazon Bedrock. You connect a repository, choose a transformation, and an agent handles the rest: reading code, reasoning about structure, writing artefacts, and surfacing a clear next step. No YAML configs. No custom scripts. One CLI command.

The service ships with built-in transformations for the most common modernisation patterns, and an expanding set of custom transformations you configure through the console chat interface:

Beyond built-ins, here are the available custom transformations — each addressing a specific modernisation scenario:

The patient: a Spring CRUD app with 3 high-severity EOL issues

The application is a textbook layered monolith — RESTful CRUD for user records, 8 endpoints, 7 Java source files, ~559 lines of code. Small surface area, but carrying the exact debt pattern seen across thousands of enterprise Java apps that haven't been meaningfully touched since 2020.

Creating the transformation in the console

From the AWS Transform console, I described the intent in natural language. The agent surfaced the available custom transformations, I selected AWS/comprehensive-codebase-analysis, and it confirmed the setup instantly:

The CLI command to trigger the run against the repo:

atx run \
  --transformation AWS/comprehensive-codebase-analysis \
  --repo mycontainers \
  --path /root/aws-transform-containers

The worklog — 61 agent minutes, end to end

AWS Transform maintains a full timestamped worklog for every job. Under the hood the agent fired hundreds of shell, file_read, and file_write tool calls — navigating directories, reading source files and the SQL schema, parsing pom.xml, and writing the entire documentation tree from scratch. Here's the high-level log:

Output: 33 files, 9 directories, one atomic commit

Everything landed in a single git commit — "Step 1: Create comprehensive ATXDocumentation with full codebase anal…" — 22 minutes after the job started. Browse it live at github.com/aquavis12/aws-transform-containers → src/ATXDocumentation.

All 8 technical debt findings, prioritised

The agent produced a debt matrix covering 3 high-severity EOL items, 1 medium, and 4 low-severity code quality issues — ranked correctly by upgrade impact, not just by surface severity.

Architecture and sequence diagrams written from source code

The agent didn't rely on existing documentation — there was none. It read the Java source files and generated ASCII-art architecture and sequence diagrams by reasoning about the class structure and method call chains.

System context diagram

┌────────────────────┐          ┌────────────────────────────────────┐
│  Client            │  HTTP    │  JBoss / WildFly                   │
│  (Browser / curl)  │──REST──▶ │  ┌──────────────────────────────┐  │
│                    │◀──JSON── │  │  Spring Boot 2.5.14 (WAR)    │  │
└────────────────────┘          │  │  UserController               │  │
                                │  │    └── UserService            │  │
                                │  │          └── UserRepository   │  │
                                │  └──────────────┬───────────────┘  │
                                └─────────────────┼──────────────────┘
                                                  │ JDBC
                                                  ▼
                                ┌─────────────────────────────────────┐
                                │  MySQL 8.0  ·  crud_db  ·  users    │
                                │  idx_username · idx_email            │
                                │  idx_created_at                      │
                                └─────────────────────────────────────┘

Sequence diagram — GET /users/{id}

Client        Controller        Service          Repository       Database
  │                │                │                 │               │
  │ GET /users/1   │                │                 │               │
  │───────────────▶│                │                 │               │
  │                │ getUserById(1) │                 │               │
  │                │───────────────▶│                 │               │
  │                │                │  findById(1)    │               │
  │                │                │────────────────▶│               │
  │                │                │                 │  SELECT       │
  │                │                │                 │──────────────▶│
  │                │                │                 │◀──────────────│
  │                │                │◀────────────────│ Optional<User>│
  │                │◀───────────────│  UserDTO        │               │
  │◀───────────────│  200 OK        │                 │               │

6-phase migration sequence — leaf dependencies first

The migration/component-order.md file gives an ordered migration plan where each phase only touches files whose own dependencies are already migrated — avoiding mid-migration build failures.

What AWS recommends running next — two named transformations

The last section of technical-debt-report.md doesn't just list issues. It names the exact AWS Transform transformations to run next — strings you can drop directly into the CLI:

Here's exactly what each one does:

Takeaways

AWS Transform's comprehensive codebase analysis is the most thorough automated pre-migration assessment I've run. A few things stood out:

• The output is genuinely actionable, not just comprehensive. The 6-phase migration sequence respects leaf-first dependency order. The validation criteria is a real test checklist, not documentation filler. The debt table prioritises the linked chain correctly — it doesn't list Java 8 and Spring Boot 2.5 as independent issues; it surfaces the dependency between them.
• Named next-step transformations are the real value. Assessment tools typically end with "you should upgrade Java." This one ends with AWS/java-version-upgrade and AWS/JBoss-to-Spring-Boot — exact strings you paste into the CLI to start the automated migration.
• 61 agent minutes is fast for this output volume. 33 files, 2,216 lines, sequence diagrams, dependency graphs, full remediation plan — generated by reading source code, not config. For a one-time pre-migration assessment on a legacy system this is genuinely faster than any manual approach.
• Run this before any automated transformation. Knowing that the javax.* namespace is the upgrade blocker before you start is the difference between a clean transformation run and debugging a half-migrated build at 2am.
• The portfolio-level variants are the next frontier. For teams managing 20+ Java services at different maturity stages, AWS/portfolio-modernization-readiness-analysis should consolidate findings and prioritise which services move first — with migration waves, not just individual reports.