AWS Builder Center

Builder Center

I Let AI Agents Modernize My Legacy App: AWS Transform Custom + AI-DLC workflows (Part 2)

I Let AI Agents Modernize My Legacy App: AWS Transform Custom + AI-DLC workflows (Part 2)

A real story of upgrading old code with AWS Transform, planning with Kiro and AI-DLC, and moving to containers with automatic releases.

Series: AWS Transform (2 articles)

  1. 1
    I Let AI Agents Plan My AWS Migration: A Real AWS Transform Story (Part 1)
  2. 2
    I Let AI Agents Modernize My Legacy App: AWS Transform Custom + AI-DLC workflows (Part 2) This article

Sundaramsubramanian

Series: Agentic AI for migration and modernization
  • Part 1: I Let AI Agents Plan My AWS Migration: A Real AWS Transform Story
  • Part 2 (this post): I Let AI Agents Modernize My Legacy App: AWS Transform Custom + AI-DLC workflows

Moving in was only the beginning

Part 1 showed how AI agents changed migration for me. What surprised me even more was modernization: work that teams usually postpone for years, because it is slow, risky and nobody wants to touch old code.
In Part 1, the LegacyMart online store moved from its data center to AWS without closing. But moving house doesn't fix old wiring. The store still ran on Java 8, on a single server that could take everything down with it, with the database on that same server, and releases done by hand.
So my next goal was clear: bring the code up to date, remove the single point of failure, and make releases automatic and safe, again without closing the store.
Everything in this story happened in a real AWS account. Only the account number is hidden.

How AI agents helped this time

This time AI agents played two roles. One did the heavy lifting: AWS Transform custom upgraded the old code. Others acted as reviewers: specialist agents in Kiro with AI-DLC workflows reviewed the plan and the build as it took shape. I approved at every point.
The journey had four steps:
Upgrade the code with AWS Transform custom → Review the plan with Kiro and AI-DLC → Automate releases with a pipeline → Switch customers to the new version.

Step 1: An AI agent upgrades years-old code

Upgrading old Java means chasing outdated libraries and code that no longer compiles, so teams often postpone it for years.
AWS Transform custom hands this job to an AI agent that runs from the command line. It comes with ready-made, AWS-managed transformations (36 were available in my account, such as Java, Python and Node.js version upgrades and AWS SDK upgrades), and you can create your own. I used the Java version upgrade transformation.
  1. Gave the agent the code and a one-line goal: "upgrade to Java 21 and the latest Spring Boot 3."
  2. The agent made a plan, changed the code and built the application to prove it worked.
  3. It delivered the result as a normal code change (a commit) for review.
  4. I reviewed it and built it again myself.
The change is signed ATX Bot (AWS Transform), lists every upgrade it made, and ends with "Build status: Success".
Result: 7 files updated in about 42 minutes of agent work.
Insight: the key skill shifts from writing the upgrade to reviewing it.

Step 2: A second opinion from Kiro and AI-DLC workflows

What Kiro is: an AI development environment from AWS built for spec-driven work, meaning you agree on what to build before building it.
What AI-DLC adds: AI-DLC (AI-Driven Development Lifecycle) is a discipline for any kind of development, whether application code, infrastructure or a complex ETL pipeline. AI agents do the work, and people stay in control at every stage, from ideas through planning and building to operations.
AI-DLC workflows are the open-source, ready-to-use version of that discipline from AWS Labs . In brief:
  • A team, not one assistant: specialist agents (for example developer, security and quality) each bring their own view.
  • Human approval gates between stages, so nothing moves on without a person.
  • Right-sized for the job: ready-made scopes such as feature, bugfix, refactor, infrastructure and security patch, from a quick fix to a full enterprise delivery.
  • Customizable: tune the depth and testing level, let it compose a plan tailored to your task, or add your own stages, agents, rules and team knowledge through simple configuration files.
  • Not tied to one tool: it runs in Kiro (used here) as well as other AI coding assistants.
How I used it, step by step:
  1. Installed AI-DLC into the LegacyMart project with its installer, and selected Kiro as the tool to run it in.
  2. Ran a health check in Kiro's chat (/aidlc --doctor). No problems found.
  3. Described the goal in one prompt: containers, a managed database, automatic releases and no downtime.
  4. AI-DLC chose an infrastructure workflow that fits this kind of work: 13 stages with 10 approval gates.
  5. In the first stage, Practices Discovery, three specialist agents (developer, security and quality) read the code and asked 13 practical questions about testing, approvals, rollback and security.
  6. The agents drafted the project's rules in the project folder, so any person or AI working on it later follows the same standards.
  7. AI-DLC summarized the answers and stopped for a person to choose "Looks correct" or "Request changes".
On the right: a summary of all 13 answers and a clear choice. Nothing moves forward without a person.
Practical rules saved in the project, such as keeping container images small and never running them as an administrator.
What the AI team found: gaps an experienced reviewer would raise, namely no automated tests, no encryption between the application and the database, and no approval step before production.
Who did what: Kiro and the AI-DLC agents reviewed and planned while I built the containers and pipeline in Step 3 by hand. Their rules confirmed several of my choices, such as non-root containers and versioned images, and the gaps they found became my to-do list.
Honest note: this first stage used about 22 of the 50 monthly credits on Kiro's free plan, so I paused at the approval gate. Budget for a paid plan to run the full workflow.

