How Kloia’s AI-DLC Delivered a .NET Modernization Blueprint on AWS in 4 Weeks

In this post, we describe how Amazon Web Services (AWS) and Kloia, an AWS Premier Tier Services Partner, compressed a three-to-six months discovery and assessment cycle into four weeks for a UK-regulated financial institution, delivering a board-ready modernization blueprint on AWS. The engagement scope was discovery and AI-driven analysis using Claude Code via Amazon Bedrock combined with senior architect validation.

The customer

The customer is a UK-based wealth management platform operating under Financial Conduct Authority (FCA) supervision, managing over £26 billion in assets. The platform serves a portfolio of advisory firms with an end-to-end solution covering financial planning, investment management, and compliance. Built over two decades, the platform had grown into a substantial legacy estate spanning approximately 25 named systems, more than 200 deployable components, and over 1.7 million lines of legacy ASP.NET 4.7/4.8 code across roughly 30 production Microsoft SQL Server databases.

The challenge

The financial institution faced three challenges that made modernization urgent:

1. Legacy platforms capping productivity and growth: the monolithic architecture and tightly coupled data layer made it hard to release new features, onboard advisory firms, and respond to market demands.
2. Current technology unable to support 2030 ambitions: the institution’s roadmap required a unified, cloud-native, AI-enabled platform by 2027 to meet 2030 ambitions; the existing .NET Framework estate could not serve as its foundation.
3. Previous modernization attempts stalled: an earlier engagement projected a two-year modernization roadmap, drained executive sponsorship, and left the board without evidence-based confidence to approve an eight-figure programme.

At the heart of the technical challenge was decomposing an approximately 1.7-million-line legacy monolithic codebase into approximately 15 medium-grained domain services. The largest embedded blocker was the data-layer coupling: 6 SQL Server databases held 87 percent of all database objects and approximately 1,400 stored procedures.

How Kloia partnered with the financial institution

Following an Executive Briefing Center (EBC) session with the institution’s Senior Leadership Team, AWS introduced Kloia to deliver a complete modernization blueprint on AWS for the customer at an accelerated pace, in weeks instead of months.

Kloia has deep expertise in modernizing legacy Microsoft Windows applications to cloud-native architectures on AWS, and has developed an AI-driven methodology that uses agentic AI tools to perform primary analysis while senior architects validate and synthesize.

Kloia’s four-phase AI-driven methodology

Kloia’s approach treats discovery as a knowledge-base construction problem. This is the discovery and assessment engagement: four weeks that produce a board-ready blueprint, not a running system. The AI-Driven Development Lifecycle (AI-DLC) pipeline accumulates a persistent, evidence-linked knowledge base, and every deliverable is projected from that base (Figure 1).

Figure 1: The three classes of source material that feed the persistent, evidence-linked knowledge base, the foundation of every AI-DLC deliverable. 

Kloia’s approach inverts the traditional discovery model. Instead of weeks of architect-led workshops and manual code walkthroughs, the AI pipeline performs the bulk of the analysis. Senior architects validate, refine, and own the synthesis. Subject matter experts (SMEs) are engaged where necessary to validate and expand on the application’s intent, features, and functionality. The AI pipeline forms an initial opinion of the codebase, which SMEs validate during focused engagement sessions.

Phase 1: Discovery and automated analysis (Week 1)

The AI pipeline ingests source repositories, database scripts, architecture documentation, and CI/CD configuration. Static analysis builds a dependency graph, scores complexity hotspots, surfaces compatibility risks against modern .NET runtime targets, and catalogs integrations.

Blocker categories are catalogued in repeatable form: Windows-specific APIs, .NET Framework version gaps, IIS-bound hosting, binary serialization, COM interop, and legacy reporting libraries.

Phase 1 closes with an inventory, dependency map, and complexity heat map that target SME validation sessions in the following week.

Phase 2: Domain validation and decomposition (Week 2)

