I Modernized a Legacy Java App with AWS Transform—Here’s What Happened

Legacy Java apps don’t age gracefully. Java 8 reached end of open-source support in 2019, Spring Boot 2.x followed in November 2023, and yet countless production codebases are still running on them—because upgrading manually is painful, risky, and time-consuming. AWS Transform promises to automate exactly this through agentic AI. I decided to put it to the test on a real Spring Boot petclinic app and document everything: setup, the first error I hit, what the agent changed, and whether the app actually ran afterward.

Spoiler: it worked. The agent made 528 line changes across 18 files, the dashboard showed 100% validation rate, and the petclinic came up clean on Java 21. Here’s the full story.

What is AWS Transform?

AWS Transform is AWS’s platform for enterprise IT modernization powered by agentic AI. It handles mainframe refactoring, VMware migration, Windows modernization, and—the focus here—Custom workloads like Java, Python, and Node.js runtime upgrades.

The platform learns from every transformation, and the numbers on their workspace dashboard reflect the scale of enterprise adoption:

Key Features & Concepts

Before diving in, here are the core building blocks of AWS Transform:

Setting Up AWS Transform

AWS Transform is enabled from inside the AWS console. You need two things: the web application (the chat-based agentic UI) and the CLI (for executing transformations locally).

Step 1 — Enable Capabilities

Navigate to AWS Transform and click Get Started. The capabilities page shows two sections: CLI for Custom workloads, and Web application for the full scope including mainframe and VMware.

Step 2 — Choose Your Identity Provider

Enabling the web app requires picking an identity provider: AWS Identity Center or an existing IdP (Microsoft Entra or Okta). This is a one-time irreversible decision.

Step 3 — Setup Complete

After enabling, the success screen confirms the web application is live and a service profile has been created.

Step 4 — Install the CLI

curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

The App: Spring Boot Petclinic on Java 8

I needed a realistic legacy app — not a toy. The Spring Boot petclinic is a well-known demo with real dependencies: Spring Boot 2.7.3, pinned to Java 1.8, with a full stack of libraries that all need updating. Here’s the pom.xml:

<artifactId>spring-petclinic</artifactId>
<version>2.7.3</version>

<parent>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.7.3</version>
</parent>

<java.version>1.8</java.version>

This is a textbook modernization target. Upgrading manually means: bumping the Java version, migrating every javax.* import to jakarta.*, updating database drivers, upgrading Spring Boot to a 3.x line, and resolving cascading dependency conflicts. AWS Transform is supposed to handle all of that autonomously.

Creating a Workspace & Starting a Job

Create a Workspace & Job

In the AWS Transform console, create a workspace, then inside it create a new CustomTransformation job. You’re dropped into the agentic chat interface with a two-step job plan in the sidebar:

Chat with the Agent

I typed exactly what I wanted: "Upgrade the Java 8 Spring Boot application to Java 21."

The agent identified AWS/java-version-upgrade — an AWS-managed transformation definition that handles the full stack: JDK bump, Jakarta EE namespace migration, database drivers, ORM frameworks, and Spring ecosystem updates. I said yes. The agent then generated the CLI command and opened the Monitor panel:

Running the Transformation — And Hitting an Error First

I copied the command from the dashboard and ran it. First attempt: I forgot the --configuration flag.

Three ways to pass the config:

# Inline flag (what I used)
--configuration "additionalPlanContext=The target Java version to upgrade to is Java 21"

# JSON file
--configuration "file://path/to/config.json"
# { "additionalPlanContext": "The target Java version to upgrade to is Java 21" }

# YAML file
# additionalPlanContext: The target Java version to upgrade to is Java 21

With the flag added, the second attempt ran cleanly:

The full working command:

atx custom def exec \
  --code-repository-path ~/petclinic-legacy-demo \
  --non-interactive \
  --trust-all-tools \
  --campaign ced189bc-bafb-4465-8d67-bda247aaf391 \
  --repo-name petclinic-legacy-demo \
  --add-repo \
  --configuration "additionalPlanContext=The target Java version to upgrade to is Java 21"

Under the Hood: What the Agent Does While "Thinking..."

The "Thinking..." state isn’t idle. The agent immediately starts producing artifacts. First it creates a plan.json — a structured JSON file that maps out every step, its goal, target components, and the exact verification command to run after:

It then creates a Transformation Worklog — a running log file tracking the project and every action taken:

With the plan established, the agent starts making targeted edits. Here it is using the editor tool (trusted) to make precise str_replace operations on pom.xml — each one surgical, each one completing in milliseconds:

After each step’s changes pass the build verification, the agent uses the vcs_control tool to commit directly to the staging branch with a structured commit message:

The Results: What the Agent Actually Did

The agent didn’t just bump a version number. It worked through the codebase in six structured, independently-committed steps — each one passing its own build validation before the next began.

Estimated Time Saved: 422 Hours

The transformation dashboard calculated 422 hours of manual effort saved, at a baseline of 10 lines of code per developer per day. The dashboard does not update automatically — you ask the agent in chat to refresh it.

100% Validated — 528 Lines, 18 Files

The Full Transformation Summary

At the end of the run, the agent outputs a complete Transformation Summary — every version change, every library migrated, and the final test results:

The Six-Step Commit History

Every step was committed separately by ATX Bot to the atx-result-staging branch, with a build verification before each commit:

What Changed Across Those 18 Files

The App Runs on Java 21

The proof that matters: does the app actually work after the transformation? I deployed the transformed code to an EC2 instance and hit it in a browser.

What’s Next — Part 2: Pentesting the Modernized App

The app is live on Java 21. But a modernized app isn’t necessarily a secure app. In Part 2, I’ll walk through how I pentested this exact petclinic deployment using the AWS Security Agent — running vulnerability scans, probing the attack surface, and seeing what AWS’s AI-powered security tooling finds on a freshly modernized Spring Boot application.

Key Takeaways