AWS Transform Custom: The Agentic AI Service That Learns While It Modernizes Your Code

Technical debt consumes 20% of IT budgets across the industry. Organizations spend $1.52 trillion per year in the US alone dealing with it. And now leadership wants AI agents running on top of codebases that haven’t been touched in years.

The modernization you keep deferring is now the thing standing between you and the AI strategy your CEO announced last quarter.

But here is the real problem: modernizing one repository is easy. Modernizing 200 is a coordination nightmare. The code transformation itself takes days. The remaining weeks get consumed by orchestrating teams, ensuring consistent patterns across codebases, and managing dependencies so upstream changes don’t break downstream systems.

This is the problem AWS Transform Custom was built to solve.

I work as a Solutions Architect in Brazil, and I’ve seen customers defer Java upgrades, Lambda runtime migrations, and framework transitions for years because there is never bandwidth. The work is understood. It’s just tedious, repetitive, and risky when done inconsistently across dozens of repos. ATX changes that calculus entirely.

What AWS Transform Custom Actually Is

AWS Transform Custom (ATX) is an agentic AI service purpose-built for code modernization at scale. It is not a chatbot that generates code. It is not an AI coding assistant running independently on each repository.

What makes it different is one word: learning.

Every execution captures patterns, fixes, and edge cases as reusable knowledge. So transformations get faster and more reliable with every run. The system literally gets smarter the more you use it.

You define transformations using natural language descriptions, documentation, and code samples. The service then applies those patterns consistently across hundreds or thousands of repositories.

The Core Mental Model: Learn, Scale, Improve

The workflow follows a deliberate progression that AWS calls the Learn-Scale-Improve Flywheel:

Learn — You start with 2–3 representative repositories in interactive mode. You work directly with the AI agent, providing feedback and validating quality. When the agent encounters ambiguity, it asks questions. You provide guidance, and the system captures that context. Result: a transformation definition enhanced with your organizational knowledge.

Scale — You shift to non-interactive mode for bulk execution. The system processes dozens or hundreds of repos overnight without manual intervention, applying patterns learned during the pilot. It validates transformations using your build and test commands and tracks progress across your portfolio.

Improve — After each batch, you review the Knowledge Items the system captured during processing. These surface new edge cases and patterns that the pilot did not cover. You approve the valuable learnings, and the transformation improves for the next round.

This cycle repeats. Each round of bulk execution generates insights that make the next round more effective. Success rates increase, manual intervention decreases, and edge case handling improves with every iteration.

Here is how I think about it visually:

The first pass through all three phases establishes your baseline. After that, the Scale and Improve phases loop continuously. Each iteration produces better results than the last.

Knowledge Items: The Compounding Advantage

This is the feature that separates ATX from running any AI coding tool on each repo independently.

Think of Knowledge Items as institutional memory for code transformations. They are automatically extracted learnings from every execution. When the agent encounters an issue, resolves it, and moves on, that resolution gets captured.

Here is a concrete example. During a Java 8 to 26 upgrade, the agent discovered that:

• Mockito 5.14.2’s ByteBuddy cannot handle Java 26 bytecode. Fix: upgrade to Mockito 5.15.2.
• Spring Boot 3.2.12’s ASM library cannot parse Java 26 class files (major version 70). Fix: upgrade to Spring Boot 3.5.14 or newer.

These learnings start disabled. You review and approve them. Once approved, they apply automatically to every subsequent Java 26 upgrade across your entire portfolio. The second repository benefits from what the first one taught the system.

References (docs you provide upfront) set the starting point. Knowledge Items are where the real value compounds.

What You Can Transform

Before listing the patterns, here is what a transformation actually looks like in practice. No tutorial needed, just the before and after:

Java: javax to jakarta namespace migration (Spring Boot 2 → 3)

// Before
import javax.validation.Valid;
import javax.persistence.Entity;

// After
import jakarta.validation.Valid;
import jakarta.persistence.Entity;

Node.js: callback handler to async/await (Lambda runtime upgrade)

// Before (Node.js 20)
exports.handler = function(event, context, callback) {
    const result = processEvent(event);
    callback(null, result);
};

// After (Node.js 24)
exports.handler = async function(event) {
    const result = await processEvent(event);
    return result;
};

These are not hypothetical. These are the exact patterns ATX applies across hundreds of files in a single run, validating compilation and tests at each step.

Now, the full spectrum of supported patterns:

ATX supports a broad spectrum of modernization patterns:

Language Version Upgrades — Java 8 to 17/21/26, Python 3.9 to 3.13, Node.js 12 to 22/24, TypeScript upgrades

Framework Upgrades — Spring Boot 2.x to 3.x, React 17 to 18, Angular upgrades, Django upgrades

Framework Migrations — Angular to React, Redux to Zustand, Vue.js to React

API and Service Migrations — AWS SDK v1 to v2 (Java, Python, JavaScript), Boto2 to Boto3, JUnit 4 to 5, javax to jakarta

Infrastructure as Code — AWS CDK to Terraform, Terraform to CloudFormation, Bash to PowerShell

Architecture Migrations — x86 to AWS Graviton (ARM), on-premises to Lambda, traditional server to containers

Code Refactoring — Print to logging frameworks, string concatenation to f-strings, type hints adoption, observability instrumentation

Organization-Specific — Internal library migrations, proprietary framework transitions, custom coding standards enforcement

Beyond these, you can define completely custom transformations for anything unique to your organization.

How Simple It Looks in Practice

You interact through a CLI or web interface. Here is what running a managed transformation looks like:

atx custom def exec \
    -p ./my-project \
    -n AWS/java-version-upgrade \
    -c "mvn clean compile -DskipTests" \
    --configuration "additionalPlanContext=Target Java version is Java 21" \
    -x -t

The agent analyzes the full dependency graph, applies all changes in a coordinated pass, verifies compilation and tests, and commits everything as a single atomic change on a local git branch. You review and merge when satisfied.

For custom transformations, you create a definition through natural language:

atx custom

From there, you describe what you want (“Migrate our internal auth library from v2 to v3, update all deprecated API calls”) and provide documentation or examples. The system generates the transformation definition, and you iterate until it works reliably on sample repos. Then you publish it for your team.

Real Customer Results

After one year in production, AWS Transform has processed over 4.5 billion lines of code and saved customers 1.6 million hours (810 developer-years of effort).

Here are specific public examples:

Air Canada upgraded Node.js runtimes in days with 90% efficacy and 80% cost reduction compared to manual effort. They made AWS Transform their internal standard for future upgrades.

ADP modernized a complex mainframe application using Transform’s mainframe and custom capabilities, scaling for 1.1 million clients with results in weeks instead of the years originally estimated.

Signaturit Group cut their Windows .NET to Linux migration timeline from 6–8 months down to a few days.

CSL planned migrations for thousands of servers in days, a 10x acceleration over their prior approach.

Enterprise software company (unnamed) migrated Control-M workflows to Apache Airflow. Original estimate: 12 weeks of intensive coordination. Actual result: 2.5 weeks, 100% success rate, 19% runtime performance improvement in the transformed code, and 3–5x faster delivery with 10–20x reduction in effort hours.

Thomson Reuters transforms 1.5 million lines of code per month using AWS Transform. Results: 40% faster pace of modernization, 30% reduction in cloud operating expenses, 25% faster time to commit new feature changes, and 15% improvement in systems reliability.

QAD achieved 60–70% productivity gains across modernization projects.

One of the strongest signals: 4 out of 5 customers come back and do more projects. Roughly half now use multiple transformation capabilities.

Pricing: Pay Only for Active Agent Work

The pricing model is straightforward: $0.035 per agent minute.

Agent minutes only count when the service is actively planning, reasoning, analyzing, or modifying your code. You are not charged for time your local machine spends compiling, running tests, or building.

Practical examples of what this means:

• SDK upgrade (~3,000 lines of code): ~20 agent minutes = $0.70
• Java version upgrade (~17,000 LOC): ~72 agent minutes = $2.52
• Python runtime upgrade (~4,000 LOC): ~37 agent minutes = $1.30

Assessment, Windows modernization, mainframe modernization, and VMware migration agents are all free. Custom transformations and the new continuous modernization capability are the paid features.

You can pause or stop a running transformation at any time, and resume within 24 hours.

When to Use AWS Transform Custom

The sweet spot is when you have:

• Multiple repositories that need the same type of transformation
• A pattern that is well-understood but tedious to apply manually
• Scale that makes inconsistency a real risk (different devs making different choices)
• Technical debt that compounds if not addressed systematically

It is less suited for:

• One-off refactoring of a single small codebase (just use your IDE agent)
• Transformations where requirements are still being figured out (define the pattern first)
• Code with zero test coverage and no validation path (the agent needs a way to verify its work)

The Bigger Picture: Continuous Modernization

AWS recently introduced continuous modernization (currently in preview, June 2026) that takes this to its logical conclusion. Instead of running transformations as discrete projects, it continuously monitors your connected repositories.

The workflow looks like this:

• You connect GitHub organizations, GitLab groups, Bitbucket workspaces, or local repositories
• The system runs automated analyses to identify technical debt, security vulnerabilities, modernization opportunities, and agent-readiness across your entire codebase
• Findings are prioritized by severity and presented with confidence scores
• You can trigger autonomous remediations that generate pull requests
• Remediations go through the same Learn-Scale-Improve loop, so quality compounds over time

Think of it as the difference between going to the doctor once a year versus wearing a health monitor 24/7. Continuous modernization catches issues as they emerge rather than letting them accumulate into multi-year projects.

This is where the industry is heading. Today’s modernization is tomorrow’s legacy. The only sustainable answer is to make modernization a continuous process, not a project.

Key Takeaways

1. It learns. Every transformation makes the next one faster and more reliable through Knowledge Items. This is the fundamental differentiator from one-off AI coding assistants.
2. It scales without losing consistency. What previously required weeks of team coordination happens overnight. The same patterns apply uniformly across hundreds of repos.
3. You stay in control. Nothing gets automatically applied to your code. Changes land on local branches. Knowledge Items require your approval. You review, you merge, you decide.
4. The economics work. At $0.035/agent-minute, a Java upgrade costs less than a coffee. The ROI becomes obvious when you multiply across a portfolio.
5. It fits your workflow. CLI for developers and pipelines, web app for campaign management, IDE plugins for in-editor use. It does not require you to change how you work.

The question is not whether to modernize. Every engineering leader already knows the answer to that.

The real question is: do you want to do it manually across 200 repositories, hoping each developer makes the same decisions? Or do you want to let a system compound its learnings, getting better with every repo it touches?

Start with one repository. Run atx custom def exec with an AWS-managed transformation. Review the diff. If the quality meets your bar, imagine that same quality applied uniformly across your entire portfolio overnight. That is what ATX Custom delivers.

Resources:

• AWS Transform Custom documentation
• Getting Started guide
• Pricing
• Knowledge Items deep dive
• Lambda runtime upgrades at scale