What if you could submit 100 application repositories to one platform, analyze their modernization needs, reuse approved code transformations, and track execution results from a single dashboard?
That is the idea behind ModernizeHub, a project architecture for agentic application modernization on AWS.
Modernizing one application can be challenging. Modernizing hundreds of applications introduces a different level of complexity: repository discovery, dependency upgrades, code transformation, testing, execution capacity, and reporting.
In this article, we'll explore how to design a practical modernization platform using:
- Strands Agents for agent orchestration
- AWS Transform custom for reusable code transformations
- Amazon Bedrock AgentCore for running and operating agents
- AWS Batch for parallel repository jobs
- Amazon S3 for artifacts and reports
- Amazon DynamoDB for job tracking
- React, Amazon CloudFront, API Gateway, and Lambda for the application interface and backend
Note: ModernizeHub is a project name used for this walkthrough. The architecture is inspired by AWS's public sample implementation. The examples and results shown below are illustrative, not claimed production test results.
1. The problem: Modernization doesn't scale easily
Imagine a company with 200 applications.
Some use older Python runtimes. Others depend on legacy Java frameworks, outdated SDKs, or configurations that need to change before migration.
The engineering team needs to:
- Understand each repository.
- Identify the required changes.
- Find an existing transformation or create a new one.
- Apply the transformation.
- Run builds and tests.
- Review failures and approve changes.
- Report the outcome.
Doing all this manually for every application consumes time and creates inconsistent results.
An agentic workflow can help coordinate these activities, while reusable transformations and automated tests make the process more repeatable.
The goal is not to let AI change everything without supervision. The goal is to automate repetitive work while keeping engineers in control.
2. What are we building?
ModernizeHub is a web application where developers can submit one repository or upload a CSV file containing many repositories.
The workflow analyzes each application, identifies an appropriate transformation, routes missing transformations for review, executes approved jobs, and displays the results.
The platform includes:
- Repository analysis
- Transformation discovery
- Custom transformation creation
- Single-repository execution
- CSV batch processing
- Parallel job execution
- Build and test validation
- A dashboard for status and logs
- Human approval for sensitive changes
3. Architecture
Here's the high-level design.
Developer / Platform Engineer
|
v
React Dashboard
|
CloudFront + S3
|
v
API Gateway
|
v
AWS Lambda
|
v
Amazon Bedrock AgentCore
|
v
Strands Orchestrator
|
+-------+--------+
| | |
v v v
Analysis Discovery Custom
Agent Agent Creation
Agent
|
Human Review
|
v
Approved Transformation
|
v
AWS Batch
|
v
AWS Transform Custom CLI
|
v
Source Repository
|
+------+------+
| |
v v
Amazon S3 DynamoDB
Artifacts Job Tracking
| |
+------+------+
|
v
Web Dashboard
This is a logical architecture. The application code must implement the API integrations, permissions, job submission, status updates, and result retrieval.
What does each service do?
React, S3, and CloudFront
Provide the user interface for repository submission, batch uploads, transformation review, and job tracking.
Amazon API Gateway and AWS Lambda
Receive requests, validate input, create job records, check authorization, and initiate the asynchronous workflow.
Strands Agents
Coordinate specialized agents and tools. The orchestrator decides which step should happen next based on validated results.
Amazon Bedrock AgentCore
Provides infrastructure for running and operating agents. AgentCore Runtime can host the orchestrator, while supporting capabilities can help with context and observability.
AWS Transform custom
Provides reusable code transformation capabilities for supported modernization tasks.
AWS Batch
Runs independent repository jobs according to the configured queue, compute resources, and concurrency limits.
Amazon S3 and DynamoDB
Store output artifacts and job metadata so developers can retrieve results and track progress.
4. Why use multiple agents?
Instead of asking one agent to analyze code, invent transformations, execute shell commands, and validate everything, we can separate the responsibilities.
Agent 1: Repository Analysis Agent
This agent inspects a repository and identifies its technology stack, dependencies, build system, tests, and potential modernization blockers.
An illustrative output could be:
{
"language": "Java",
"build_tool": "Maven",
"framework": "Spring Boot",
"target": "Spring Boot 3",
"tests_detected": true,
"manual_review_recommended": true
}
These values are examples. A real implementation must derive them from repository evidence.
Agent 2: Transformation Discovery Agent
This agent checks whether a suitable transformation already exists.
If an approved transformation matches the repository and target, the workflow can use it. Otherwise, the orchestrator can request a candidate transformation.
Agent 3: Custom Transformation Creation Agent
This agent helps translate a modernization requirement into a candidate transformation definition.
For example:
Create a reusable transformation for supported Spring Boot 2 to Spring Boot 3 migration patterns. Identify dependency changes, update supported configuration patterns, and flag unsupported cases for manual review.
The candidate must be tested and reviewed before it is added to a shared transformation catalog.
Never treat generated transformation logic as automatically trusted production code.
Agent 4: Execution Agent
This agent coordinates the execution request and submits approved work to the execution system.
AWS Batch runs the configured transformation container. The job's exit code and validation results determine the actual outcome.
The orchestrator
The Strands orchestrator coordinates the workflow:
- Validate the request.
- Analyze the repository.
- Find an appropriate transformation.
- Request a new candidate if needed.
- Route it for approval.
- Submit approved work.
- Collect execution and test results.
- Update the job record.
This division makes the workflow easier to understand, test, and govern.
5. Design the web application
A useful platform needs a clear interface, not just an agent that responds to prompts.
Screen 1: Dashboard
The dashboard shows the status of the modernization portfolio.
+--------------------------------------------------+
| ModernizeHub Account |
+--------------------------------------------------+
| Total Repositories: 200 |
| Completed: 142 Running: 18 |
| Failed: 12 Awaiting Review: 28 |
| |
| [Analyze Repository] [Upload CSV Batch] |
| |
| Repository Transformation Status |
| payments-service Java Upgrade Complete|
| customer-api Python Upgrade Running |
| billing-worker Custom Migration Review |
+--------------------------------------------------+
These are mock numbers for illustrating the interface, not real execution results.
The production dashboard should retrieve actual data from the backend.
Screen 2: Analyze a repository
A developer enters a repository URL and selects the modernization target.
Repository URL:
https://github.com/example-org/payments-service
Modernization Goal:
Upgrade supported Spring Boot 2 patterns to Spring Boot 3
Validation Profile:
Maven build and unit tests
[Analyze Repository]
The API validates the request, creates a job ID, and starts the asynchronous workflow.
The example repository URL is illustrative.
Screen 3: Custom transformation builder
If no suitable transformation exists, the developer can provide a natural-language requirement.
Transformation Name:
spring-boot-3-modernization
Requirements:
- Identify supported dependency changes
- Update compatible configuration patterns
- Flag unsupported changes
- Produce a reviewable transformation
[Generate Candidate]
The application displays the generated candidate so an engineer can inspect, test, approve, or reject it.
Screen 4: Batch processing
The developer uploads a CSV file, previews the repositories, fixes invalid rows, and submits the batch.
Each accepted repository becomes an independent job.
Screen 5: Job details
Each job should display:
- Repository and revision
- Transformation name and version
- Current status
- Execution logs
- Build and test results
- Output artifact location
- Failure details
- Approval history
This makes it easier to troubleshoot one application without losing visibility into the rest of the batch.
6. Example: Submit multiple repositories with CSV
Create a file named sample-batch.csv:
repository_url,transformation_name,validation_profile,context
https://github.com/example-org/service-a,python-runtime-upgrade,python-tests,Upgrade supported Python patterns
https://github.com/example-org/service-b,spring-boot-modernization,maven-tests,Review framework dependencies
https://github.com/example-org/service-c,aws-sdk-migration,java-tests,Update supported SDK usage
These are example rows. The repositories must be accessible, and the transformation names and validation profiles must exist in the deployed platform.
What happens after upload?
Step 1 — Validate the input
Check required fields, repository policies, transformation names, duplicate submissions, and file size.
Step 2 — Preview the batch
Show the parsed rows and allow the user to fix errors.
Step 3 — Create job records
Create a unique ID for each accepted repository.
Step 4 — Resolve transformations
Find approved transformations and route missing or newly generated definitions through the appropriate review process.
Step 5 — Execute jobs
Submit approved jobs to AWS Batch, respecting concurrency limits.
Step 6 — Validate changes
Run the configured build and test commands.
Step 7 — Report results
Update each job's status and expose available logs and artifacts.
An illustrative outcome might be:
| Repository | Status | Next step |
|---|---|---|
| service-a | Completed | Review validation report |
| service-b | Failed validation | Investigate build error |
| service-c | Awaiting approval | Review proposed transformation |
These results are examples, not claimed test results.
A failure in one repository should not automatically mark every other job in the batch as failed.
7. Validate the transformed code
An agent saying "completed" does not prove that the application works.
Each execution should:
- Check out an approved repository revision.
- Prepare an isolated working environment.
- Run the selected transformation.
- Capture logs and the exit code.
- Run approved build and test commands.
- Store the patch and reports.
- Update the job status.
- Flag failures for investigation.
For a Maven-based Java application, a test step might be:
mvn -B test
For a Python application, it might be:
python -m pytest
These are examples only. Use commands appropriate to the repository and toolchain.
Do not execute arbitrary commands supplied by an untrusted repository or model output in a privileged environment.
For more complete validation, add static analysis, dependency security scanning, integration tests, and application-specific acceptance tests.
A successful build is useful evidence, but it does not guarantee that all application behavior remains correct.
8. Infrastructure as code: CDK, SAM, or Terraform?
Infrastructure as code makes the deployment reproducible.
The platform needs resources for the frontend, API, agent runtime, execution environment, storage, tracking, and monitoring.
A project might organize its code like this:
modernizehub/
├── frontend/
├── api/
├── agents/
│ ├── orchestrator.py
│ ├── analyze_agent.py
│ ├── discovery_agent.py
│ ├── create_agent.py
│ └── execute_agent.py
├── batch/
│ ├── Dockerfile
│ └── entrypoint.sh
├── transformations/
├── tests/
├── samples/
│ └── sample-batch.csv
└── infrastructure/
├── cdk-sam/
└── terraform/
This is a suggested structure, not the exact structure of the AWS sample.
AWS's public repository contains an implementation under agentic-atx-platform and documents deployment using AWS CDK and AWS SAM.
Explore it here:
https://github.com/aws-samples/aws-transform-custom-samples/tree/main/agentic-atx-platform
If your team uses Terraform, you can build an equivalent Terraform implementation for supported AWS resources and deployment steps. However, the linked sample should not be mistaken for a ready-made Terraform deployment.
Before deploying, review current service availability, model access, IAM permissions, network requirements, and cleanup instructions.
9. Security considerations
A modernization platform can read source code and execute build tools. Security must be part of the design.
Least privilege: Give each component only the permissions it needs.
Secure credentials: Do not embed repository tokens in prompts, logs, or container images.
Isolated execution: Run jobs in controlled environments with resource limits and restricted network access where practical.
Human approval: Review new transformation definitions before publishing them for reuse.
Reviewable changes: Preserve the original revision and make patches easy to inspect.
Safe retries: Track job IDs, transformation versions, and outputs to prevent blind repeat execution.
Auditability: Record the requester, repository revision, transformation version, approval status, and validation results.
Cost controls: Limit concurrency and monitor model usage, compute, storage, and logging costs.
The goal is to automate repetitive work without removing engineers from important decisions.
10. Try the public AWS sample
You do not have to build every component from scratch.
Start with the public repository:
https://github.com/aws-samples/aws-transform-custom-samples
Then:
- Review the
agentic-atx-platformREADME and architecture. - Check the current prerequisites, AWS Region, model access, and IAM requirements.
- Configure the required AWS credentials and development tools.
- Deploy the sample using its documented instructions.
- Test with one repository that you control.
- Verify job status, transformation output, logs, and validation results.
- Test a small CSV batch.
- Increase concurrency only after reviewing reliability and cost.
- Follow the documented cleanup procedure when finished.
Deployment commands and requirements can change, so use the repository's current instructions.
11. How do we measure success?
Measure the platform using actual outcomes rather than the number of agents.
Useful metrics include:
- Number of repositories submitted and completed
- Percentage matched to existing transformations
- Custom transformations approved or rejected
- Transformation execution success rate
- Build and test pass rate
- Average processing time per repository
- Manual intervention rate
- Cost per completed repository
- Changes successfully reviewed and merged
Compare these metrics with your existing modernization process before claiming productivity improvements.
Conclusion
Modernizing hundreds of applications is a coordination challenge involving code analysis, transformation selection, execution, testing, and governance.
Strands Agents can coordinate the workflow. AWS Transform custom provides reusable transformation capabilities. Amazon Bedrock AgentCore supports the agent runtime, while AWS Batch enables independent repository jobs to run in parallel.
A dashboard, API, S3, DynamoDB, and infrastructure as code bring these capabilities together into an application that engineers can monitor and extend.
The most important lesson is this:
Don't give AI unrestricted control over every repository. Let agents help plan the work, use approved transformations to make changes, validate the results, and keep engineers in control of important decisions.
Start with one repository. Prove the workflow. Test a small batch. Then scale based on evidence.
Top comments (0)