Project Overview
A specialty property and casualty insurance carrier operating across North America runs its core policy administration, underwriting, and claims platforms on a .NET Framework codebase that has accumulated over more than fifteen years. The estate consists of roughly forty applications totaling several million lines of C# and VB.NET, backed by a SQL Server database tier with hundreds of stored procedures encoding business rules that exist nowhere else in documented form. The platforms run in two on-premise data centers under a vendor support contract whose renewal cost has roughly doubled over the last three renewal cycles.
The carrier's IT leadership had committed to a cloud-native target state on AWS, with a particular interest in qualifying the program for AWS Migration Acceleration Program funding under the Windows variant of MAP. The constraint set was familiar. Regulatory obligations require that customer data, including personally identifiable information and protected health information for the carrier's specialty health lines, never leave the carrier's controlled environment, even during assessment. The internal architecture team had attempted a manual current-state assessment in the previous year and had produced documentation that the team itself acknowledged was incomplete, internally inconsistent, and already outdated relative to the codebase.
This engagement is illustrative of the modernization pattern ArchWeaver is purpose-built for: a regulated, mid-to-large enterprise with a substantial .NET Framework estate, a hyperscaler-funded modernization mandate, and an internal architecture team that needs an analytical foundation strong enough to defend the program through a five-year strategic plan.
The Challenge
The carrier's enterprise architecture team faced four problems that compound each other.
Assessment fidelity. The previous manual assessment had documented major application boundaries and surface-level dependencies but had not produced a defensible map of the cross-application data flows or the business rules embedded in the database tier. Roughly thirty percent of the stored procedures in the SQL Server estate were known to encode underwriting and claims logic that the application code referenced but did not duplicate. A modernization plan that did not account for these rules would be incomplete in ways that would only surface during delivery.
Target state defensibility. The internal team had a working hypothesis about the target state (containerized microservices on AWS with managed Aurora as the data tier) but had not been able to defend the recommendation at the component level. Without a per-component analysis, the steering committee could not distinguish between components that were genuine candidates for refactoring and components where rehosting was the right answer for the next two to three years pending a deeper rework.
Business case credibility. A finance-led review had pushed back on the program's previous TCO numbers because the assumptions behind them were not traceable. The CFO's office wanted a five-year cost trajectory with current-state and target-state TCO that could be reconciled against actual AWS pricing rather than against rule-of-thumb estimates.
Data sovereignty. Any analysis approach that required uploading the codebase, schema definitions, or architecture documents to a vendor environment was disqualified at the security review stage. Several alternative platforms had been evaluated and ruled out for this reason before ArchWeaver was selected.
The carrier needed an assessment that could produce a graph-model representation of the estate, a per-component 6R recommendation set with supporting rationale, a five-year business case grounded in real cloud pricing, and an implementation roadmap that the AWS partner team could underwrite for MAP funding. All of this had to happen inside the carrier's own infrastructure.
The Solution
ArchWeaver was deployed as containerized microservices inside the carrier's primary data center, behind the same network perimeter as the systems being analyzed. The deployment footprint sat well within the platform's published requirements: 8 cores, 16 GB of RAM, and 100 GB of storage on a virtualized host inside the carrier's enterprise environment. The deployment was complete within a single business day, including the security team's network-isolation validation.
The assessment proceeded in five stages, run sequentially over a two and a half week elapsed timeline.
Ingestion and discovery. The platform connected to the carrier's on-premise GitLab instance, ingested the full .NET Framework codebase across all in-scope applications, accepted Terraform configurations for the existing on-premise infrastructure, and parsed architecture documents the internal team had produced over the prior twelve months. The platform also ingested the SQL Server schema and stored procedure definitions, which let the analysis incorporate the business rules embedded in the data tier rather than treating the database as an opaque dependency.
Current state visualization. The platform rendered an interactive architecture model containing more than 1,200 components and over 4,800 dependencies. Hidden cross-application coupling that the previous manual assessment had missed surfaced at this stage, including a set of shared utility libraries that several supposedly independent applications relied on, and a cluster of integration points to a vendor claims processing system that constrained the order in which the rest of the estate could be decomposed.
6R recommendations. ArchWeaver produced component-level 6R classifications with confidence scores. Refactoring was recommended for the largest cluster of policy administration components, replatforming for the claims processing applications where vendor coupling made refactoring impractical in phase one, and rebuilding for a smaller cluster of legacy reporting applications that were already slated for retirement in the carrier's IT roadmap. The architecture team reviewed the recommendations and accepted more than three quarters of them without modification.
Business case generation. The platform generated a 12-page executive decision report containing current-state TCO derived from the carrier's actual on-premise cost basis, target-state TCO calculated against AWS pricing through the cost calculator API, implementation effort estimates, ROI and IRR analysis, and a five-year cost trajectory across multiple target-state scenarios. The report was used directly in the carrier's quarterly steering committee review without rework.
Implementation roadmap. A phased roadmap was generated with dependency-aware sequencing, organized into four phases over a 24 month delivery horizon. The roadmap was exported in MS Project format and used as the basis for the carrier's MAP for Windows funding application to AWS.
The internal architecture team's role across the engagement was review and contextualization. The carrier did not bring in external consulting headcount for the assessment, which was itself one of the program's success criteria.
Results
The assessment phase compressed from the carrier's previous estimate of four to six months down to two and a half weeks of elapsed calendar time, consistent with ArchWeaver's published 40 to 60 percent compression range. The analytical artifacts produced through the engagement supported the next phase of the carrier's modernization program in three concrete ways.
The MAP for Windows funding application was approved by AWS within the partner program's standard review window, with the platform-generated assessment and roadmap serving as the underwriting artifacts. The partner funding materially offset the carrier's first-year migration cost, which was a precondition for the program's CFO approval.
The five-year TCO analysis surfaced a target-state infrastructure cost reduction in line with ArchWeaver's reported 30 percent average across engagements, with the savings concentrated in the database tier where Aurora replaced a multi-node SQL Server licensing footprint that had been the largest single line item in the on-premise cost basis.
The business case received CFO sign-off in a single review cycle, which the carrier's IT finance team flagged as the most efficient approval cycle for a multi-year IT investment in their recent history. The traceability of the underlying numbers (each TCO figure linked back to a specific component in the graph model) was the factor most cited in the approval discussion.
The carrier's enterprise architecture team has since redeployed ArchWeaver into a continuous assessment posture, where the platform re-ingests the codebase on a quarterly cadence to track architectural drift against the approved target state. This use pattern was not part of the original engagement scope, but emerged once the team recognized that a queryable assessment artifact has ongoing value beyond the initial program approval.
The modernization program is currently in delivery, with phase one execution underway and phase two scoped against the roadmap the platform produced.
