The 74/28 Gap and What It Means
Seventy-four percent of insurers acknowledge that legacy systems are actively blocking growth. Only 28% have a plan to act [1]. That’s the 74/28 gap.
The gap is not inertia. It is a confidence problem. Carriers cannot credibly plan transformation for systems they do not fully understand. The decision logic is buried in decades of undocumented code, and the developers who built it are approaching retirement.
The consequence of attempting transformation without that confidence is documented across the industry. Large-scale core system transformations fail more than 70% of the time. Nearly 25% become full write-offs [2]. These are not programs that ran over budget. They are programs that consumed years of capacity and delivered nothing deployable.
More than half of US insurers spend between 51% and 75% of their IT budget keeping existing systems operational [3]. That maintenance cost compounds annually. Every dollar spent sustaining legacy architecture is a dollar unavailable for the transformation designed to replace it.
This article covers what is inside a typical carrier’s legacy stack, why programs fail at the rates they do, what the carriers that succeed do structurally differently, and how Gen AI-powered codebase analysis changes the execution model for each stage.
What’s Running Inside a Typical Carrier and Why It’s So Hard to Touch
Legacy insurance systems in production today are not a single platform with known boundaries. They are a collection of interdependent systems, each carrying decades of accumulated product decisions, regulatory adjustments, and operational workarounds, most of which were never designed to work together.
Policy Administration System (PAS)
The PAS is the operational core: quote, bind, issuance, endorsements, renewals, cancellations. It is also where embedded logic is densest. Rating algorithms, bureau rate integrations, state filing dependencies, and product-specific exception handling have been layered over the years without systematic documentation. Many carriers run more than one PAS. M&A-driven accumulation means a significant proportion of L&A carriers operate four or more simultaneously, each with its own data model and business rule implementation.
For deeper guidance on PAS transformation specifically, see Policy Administration System Modernization: A 2026 Guide for Insurance IT Teams Ready to Act.
Claims
Claims systems carry the highest operational load and the most direct customer impact. Adjudication logic (coverage determination, reserve calculations, subrogation rules, fraud indicators) is embedded across workflows that have been modified repeatedly without documentation. Getting this wrong during transformation means claims paid incorrectly, coverage disputes, and regulatory exposure. There is no tolerance for behavior drift here.
Underwriting
Underwriting is where rule accumulation is most dangerous. Hundreds of interdependent modules govern risk selection and pricing. A single product change can trigger months of regression testing across lines of business, not because the change is complex, but because the dependency map is unknown. This is the system type most likely to contain logic no one can explain, but everyone relies on.
Billing, CRM, and BI/Analytics
These systems compound the challenge rather than introduce separate categories of risk. Billing fragmentation erodes policy persistence. CRM data is split across lines of business, producing a customer view that exists in strategy documents but not in production. Batch-based BI architectures cannot support real-time AI applications, dynamic pricing, or fraud detection at claim intake. The gap originates in the data layer, and the data layer originates in these systems.
Insurance core systems, specifically PAS, claims, billing, and underwriting, are among the most tightly coupled architectures in any enterprise environment. Changes in one cascade across the others.
A billing change affecting premium collection touches PAS policy status, claims payment eligibility, and underwriting renewal triggers simultaneously. That interdependency is what makes isolated modernization operationally dangerous and what makes conventional transformation approaches so frequently inadequate.
The M&A Problem: Inheriting Systems You Did Not Build
Carriers that grew through acquisition frequently run four or more PAS platforms simultaneously, each with its own data model, business rule implementation, and integration assumptions. They were patched together after each deal closed. The integrations between them are undocumented.
The consequence is specific. A billing change in one acquired system can trigger policy status errors in another because that dependency was never designed, only patched. Such a modernization program discovers this through a production incident, not a design review.
You cannot replace what you cannot map across systems you did not build. Carriers that successfully modernize after M&A-heavy growth produce a cross-system dependency and logic map before selecting any transformation path. Without it, the program modernizes the visible layer while the inherited architecture underneath remains intact.
Why Insurance Modernization Programs Fail at 70%
The 70% failure rate is not primarily a technology selection problem or a budget problem. It is a structural problem, and it has the same root cause across most of the programs that collapse: carriers attempt transformation without an accurate picture of what the systems under transformation actually contain.
The Embedded Logic Problem
Insurance legacy systems carry decades of accumulated business decisions, such as underwriting rules, pricing edge cases, or adjudication exceptions. Almost none of it is systematically documented.
A SimpleSolve practitioner account [4] describes a P&C carrier engagement that began as a rules rationalization exercise and became a full rules discovery exercise: thousands of interdependent conditions uncovered, vintage logic for terminated products still firing, analytics misrepresenting operational reality because the actual decision logic was buried in layers the reporting layer had never reached.
When a carrier migrates to a new platform, the undocumented rules do not migrate with it. They get missed, get rebuilt incorrectly, or keep executing from the legacy layer underneath the new one. “We moved to Platform Y” frequently means the actual decision logic still lives in Platform X.
Five Forces That Compound the Risk
The embedded logic problem does not operate in isolation. Five structural forces make failure more likely and its consequences more severe with each passing year.
| Force | What It Creates |
| Maintenance cost spiral | IT budget consumed by run-the-business activities crowds out the transformation investment designed to reduce it. The spiral self-reinforces. |
| Product velocity gap | New insurance products take 12–18 months to launch. Insurtechs operating on modern infrastructure ship in weeks. The constraint is architectural: underwriting rules are hardcoded, rating engines are tightly coupled to policy systems. |
| [UPDATED] AI architecture blockage | Legacy systems cannot provide the real-time data access, unified data models, or open APIs that Gen AI applications require. Nearly half of P&C insurers identify data quality and limited accessibility as the primary barrier to analytics adoption. The tooling is available. The infrastructure is not. |
| Regulatory exposure | NAIC Data Security Model Law is active in 23+ states. The NAIC AI Model Bulletin is adopted in 24 states, with market conduct exams underway. Undocumented logic creates a specific regulatory risk: a carrier cannot explain a decision it cannot trace. |
| Workforce retirement | The knowledge embedded in legacy systems lives in two places: the code and the developers who built it. Both are leaving simultaneously. Unlike technical debt, knowledge loss is discontinuous. A retirement is a hard cutoff, not a degradation curve. |
The Knowledge-Transfer Crisis: What Retirements Cost
P&C insurance is projected to lose nearly half its workforce to retirement within five years [5]. Ninety-three percent of insurance CxOs rate knowledge loss as mission-critical or a significant concern [5].
The deeper issue is what that workforce carries. The exception logic, adjudication rules, and rating algorithms that the business runs on were built by people, not written into specifications. When those people retire, that knowledge ends on a specific date. The system keeps running. The rationale behind its behavior does not.
Any modernization program that starts after those retirements faces the same problem: a replacement platform cannot replicate behavior no one can explain, and a QA process cannot validate parity against a baseline that was never captured. Manual documentation exercises do not close this gap. The developers who know the most are the least available to document it.
Every year a carrier defers this, the window narrows.
The Stakeholder Paralysis That Follows
Structural causes do not fail programs on their own. They create the conditions for the organizational dynamics that stall them. Only 52% of health insurers report complete alignment between business and IT on modernization priorities [3]. Finance, legal, and compliance functions resist when they cannot get clear answers about what the legacy system does and what the transformation guarantees to preserve.
Ninety-four percent of US insurers had at least one strategic technology program delayed or canceled for budget reasons in the last 12 months [3]. “Budget reasons” frequently mean the program could not demonstrate what it was transforming or what it would deliver, which is a governance visibility problem, not a funding problem.
The structural failure pattern, in sequence:
- Embedded business logic is not mapped before transformation begins. The program rebuilds behavior that it has not documented
- M&A-driven PAS accumulation means multiple systems with incompatible data models that no single replacement platform resolves cleanly
- Stakeholder resistance hardens when no one can answer: what changes, what is preserved, and how is that validated before go-live
- The replacement or wrapping approach presupposes knowledge of the system that the carrier does not have, and the program discovers this after commitment, not before
If any of this maps to your environment, the first step is not choosing a platform. It is understanding what is in your codebase. Legacyleap’s $0 Modernization Assessment produces the dependency map, embedded logic summary, risk indicators, and modernization readiness view your program needs before any architecture decision is made.
The Three-Path Decision and Why Two Paths Keep Failing
Every carrier evaluating modernization faces the same structural choice. The decision looks strategic. In practice, it is determined by what the carrier knows about its own systems, and what it does not.
- Replace (migrating to Guidewire, Duck Creek, or Majesco) works when the carrier can fully specify what the new system must do. For carriers with undocumented logic across multiple PAS platforms, that specification is precisely what was never written. This is where the 70% failure rate is concentrated.
- Wrap uses an API-layer, and Strangler Fig approaches that build modern interfaces above legacy systems without changing what those systems do. Embedded logic keeps executing underneath. Gen AI readiness and data consolidation are not achievable through interface modernization alone. Wrapping defers the problem.
- Comprehend and Modernize starts with systematic codebase analysis to extract undocumented business rules, dependency maps, and embedded logic before any transformation decision is made. Transformation, governance, and validation are then treated as inseparable phases of a single program that is governed, diff-reviewed, and parity-validated throughout.
| Path | Timeline | Cost Range | Core Risk | Best Fit |
| Replace (Guidewire, Duck Creek, Majesco) | 12–24 months | $500K–$2M+ | Undocumented logic gets missed or rebuilt incorrectly; specification work was never done | Carriers with fully documented legacy behavior and clean system boundaries |
| Wrap (API layer / Strangler Fig) | 6–12 months per phase | Moderate | Legacy logic keeps executing underneath; Gen AI readiness not achieved | Carriers extending system life while planning full transformation |
| Comprehend and Modernize | Phased | Scales to program scope | Requires codebase-level assessment before execution begins | Carriers with undocumented logic, M&A-accumulated systems, or retiring developer knowledge |
How Legacyleap’s Gen AI Agents Execute Insurance Modernization
Legacyleap is a Gen AI-powered modernization platform built on multi-agent orchestration, headquartered in Texas with over 150 production-grade assessments completed. For insurance carriers, the platform addresses the specific failure pattern documented above: it starts with codebase-level comprehension and runs through a governed transformation lifecycle before any code moves to production.
The five-agent system executes in coordinated sequence. No agent acts autonomously. Every transformation decision affecting product behavior, architectural direction, or release readiness is subject to human review and approval before proceeding.
- Assessment Agent maps systems, dependencies, and legacy risk areas across the full codebase. For insurance environments, this means identifying tightly coupled dependencies across PAS, claims, billing, and underwriting, and flagging the transformation sequences where risk is concentrated.
- Documentation Agent reconstructs missing documentation, module boundaries, and embedded business rules, including the undocumented underwriting logic, rating algorithms, and adjudication exceptions that replacement programs consistently miss.
- Recommendation Agent evaluates modernization paths and target architecture options based on complexity, effort, and feasibility. The output is a sequenced blueprint with effort ranges and migration targets, not a generic roadmap.
- Modernization Agent executes governed code transformations. All changes are delivered as diff-based pull requests. There are no autonomous merges and no deployments without engineering review. The transformation record is complete and auditable.
- QA Agent validates functional parity, runs regression checks, and generates test suites. Parity is confirmed before deployment, not after go-live, when a missed adjudication rule becomes a production incident.
The governance model built across this sequence directly addresses the stakeholder resistance that stalls most programs. Finance, legal, and compliance can see exactly what changed, why it changed, and what was validated before it moved. CodeShield scans every block of Gen AI-generated code for vulnerabilities. Audit logs capture every agent action across the transformation lifecycle. The program is traceable, which means it is defensible in regulatory examinations and in board-level reviews.
For carriers evaluating the platform vs. services decision or planning a phased, incremental modernization across a complex multi-system environment, those decisions are better made with a complete codebase picture than without one.
Insurance Case Study: VB6 Administration Platform to .NET
A major insurance administration provider was running a VB6 core system: 327 files, 259 forms, 242,613 COM component calls, all incompatible with modern .NET and with no automated testing framework in place.
Legacyleap’s Gen AI agents produced a full dependency map across all 242,613 COM calls, replaced every one with native .NET alternatives, eliminated the ADODB layer, and built a custom automated UI testing framework covering all 259 forms. That testing framework was not in the original scope; it was the infrastructure required to prove 100% functional parity before deployment.
Results: 50% faster development cycles. Zero legacy COM calls remaining. Five EXEs and ten DLLs consolidated into a clean, maintainable architecture. A permanent automated testing capability deployed.
Legacyleap platform results across insurance engagements:
- 50-70% acceleration in modernization efforts compared to manual approaches
- 100% functional parity validated before deployment, not after
- Supported stacks: VB6/.NET Framework to .NET 6/8; Java EE/EJB/Struts to Spring Boot; AngularJS to Angular/React; SSIS/Ab Initio to Azure Data Factory/Databricks/Spark
What Successful Modernization Delivers
Carriers that complete core modernization report a 15–25% reduction in operating expenses within three years of go-live [2]. The programs that reach that outcome started with a structured assessment of what they actually had, not a vendor evaluation.
[NEW] The 28% of carriers with a comprehensive modernization plan are not more courageous than the 74% who acknowledge the problem. They have more information.
Claim your $0 Modernization Assessment. Legacyleap produces the codebase-level view that modernization programs require before any architecture decision is made: dependency and module map, embedded logic summary, risk indicators, effort and timeline ranges, recommended migration targets, and a structured modernization readiness view across your insurance stack. It runs entirely inside your infrastructure. No source code leaves your environment.
Book a Demo for carriers who want to see the five-agent execution model in a live environment before any code is shared.
FAQs
The only reliable approach is extracting behavioral logic directly from the codebase rather than from documentation or developer interviews. Documentation is incomplete by definition, and the developers with the deepest knowledge are typically closest to retirement. Systematic codebase analysis maps what the system actually executes under real conditions, including edge cases and override paths. Parity validation against that baseline before deployment is what separates a migration that closes from one that runs indefinitely in parallel.
M&A-accumulated systems require a cross-system dependency map before any transformation path is selected. Incompatible data models are rarely documented. They were patched at integration points after each acquisition and never rationalized. A billing change in one acquired system can trigger policy status errors in another because those dependencies are undocumented. Transformation sequencing must be built around a complete map of how inherited systems interact, not around platform replacement timelines.
Platform selection presupposes the carrier can specify what the new system must do, which requires knowing what the legacy system currently does. Before evaluating any replacement platform, carriers need a complete picture of embedded business rules across PAS, claims, and underwriting; a dependency map across core systems; and an inventory of undocumented exception logic that the new platform must replicate. Without that baseline, specification gaps surface after commitment, not before.
Parity validation requires a behavioral baseline captured from the legacy system before transformation begins, test coverage across all functional paths including exception handling, and automated regression testing run against both systems before cutover. The failure mode is a QA process that validates what the new system does rather than whether it matches what the old system did. Adjudication rules and underwriting exceptions that differ between legacy and modern rarely surface in functional testing. They surface in production.
Workforce retirement is irreversible in a way that technical debt is not. When a senior developer retires, the undocumented exception logic they maintained ends on a specific date. The system keeps running; the rationale behind its behavior does not transfer. The only mechanism that reliably captures this knowledge is systematic extraction from the codebase itself, analyzing what the code actually executes under real conditions, not what documentation says it should do.
References
[1] HFS Research / Sutherland Global — “Redefining Legacy Transformation in Insurance: Insights for 2025 and Beyond.” 74% of insurers acknowledge legacy systems hinder business growth; 28% have a comprehensive modernization plan. https://www.sutherlandglobal.com/insights/blog/legacy-transformation-in-insurance
[2] McKinsey / BCG via Carrier Management, March 2026 — “How Modern Is ‘Modern Enough’ for Insurance Applications?” Large-scale core system transformations fail 70%+ of the time; nearly 25% become full write-offs. McKinsey: carriers completing modernization report 15-25% reduction in operating expenses within three years of go-live. IT cost per policy (-41%) and operations productivity (+40%) attributed to McKinsey; original report not directly accessed. https://www.carriermanagement.com/features/2026/03/04/285258.htm
[3] West Monroe Partners — “Insurance Modernization Under Pressure” (October 2025) and “New Tech, Old Habits: Why Modernization Stalls With Health Insurers” (March 2026). 300 US insurance executives surveyed. 51-75% of IT budgets spent on run-the-business activities; 52% of health insurers report complete business-IT alignment on modernization priorities; 94% had at least one strategic technology program delayed or canceled for budget reasons in the last 12 months. https://www.westmonroe.com/insights/from-legacy-systems-to-strategic-advantage and https://www.westmonroe.com/insights/modernization-with-health-insurers
[4] SimpleSolve, March 2026 — “Insurance Palimpsest: Why Layered Processes Hide the Real System.” Practitioner account of a P&C carrier rules discovery engagement. Ovum attribution (27% PAS implementation success rate) cited through SimpleSolve; original Ovum report not directly accessed. https://www.simplesolve.com/blog/why-layered-insurance-processes-hide-the-real-system
[5] Insurance Thought Leadership / APQC, December 2025 — “Insurance’s Silver Tsunami Knowledge Crisis.” P&C insurance workforce retirement: nearly half of workforce projected to retire within five years. 93% of insurance CxOs rate knowledge loss as mission-critical or significant concern. https://www.insurancethoughtleadership.com/ai-machine-learning/insurances-silver-tsunami-knowledge-crisis
