Migration & Modernization
New in AWS Transform: Analyze Your Code for Modernization and Agentic Readiness
Your VP of Engineering wants to know which of your 200 services to modernize first. Your AI team wants to deploy agents against your order management system next quarter. Your CISO wants to know what happens when an autonomous agent calls an API that was built in 2014 with hardcoded credentials and no rate limiting. They’re all asking different versions of the same question: are our systems ready? Until now, answering that question meant 4 to 8 weeks of interviews, fragmented tooling, and reports that vary by who wrote them. The result: projects stall in discovery, teams lose momentum, and modernization stays in the “planning” phase indefinitely. Today, we are announcing two managed analyses in AWS Transform that change this.
Two questions converge:
- How mature is our cloud architecture? Where are the modernization gaps, and what is the fastest path to close them?
- Are our systems safe for agents to call? Can an AI agent invoke your APIs without causing data leaks, cascading failures, or compliance violations?
Two Analyses. One Repository.
Agentic Readiness Analysis (ARA) evaluates whether your systems are ready to be safely called by AI agents. It covers APIs, identity, state management, human-in-the-loop controls, and observability.
Modernization Analysis (MODA) scans your code for cloud-native maturity gaps and maps findings to AWS modernization pathways.
You can run either or both on the same repository. Both complete in 5 to 30 minutes per repository, perform a read-only scan of your code, require no infrastructure changes, and produce output you own entirely. Pricing is per agent minute and a typical analysis of a 12K-line service costs $1-$2.
Agents depend on modern foundations: accessible APIs, structured data, proper identity boundaries, and observable infrastructure. Organizations that want to run agents but have not modernized their underlying systems will find that those systems become the bottleneck. MODA shows where the foundation needs reinforcement; ARA shows what specifically breaks when agents start calling.
Agentic Readiness Analysis (ARA)
In a previous post, we introduced Agentic Readiness as a method for evaluating whether applications can safely support agent interaction across five pillars: API and interface readiness, security and identity, data handling, operational resilience, and observability. ARA is the automated implementation of that method, delivered as a managed transformation definition in AWS Transform.
How ARA Thinks
Three mechanisms make ARA’s output actionable rather than generic:
Automatic Service Archetype Classification. ARA classifies each service into an archetype (data-plane, control-plane, stateless utility, event processor, and others) before evaluating it. The archetype determines which questions are relevant. A stateless utility is not penalized for lacking state rollback. An event processor is not flagged for missing synchronous API contracts. You can override the classification via configuration if you know the service better than the scanner does.
Core + Extended Question Tiers. Each pillar contains core questions that apply universally and extended questions that activate based on archetype and context. A data-plane service with agent_scope: write-enabled triggers the full extended set for operational resilience. A library with agent_scope: read-only skips those entirely. The result: no irrelevant findings, no wasted remediation effort.
Context-Sensitive Severity. The same gap produces different severities depending on how agents interact with the system. An application lacking idempotent write operations is Low severity if agents only read from it. That same gap becomes a High-severity blocker if agents modify state through it. The agent_scope field in your configuration drives this. One field changes which findings become blockers versus advisories.
ARA Output: Readiness Classifications
Every service receives a readiness classification:
| Classification | Meaning |
|---|---|
| Agent-Ready | Safe for production agent deployment today |
| Pilot-Ready | Can run a controlled pilot with compensating controls |
| Remediation Required | Known gaps with known patterns to fix |
| Not Agent-Integrable | Fundamental rework needed before agent interaction |
Every finding is tagged High, Medium, or Low severity, backed by file-level evidence, and paired with a specific recommendation connecting to AWS services and architectural patterns.
Modernization Analysis (MODA)
MODA evaluates cloud architecture maturity, operational readiness, and modernization potential across five categories:
| Category | What It Evaluates |
|---|---|
| Infrastructure & Platform | Compute strategy, container adoption, infrastructure as code (IaC) maturity |
| Application Architecture | Service decomposition, dependency management, async patterns |
| Data Platform | Database strategy, caching, event streaming |
| Security Baseline | Secrets management, network segmentation, compliance automation |
| Operations & Observability | continuous integration/continuous delivery (CI/CD) maturity, deployment strategies, incident management |
How MODA Thinks
MODA applies similar precision through three mechanisms:
Archetype-Calibrated Scoring. MODA classifies the application and adjusts expectations. A stateless Lambda function is not penalized for lacking container orchestration. An infrastructure-only repo is not evaluated against application architecture criteria. Each criterion is scored against maturity expectations for the given archetype, and gaps are translated into the unified findings model (High, Medium, Low severity) shared with ARA.
Automatic Pathway Detection. MODA detects modernization pathways based on actual code and configuration patterns: Move to Containers, Move to Cloud Native, Move to Managed Databases, Move to Open Source, Move to Managed Analytics, Move to Modern DevOps, and Move to AI. It does not recommend pathways irrelevant to the application’s actual architecture. Findings align to the AWS Well-Architected Framework.
Technology Preference Steering. You specify preferred and avoided technologies in your configuration. MODA uses these to frame recommendations without overriding severity. If you prefer Amazon EKS and Amazon Aurora but want to avoid a stateless AWS Lambda function, MODA steers recommendations toward those preferences.
MODA Output: Readiness Classifications
Like ARA, MODA assigns a readiness classification to every service:
| Classification | Meaning |
|---|---|
| Cloud-Native Ready | Architecture meets cloud-native standards across all dimensions |
| Pilot-Ready | Can proceed with modernization pilots; minor gaps remain |
| Remediation Required | Significant modernization gaps that need resolution before proceeding |
| Not Modernization Ready | Fundamental rework needed across multiple dimensions |
MODA uses softer thresholds than ARA. In ARA, a single High-severity finding means the system has a deployment blocker for agent safety. In MODA, a single High-severity finding represents one modernization gap and maps to Pilot-Ready rather than Remediation Required. This reflects the different stakes: an agent calling an insecure API is an immediate safety concern; a system lacking container orchestration is a maturity gap with a clear upgrade path.
Four Managed Transformation Definitions
Everything described above is now available as four AWS-managed transformation definitions. Published analysis logic you invoke directly via the AWS Transform CLI (atx). No custom setup, no authoring required.
$ atx tp list
AWS/agentic-readiness-analysis
AWS/modernization-readiness-analysis
AWS/portfolio-agentic-readiness-analysis
AWS/portfolio-modernization-readiness-analysis
The first two run per-repository. Point them at a codebase and get a full assessment. The last two run at portfolio level. They consume individual reports and produce cross-cutting analysis: systemic patterns, shared dependency risks, and a consolidated remediation roadmap across all your services.
All four are managed by AWS and versioned independently. You do not maintain them. You invoke them.
Try It Now: Running an Analysis with ATX CLI
Here is how to run an analysis on a single repository in under five minutes.
Prerequisites
- AWS credentials configured (
aws sts get-caller-identity) - AWS Transform CLI installed (
atx --version)
Step 1: Verify the Managed Transformation Definitions
atx tp list
You should see all four managed TDs listed.
Step 2: Run ARA on Your Repository
atx custom def exec \
-n AWS/agentic-readiness-analysis \
-p ./my-service \
-x -t
The -p flag points to your source code, -x runs non-interactively, and -t trusts all tools. Analysis typically completes in 5 to 30 minutes and produces a four-artifact report bundle:
| Artifact | Purpose |
|---|---|
*-ara-report.md |
Rich narrative with full findings and remediation guidance |
*-ara-report.json |
Machine-readable contract (authoritative if artifacts disagree) |
*-ara-report.html |
Self-contained interactive visualization |
*-ara-report.metadata.json |
Version compatibility sidecar |
Step 3: Run MODA on the Same Repository
atx custom def exec \
-n AWS/modernization-readiness-analysis \
-p ./my-service \
-x -t
Same command pattern, different analysis. Now you have both an agentic readiness assessment and a modernization maturity assessment for the same codebase.
Customizing the Analysis
Pass additional context via a config file to tailor results:
atx custom def exec \
-n AWS/agentic-readiness-analysis \
-p ./my-service \
-g file://atx-config.yaml \
-x -t
Example atx-config.yaml for ARA:
additionalPlanContext:
repo_type: "application"
service_archetype: "data-plane"
agent_scope: "write-enabled"
context: "Payment processing service"
priority: "P0"
The agent_scope field drives conditional severity. The service_archetype field lets you override ARA’s auto-classification.
Example atx-config.yaml for MODA:
additionalPlanContext:
repo_type: "application"
context: "Legacy order management system"
priority: "P1"
preferences:
prefer: ["eks", "aurora", "bedrock"]
avoid: ["self-managed-kafka", "oracle"]
Scaling to a Portfolio
Portfolio-Level TDs
The portfolio transformation definitions (AWS/portfolio-agentic-readiness-analysis and AWS/portfolio-modernization-readiness-analysis) are also managed TDs. You invoke them the same way:
atx custom def exec \
-n AWS/portfolio-agentic-readiness-analysis \
-p . \
-g file://atx-portfolio-config.yaml \
-x -t
These consume individual reports and produce cross-cutting insights: systemic gaps, shared dependency risks, and a consolidated prioritized roadmap.
The Portfolio Analysis Orchestrator
Orchestrating 10+ repos manually gets tedious. The Portfolio Analysis Orchestrator is an open source Kiro Power that automates the full workflow using the same four managed TDs. It handles what gets complex at scale:
- Auto-classification: scans each repo and classifies it to tailor the analysis
- Parallel execution: spawns subagents across repositories while enforcing safety contracts
- Portfolio-level analysis: runs cross-cutting portfolio TDs that identify systemic patterns
- Four-artifact bundles per analysis, per repo, plus portfolio-level reports
GitHub: https://github.com/aws-samples/sample-agentic-readiness-analysis-orchestrator
What the Output Looks Like
Both analyses produce rich, interactive HTML reports alongside machine-readable JSON and Markdown artifacts. Below are examples from a portfolio of five repositories evaluated with the ecommerce-platform-v2 sample.
Agentic Readiness Report: The portfolio-level report shows readiness classifications across all repositories, identifies cross-cutting blockers (like missing machine identity authentication), and provides a phased remediation plan with severity-based prioritization.
Figure 1: Portfolio-level Agentic Readiness report for ecommerce-platform-v2 — 148 total findings across 5 repositories, with phased remediation plan and section heatmap.
Modernization Readiness Report: The modernization report evaluates cloud-native maturity across infrastructure, application architecture, data platform, security, and operations. It maps findings to severity levels and provides a remediation roadmap organized by modernization phase.
Figure 2: Portfolio-level Modernization Readiness report for ecommerce-platform-v2 — 135 findings across 5 repositories, with remediation phases and severity breakdown by repo.
Early Feedback
“The technical perception of the tool was extremely positive, demonstrating high potential to accelerate deliveries and optimize processes. The generated recommendations cover infrastructure, application, and CI/CD fronts with a depth that adds immediate value, allowing validation of the technology roadmap without starting from scratch.”
Enzo Trujillo, Site Reliability Engineer (SRE), DreamSquad
“This directly addresses one of the most common barriers we see with customers beginning modernization journeys: knowing where to start. Having a reliable, automated readiness assessment accelerates time-to-decision and reduces the risk of costly misalignment early in the project lifecycle.”
Ryo Hang, Technical Cofounder, Ascending Inc.
Conclusion
Every organization will deploy AI agents against their existing systems. The question is not if, but whether those systems are ready when it happens. Agentic Readiness Analysis (ARA) and Modernization Analysis (MODA) give you the answer in minutes, from your actual code, with evidence you can act on immediately.
Get started today. Install the AWS Transform CLI, point it at one repository, and see what it finds:
atx custom def exec -n AWS/agentic-readiness-analysis -p ./your-service -x -t
Your first report reveals what to fix, where to start, and how to proceed. Then scale the analysis across your portfolio to build a consolidated remediation roadmap. In under 30 minutes, you will have a clear, evidence-backed modernization plan for your entire organization.