Kloia’s architects run targeted validation sessions against the AI-generated findings. SMEs confirm what the AI got right, flag what it inferred, and resolve ambiguities in business logic that pure code analysis cannot answer.

In parallel, the AI pipeline produces a candidate domain decomposition aligned to the customer’s target domain model; architects refine boundaries and select AWS service categories per layer.

Phase 2 closes with documenting validated coverage, risk scoring, and initial decomposition design.

Phase 3: Target architecture and splitting (Week 3)

Against the validated decomposition, Kloia’s architects select AWS service categories per layer (compute, data, eventing, observability, security), design the cutover mechanism of tranches, and lock service boundaries.

The AI pipeline proposes ways to map legacy components onto new services, and flags cases where an AWS managed service can fully replace custom-built legacy infrastructure. All the design work like mappings, boundaries, and cutover mechanics feeds into Phase 4’s blueprint.

Phase 3 closes with the target AWS architecture and the per-domain splitting strategy.

Phase 4: Roadmap, cost, and execution plan (Week 4)

The team pulls together the roadmap, per-slice modernization plans, risk register, execution model, and fixed-cost / fixed-time proposal into a board-ready blueprint. AI-assisted authoring drafts the narrative against the validated evidence base; architects own the framing, trade-offs, and recommendations.

Playback sessions land the recommendations and surface any remaining questions. Feedback into Claude’s knowledge base lets the AI pipeline refine the proposal without manual edits.

Phase 4 closes the discovery and assessment engagement.

Building the target architectures

The blueprint’s target architecture sits across two orthogonal axes: a domain-level decomposition of the monolithic estate into approximately 15 medium-grained services, and an infrastructure-level implementation design on AWS managed services. Domain decides what runs where; infrastructure decides how.

Domain-level architecture

Decomposing the monolithic estate into a manageable target service topology is the core of the modernization. The target state settled on approximately 15 medium-grained domain services rather than 20-to-30 fine-grained microservices, evidence-based sizing that avoids the distributed-monolith failure mode. Services split across four modernization archetypes and ten cross-cutting programme outcomes (Figure 2).

Figure 2: Target domain-level architecture: decomposition, archetype mix, and 10 cross-cutting programme outcomes. 

One owned data store per capability. Every domain service completing its Phase B owned-store rewrite lands on a dedicated Amazon Aurora PostgreSQL cluster. Amazon RDS for SQL Server is retained during transition for the residual legacy estate, with each table retiring when its owning slice completes Phase B.

Property-driven rather than style-driven decomposition. Sizing was driven by boundary evidence in the codebase, not by an aesthetic preference for many small services.

Infrastructure-level architecture

The reference architecture in Figure 3 shows the 15 domain services on managed AWS building blocks across edge, compute, data, messaging, observability, and security tiers, with the residual legacy estate accessible through a dedicated bridge.

Figure 3: Target AWS reference architecture for the modernized platform. 

At the edge, Amazon Route 53 fronts Amazon CloudFront with AWS Web Applicaton Firewall (WAF) and AWS Shield protecting the regulated surface. Domain services run on Amazon Elastic Kubernetes Service (Amazon EKS) with AWS Fargate. AWS Lambda handles event-driven glue, and AWS Step Functions orchestrates saga-style workflows. Agentic AI consumes Amazon Bedrock through a thin abstraction layer.

The data tier replaces the coupled SQL Server estate with per-capability Amazon Aurora PostgreSQL clusters. Amazon DynamoDB carries audit trails; Amazon Simple Storage Service (Amazon S3) holds FCA-regulated records under Object Lock with AWS Key Management Service (AWS KMS) encryption. Asynchronous messaging runs on Amazon Simple Queue Service (Amazon SQS), Amazon Simple Notification Service (SNS), and Amazon EventBridge; Amazon Managed Streaming for Apache Kafka (Amazon MSK) handles change-data-capture and Amazon OpenSearch Service is used for search functionality.

