Agentic AI for Cloud Migration and Application Modernization at Scale

commonwealth_bank_of_australia · Finance · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.2 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Cloud migration

Commonwealth Bank of Australia needed to modernize legacy Windows applications faster despite missing documentation and technical debt.

Constraints:

Security and compliance
Manual modernization bottlenecks
Legacy technical debt
Quality gates

Architecture

CBA's Lumos is an internal modernization platform that combines AI agents with deterministic engineering engines. Engineers use Lumos to analyze application estates, reconstruct documentation, assess cloud readiness, transform legacy code, test changes, and route human review. The platform runs orchestrator and specialist agents with Strands and AgentCore runtime, containers on ECS/Fargate, MCP/OpenSearch for tool and context access, deterministic code analyzers and OpenRewrite for factual transformations, Q Developer/Kiro CLI for repair, evaluation agents and continuous compliance agents for reliability, and human-in-the-loop pull-request review.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  lumos-portal[Lumos portal] --> orchestrator-agent[Orchestrator agent]
  orchestrator-agent --> analysis-accelerators[Analysis accelerators]
  analysis-accelerators --> opensearch-context[OpenSearch context]
  opensearch-context --> mcp-server[MCP server]
  mcp-server --> agent-runtime[Agent runtime]
  agent-runtime --> orchestrator-agent
  orchestrator-agent --> transformation-accelerators[Transformation accelerators]
  transformation-accelerators --> build-validation[Build validation]
  build-validation --> evaluation-agents[Evaluation agents]
  evaluation-agents --> continuous-compliance-agents[Continuous compliance agents]
  continuous-compliance-agents --> human-review[Human review]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Lumos portal`	Engineer-facing modernization workflow entry point.	`Orchestrator agent`
`Orchestrator agent`	Coordinates specialist modernization agents and tools.	`Lumos portal`, `Analysis accelerators`, `Transformation accelerators`, `Evaluation agents`
`Analysis accelerators`	Static code analyzers and documentation accelerators that create factual baselines.	`Orchestrator agent`, `OpenSearch context`
`OpenSearch context`	Context and retrieval layer used by agents and MCP tools.	`Analysis accelerators`, `MCP server`
`MCP server`	Tool interface for agents and modernization services.	`OpenSearch context`, `Agent runtime`
`Agent runtime`	AgentCore/Strands runtime hosted on ECS/Fargate.	`MCP server`, `Orchestrator agent`
`Transformation accelerators`	OpenRewrite and Q Developer/Kiro-assisted code transformation path.	`Orchestrator agent`, `Build validation`
`Build validation`	Compilation, testing, and failure feedback for transformed applications.	`Transformation accelerators`, `Evaluation agents`
`Evaluation agents`	Review generated code and documents for reliability and quality.	`Build validation`, `Continuous compliance agents`
`Continuous compliance agents`	Check generated artifacts against security and compliance expectations.	`Evaluation agents`, `Human review`
`Human review`	Engineer review and approval of agent-produced pull requests.	`Continuous compliance agents`

Data flow

A migration engineer starts an application workflow in Lumos. Deterministic analyzers generate facts such as sequence and class diagrams; AI agents reason over analysis, documentation, cloud readiness, and transformation steps; OpenRewrite attempts deterministic code upgrades; Q Developer repairs failed builds; evaluation and compliance agents review generated code/documents; and a human engineer reviews the final pull request.

3 supporting quotes

“So when we started this CBA journey, it was we started as a generative AI one, and then we leveraged deterministic engines like a static code analyzer”transcript, stated

“from code analysis to the cloud readiness. And we leveraged for the code transformation we use, still, open rewrite, which is a deterministic part of it and then we use Q, which is now being called as keto CLI, which you'll be talking about where it reduced the AI agents to expand and then show”transcript, stated

“There's built in validation so that cybersecurity rules are enforced. We don't want to run our EC2 to be internet facing. So it stops you from doing that.”transcript, implied

Why this architecture

CBA combines deterministic engines with agents because modernization needs facts, repeatable transformations, and compliance evidence, not just generated prose or code. Static analysis and OpenRewrite provide grounded baselines, AI agents fill gaps and repair failures, evaluation agents add reliability, and humans remain in the approval loop for enterprise migration risk.

3 supporting quotes

“So the deterministic engine provides the facts. The AI engine provides intelligence to the facts so that it increases the accuracy or it increases the reliability and auditability of the change that is going to be done as part of the agents.”transcript, stated

“So one challenge which we faced is like how do we ensure that the reliability is brought into the picture?”transcript, implied

“We want to absolutely make sure in this case that there are humans in the loop that does those reviews.”transcript, stated

Models used: Amazon Q Developer · Kiro CLI · AI agents

Scale

CBA moved from about 10 applications per year to 20-30 applications per quarter.
“So, our baseline before we started our AI journey to assist us was about 10 applications a year. Where we ended up was about 20 to 30 applications per quarter.”transcript, implied
Average transformation time had previously been one to two years.
“I think based upon the market research from Gartner, McKenzie and ISG, about 70% of the workloads are still in on-prem with a code written about 20 plus years ago and an average transformation time takes from one to two years approximately. In reality, this is the reality we are operating in.”transcript, stated

Alternatives considered (roads not taken)

Pure generative-AI modernization

Rejected because: The team added deterministic engines and evaluation agents to make results reliable.

“So when we started this CBA journey, it was we started as a generative AI one, and then we leveraged deterministic engines”transcript, stated

Deterministic OpenRewrite alone

Rejected because: OpenRewrite could fail or produce poor transformation quality, requiring agent repair.

“the quality, it was poor, it failed. So at the back of this attempt here, we had to build failure, it didn't work.”transcript, stated

Patterns

`multi-agent-orchestration` (modernization)

Lumos orchestrates application analysis, design, transformation, testing, deployment, and operations.

“and the punchline of today's conversation is going to be that we build a multi-agent tool to help our engineers accelerate”transcript, stated

`human-in-the-loop-gate` (governance)

The modernization process keeps validation gates for security, compliance, and quality.

“), CBA increased their modernization velocity from 10 applications per year to 20-30 applications per quarter, while maintaining security, compliance, and quality standards through human-in-the-loop validation and multi-agent review processes.”summary, stated

Tradeoffs

Combine deterministic engines with AI agents for modernization reliability.

Chose Static analyzers, OpenRewrite, evaluation agents, and continuous compliance agents alongside generative agents over A pure generative-agent modernization pipeline.

Rationale: CBA needed factual baselines, evaluation, and compliance checks to make generated code and documents reliable enough for enterprise migration.

“So when we started this CBA journey, it was we started as a generative AI one, and then we leveraged deterministic engines like a static code analyzer”transcript, stated

“So one challenge which we faced is like how do we ensure that the reliability is brought into the picture? So that is where the deterministic engine and that's where the evaluation agent came into the picture”transcript, stated

How to make generated modernization artifacts reliable.

Chose deterministic engines plus evaluation/compliance agents over pure generative modernization.

Rationale: Static facts, deterministic transforms, and continuous checks reduce the risk of agent-generated code and documentation.

“So that is where the deterministic engine and that's where the evaluation agent came into the picture”transcript, stated

Gotchas (what bit them)

Legacy modernization required documentation archaeology before agents could reason about applications.

Root cause: Application knowledge lived in scattered, incomplete documentation and often lacked a current SME.

Resolution: Lumos added analysis and documentation accelerators to reconstruct application baselines before transformation.

“So there was a lot of documentation archeology to go and find out all the various pieces of documentation across the organization and then piece together a timeline and you'll find missing pieces.”transcript, stated

Pure deterministic code transformation produced poor-quality builds in the modernization loop.

Root cause: OpenRewrite alone could not complete all version-upgrade fixes successfully.

Resolution: The orchestrator brought in Q Developer after OpenRewrite failed, iterated to a successful build, then raised a pull request for human review.

“try to convert that code from all the version of Java to a newer version of Java and you'll see the quality, it was poor, it failed. So at the back of this attempt here, we had to build failure”transcript, stated

Evaluation

CBA measured modernization velocity and transformation time.

Metrics: applications per year · applications per quarter · transformation time

“about 20 plus years ago and an average transformation time takes from one to two years approximately.”transcript, stated

Outcomes

The summary reports velocity moving from 10 apps/year to 20-30 apps/quarter.

The platform supports end-to-end modernization lifecycle orchestration.