Step 3: Building an assembly line for releases

Instead of copying files to a server by hand, I built an assembly line that turns every code change into a running application automatically.
  • AWS CodeCommit: Stores the code
  • AWS CodeBuild: Packages the app into a container
  • Amazon ECR: Stores the containers
  • Amazon ECS (Fargate): Runs the containers, with no servers to manage
  • AWS CodePipeline: Connects the stations: change, build, deploy
  1. Stored the code in CodeCommit.
  2. Added two small recipe files: how to package the app, and how to build it.
  3. Set up CodeBuild, ECR and an ECS service running two copies of the store.
  4. Connected them all with CodePipeline.
Three green stations, Source, Build and Deploy, triggered by a single code change.
Proof it works: I shipped a real fix through this pipeline while shoppers kept browsing. The containers were replaced one by one: 508 requests, 0 server errors.
Step 3 above sets up CodeCommit, CodeBuild, ECR, ECS and CodePipeline as separate services connected together. Some of that groundwork can be shortened with Kiro itself. Since Kiro is a full IDE with built-in Git support, you can connect it directly to a CodeCommit repository, and the agent can stage, commit and push code changes for you through plain chat, no separate terminal step needed. You can also ask it to draft the commit message or a pull request description, which speeds up the review step. The actual approval still happens as a human decision in CodeCommit's pull request view, which fits the "human stays at the gate" pattern this whole series follows. It doesn't replace CodeBuild, ECR or CodePipeline, those still handle building and deploying, but it removes some of the manual git handling around them.
Step 4: Switching customers while the store stays open
  1. Moved the data to Amazon RDS, kept as a live copy of the old database.
  2. Tested the new containers through a hidden entrance only I could use, while customers stayed on the old version.
  3. With pretend shoppers running, paused orders for a moment and confirmed both databases held the same last order (#293).
  4. Pointed the front door 100% to the new containers.
  5. Kept the old version ready, so going back is one setting.
Traffic split: new containers 100%, old server 0%.
Two near-misses, caught before any customer noticed:
  1. The upgraded app quietly changed the database. A new default in the modern framework, combined with an old setting, let the app alter the database on startup. That broke the live copy. I caught it in a pre-switch check and fixed it through the pipeline. Lesson: never let an application change its own database structure.
  2. The database almost ran out of connections. Each copy of the app holds connections open. Two containers plus the old server used 28 of about 30, so the next release could have caused an outage. Lesson: containers multiply connections, so size them for your database.

How it went

Same web address for customers, now served by containers on Java 21 (aws-ecs-fargate).
  • Page visits during the switch: 391 of 391 worked
  • Orders rejected during the brief write pause: 3, over about 15 seconds
  • Last order in old and new database: #293 in both
  • Release through the pipeline: 508 requests, 0 server errors
Is it still a monolith? Yes, on purpose. It is still one application, but with modern code, multiple copies, a managed database and safe releases, splitting off one service at a time is now far safer.

What I would modernize next

Modernization is a journey, not a single project. Natural next steps for LegacyMart:
  • Close the gaps Kiro found (tests in the pipeline, encrypted database connection, approval before production): the next AI-DLC stages plan and build these, with human approval.
  • Split the monolith gradually (move one piece, for example orders, into its own service behind the same load balancer): Kiro specs and AI-DLC turn each piece into requirements, design and tasks.
  • Keep code current at scale (libraries, SDKs and runtimes across many applications): AWS Transform custom managed or custom transformations.
  • Stay modern continuously (find and prioritize technical debt across all repositories): AWS Transform continuous modernization.
  • Let agents work in the background (dependency updates and routine fixes on a schedule): Kiro Crew , AWS's open-source, always-on agent workspace (not used in this story).

Key takeaways

  1. AI agents make long-postponed upgrades practical: AWS Transform custom took Java 8 to 21 in under an hour, ready for human review.
  2. Kiro with AI-DLC acts like a review team: specialist agents ask the right questions and wait for human approval.
  3. Automate the path to production and test on a hidden route before customers see anything.
  4. Watch the database during modernization: its structure and its connections.

The whole journey

Part 1: Move
  • AI agent assesses cost and size
  • AI agent recommends a strategy
  • AWS Transform MGN copies and tests the server
  • Customers switched in about 1.3 seconds
Part 2: Modernize
  • AI agent upgrades the code
  • Kiro and AI-DLC agents review the plan
  • Automatic pipeline to containers
  • 391 of 391 visits worked during the switch
What is the oldest application in your organization, and what would an AI agent find first?
# aws-transform# migration# agentic-ai# ai# app-modernization

Series: AWS Transform (2 articles)

  1. 1
    I Let AI Agents Plan My AWS Migration: A Real AWS Transform Story (Part 1)
  2. 2
    I Let AI Agents Modernize My Legacy App: AWS Transform Custom + AI-DLC workflows (Part 2) This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article