Security layers AWS Identity and Access Management (AWS IAM), AWS KMS for key rotation, Amazon GuardDuty for threat detection, and AWS CloudTrail for the regulatory audit trail. Operations run on Amazon CloudWatch, AWS X-Ray, AWS Backup, and AWS Systems Manager. The residual legacy estate stays reachable via AWS Database Migration Service (AWS DMS) and AWS Direct Connect.

Key architectural decisions

No two-way data synchronization during production data migration: Bidirectional sync would reproduce the coupling issues the programme intends to remove. Strangler writes are one-way only; dual writes are permitted only as a documented fallback with a named removal date.

Tranched cutovers rather than big-bang: Weekend cutovers with pilot firms concentrate risk into a manageable window per tranche and preserve the option to halt mid-programme.

Identity stays external: The customer’s existing identity provider remains the source of truth; AWS IAM Identity Center federates from it for engineer access.

Overcoming the hardest problem: preventing AI fabrication

Agentic AI analysis reliably surfaced the codebase inventory, dependency graph, and compatibility blockers. The subtler failure mode: during synthesis, the AI produced plausible identifiers, integration names, and system references that were inferences rather than observations, unverifiable without a manual roundtrip to source.

The first approach was prompt-level instruction to use only source-grounded identifiers. It reduced frequency but did not eliminate the fabrication.

The working solution adds a grep-roundtrip verification step (Figure 4). Before any named identifier or integration reference appears in a final deliverable, it is checked against the ingested source. References that cannot be grounded are replaced with a qualified description or flagged for SME confirmation. This step added roughly two hours to Phase 3 and eliminated fabricated identifiers entirely.

Figure 4: The verification loop that prevents AI-drafted references from entering the deliverable unverified. 

Deliverables

The blueprint is a document deliverable. The customer received a comprehensive document package organized across five sections.

Results

At the end of four weeks, the financial institution received a board-ready modernization blueprint anchored in real codebase evidence, delivered with a fixed-time commercial position the board could underwrite.

3-6 months compressed to 4 weeks: AI-driven analysis delivered in four weeks what traditional discovery takes months to produce.

90 percent reduction in modernization costs: the combination of AI-driven analysis and focused architect validation dramatically reduced the professional services investment required for the discovery phase.

Evidence-based confidence: every recommendation traces to a specific repository path or schema artifact. No assumptions, no guesswork.

SME time measured in hours, not weeks: Focused validation sessions replaced weeks of discovery workshops.

Following the blueprint, Kloia completed a Proof of Value in four weeks using Claude Code via Amazon Bedrock with an AI-Driven Development Lifecycle (AI-DLC) workflow. Full estate modernization is now projected at six to eight months, versus the two-year timeline originally estimated.

Conclusion

Kloia’s AI-driven methodology closes the traditional trade-off between speed and rigour in modernization assessment. Organizations with substantial .NET estates can move from uncertainty to an evidence-based, board-ready investment decision in weeks rather than months. Execution is scoped separately once the board decides to fund it.

“The AI-driven approach fundamentally changed the economics of our modernization programme. What previously required months of workshops and manual analysis was delivered in four weeks with greater precision and traceability than we had seen from traditional methods.” — CTO, UK Financial Institution

If you have legacy .NET applications and are evaluating modernization, contact Kloia for an assessment on accelerating your journey to cloud-native on AWS.

AWS can help you modernize your most important applications in the cloud. Join the millions of AWS customers that trust us to migrate and modernize critical workloads. To learn more, visit Windows on AWS.

Get started. Ready to see whether AI-driven discovery can compress your own modernization timeline? Explore the resources below and reach out to kloia:

• AWS for Microsoft workloads. AWS’s landing page for running and modernizing .NET, SQL Server, and Windows workloads on AWS.
• Kloia: AI-DLC solution. The AI-Driven Development Lifecycle methodology behind the four-week discovery engagement described in this blog.
• Kloia: .NET Modernization on AWS Transform. Kloia’s productized .NET modernization approach, including AWS Transform integration.