Insurance Software Integration with Legacy Systems: Patterns, Strangler Fig, and the Mid-Tier Carrier Reality in 2026

Why insurance software integration with legacy systems matters in 2026

In my experience working with U.S. P&C carriers between $500M and $5B GWP, every architectural conversation about modernization eventually arrives at the same constraint: “We cannot turn off the legacy system. It runs claims. It runs billing. It has 20 years of policy data and 50-state regulatory carve-outs baked into the code.” That sentence ends every “rip and replace in 12 months” pitch I have ever heard, and it begins every realistic conversation about how mid-tier carriers actually modernize.

Insurance software integration with legacy systems matters because the legacy system is not a problem to be eliminated; it is a constraint to be designed around. Gartner has documented for years that 70-80% of insurance IT budgets go to maintaining legacy systems. That spend is locked in by the regulatory audit trail, the policy data continuity, the customer relationships embedded in the system, and the operational workflows that depend on the legacy system being available 24/7. A carrier that pretends the legacy system can be turned off in 12 months is signing up for a project that will fail at month 13.

I have spent the last 20+ years building integration patterns for European and U.S. insurance carriers. What I tell every Daniel-level architect who asks me how to approach legacy integration: “The integration pattern you pick determines what kind of system you are building. Point-to-point gives you brittleness disguised as speed. ESB gives you middleware lock-in. API gateway gives you a contract surface. Event-driven gives you decoupling at the cost of operational complexity. None of them is wrong by default. All of them are wrong if applied without understanding the carrier’s actual operational reality.”

For mid-tier carriers specifically, insurance software integration with legacy systems is the single most important architectural decision in any modernization program. The decision determines whether the new system can ship in 18-36 months alongside the legacy or whether the project ends up as a 48-month all-or-nothing migration with the typical insurance core platform failure rate. The integration architecture is the difference.

This article is the technical integration deep dive that pairs with our Pillar Main on legacy-to-modern modernization for U.S. carriers in 2026. The Pillar Main covers the strategic decision (Build vs Buy vs Partner, vendor landscape, 5-year TCO); this one is the architectural deep dive on integration patterns, when each fails, and how to sequence migration so the legacy survives long enough to be retired safely.

What is insurance software integration with legacy systems?

Insurance software integration with legacy systems is the architectural and operational practice of connecting modern insurance platforms (PAS, claims systems, underwriting workbenches, billing engines) to existing legacy systems built in earlier technology generations - typically COBOL mainframes, AS/400, early-2000s .NET PAS, or legacy Java enterprise stacks - while maintaining data consistency, regulatory audit trails, and 24/7 operational availability across both old and new systems during the transition period.

The integration is not a one-time data transfer. It is an ongoing architectural commitment that runs from the start of modernization through the legacy retirement years later. During that period, the carrier operates two systems of record that must stay coherent - which is a different problem from a clean cutover, and it requires different patterns than mainstream system integration.

Why insurance integration is different from generic enterprise integration

Insurance integration with legacy systems has four characteristics that distinguish it from generic enterprise integration patterns documented in textbooks:

1. Regulatory continuity requirement. Every policy transaction must be auditable in either or both systems for the regulatory retention period (typically 7 years for most U.S. P&C jurisdictions). The integration cannot drop transactions or lose audit trail during the migration.
2. ACORD standards and industry data models. U.S. P&C insurance runs on ACORD standards - AL3 for P&C, the XML schemas, and the newer ACORD digital standards. The integration must speak ACORD natively or translate to it cleanly for partner connections.
3. Multi-system policy lifecycle. A single policy touches the PAS for issuance, the underwriting workbench for renewal decisions, the claims system for first notice of loss, the billing system for premium collection, and the reinsurance system for ceded reporting. The integration must keep all these systems coherent on a single policy object that lives in different platforms over its lifecycle.
4. State-by-state regulatory data variation. Each U.S. state has slightly different data requirements (additional fields, different formats, regulatory carve-outs). The integration must respect state variation without forcing the carrier to maintain 50 different data pipelines.

The integration spectrum

The next sections cover each pattern indepth.

The legacy reality - 15-30 year old systems still running claims

The legacy reality at most U.S. mid-tier P&C carriers is not what vendor pitch decks describe. It is something closer to this: a 1995-2005 era mainframe or AS/400 system running policy administration, with 25 years of business rule changes hardcoded into COBOL or RPG; a 2005-2015 era .NET or Java claims system that was supposed to replace part of the mainframe but ended up running alongside it; a billing system from a different era again; an underwriting workbench that someone built in Access in 2008 and refuses to die; and 14-22 point-to-point integrations connecting them all in ways that nobody fully documented.

The four legacy system patterns I see most often

In my experience reviewing carrier IT architectures, the legacy footprint usually fits one of four patterns. The pattern determines what integration approach is even feasible.

Pattern A: Monolithic mainframe core. Policy administration, claims, billing, and reinsurance all in a single mainframe system, often COBOL on z/OS or RPG on AS/400. 20-30 years of business logic baked in. Integration with modern systems through batch file transfers or a thin API layer wrapping the underlying batch jobs.

Pattern B: Distributed legacy with point-to-point integrations. The carrier replaced parts of the mainframe over time with .NET, Java, or commercial PAS products. Now 4-8 legacy systems connected by 14-22 point-to-point integrations, each with its own data format, error handling, and operational quirks. Collective documentation is incomplete.

Pattern C: Commercial PAS reaching end-of-life. Carrier deployed a commercial PAS in 2008-2015 (early Guidewire ClaimCenter, an early SAP for Insurance instance, regional vendor product). The vendor end-of-lifed the product or is charging exit fees. Carrier needs to migrate but has 8-15 years of custom configuration on the platform.

Pattern D: Hybrid mainframe + cloud SaaS. Carrier kept the mainframe for system of record but added cloud SaaS for specific functions (agent portal, customer self-service, document management). Integration between mainframe and cloud is a mix of nightly file transfers and API calls with inconsistent contracts.

Each pattern requires different integration tactics. Pattern A often benefits from a Strangler Fig approach where new capabilities run alongside the mainframe and gradually take over. Pattern B usually needs an API gateway that abstracts the legacy mess from new systems. Pattern C typically becomes a focused migration project with the existing PAS data as the source. Pattern D needs event-driven patterns to decouple the cloud and mainframe layers.

The legacy maintenance cost reality

The maintenance cost of legacy systems is well-documented. Gartner and similar analyst firms have consistently found that 70-80% of insurance IT budgets go to legacy maintenance, with the remainder available for new development. The hidden cost is not the maintenance budget line; it is the opportunity cost of the new development that cannot happen because the team is busy keeping the legacy alive.

For mid-tier carriers writing $500M-$5B GWP, the legacy maintenance footprint typically runs $2-15M annually depending on system complexity. That is the integration’s competition for budget: every dollar spent on integration that fails to reduce legacy maintenance is a dollar that should have gone elsewhere. Successful integration eventually reduces the legacy footprint; unsuccessful integration adds to it.

Integration patterns explained - point-to-point, ESB, API gateway, event-driven

There are six integration patterns I see in U.S. P&C insurance carrier architectures. Each pattern has a sweet spot and a failure mode. I have worked with carriers using each of them, and the architecture conversation usually comes down to picking the right combination of two or three patterns rather than committing to one.

Pattern 1: Point-to-point integration

The simplest pattern - System A calls System B directly through whatever interface System B exposes.

When it fits: Integration scope of 2-5 connection points, unlikely to grow.

When it fails: When the carrier has 14-22 integrations (typical mid-tier number). Each becomes its own snowflake. Changes cascade unpredictably. Production incidents take longer to triage because the dependency graph is undocumented. By the fifteenth integration, the carrier has built a custom middleware layer by accident, without the operational tooling that a real middleware layer would have.

Pattern 2: Enterprise Service Bus (ESB)

A centralized middleware layer that all cross-system traffic flows through. Tibco, MuleSoft, WebMethods, and similar products defined this category. The ESB handles message routing, transformation, and protocol translation.

When it fits: 10+ integration points across heterogeneous legacy systems with limited control over source system contracts.

When it fails: When the ESB becomes the bottleneck. Every change requires ESB team involvement. Middleware vendor lock-in becomes severe over 5-10 years. ESB is yesterday’s standard - most new modernization programs avoid central ESB and use API gateway plus event streaming instead.

Pattern 3: API gateway with contract-first design

Modern systems publish APIs with explicit contracts (OpenAPI 3.0 specifications). Legacy systems get wrapped in adapters that expose the same API surface. The API gateway handles authentication, rate limiting, and routing. Each system owns its own API contract.

When it fits: Almost always for new modernization programs in 2026. The API gateway pattern combines decoupling with explicit contracts and operational maturity. It is the pattern I recommend for most mid-tier P&C carrier modernization in the $500M-$5B GWP range.

When it fails: When the carrier treats it as a configuration exercise rather than a contract design exercise. An API gateway with poorly designed contracts is just a more expensive point-to-point integration.

The specific test: The API contracts should be designed before the implementation, not after. I cover the deeper architectural pattern in our coverage of composable insurance and MACH for insurance leaders, which addresses the API-first vs API-enabled distinction in detail.

Pattern 4: Event-driven integration with domain events

Systems publish domain events (“PolicyBound”, “ClaimFiled”, “PremiumReceived”) to a shared event bus. Other systems subscribe to events they care about and react asynchronously. Typical infrastructure: Kafka, AWS EventBridge, Azure Event Grid.

When it fits: When the carrier needs decoupling more than synchronous consistency, when the operational team can run a distributed event system, and when business processes naturally fit an asynchronous model (most insurance workflows do).

When it fails: When operational maturity is not there. Event-driven systems require distributed tracing, dead letter queue management, replay tooling, and on-call rotations that understand asynchronous failure modes. A carrier going event-driven without this maturity will have outages that take hours to triage.

The pattern I see succeed: Event-driven internal to the new system, with API gateway for integration to legacy. This combination keeps distributed system complexity inside the new system where the team has chosen to invest in it.

Pattern 5: Hybrid synchronous + asynchronous

Most carriers end up with this in practice: synchronous APIs for transactional operations (quote, bind, issue) and asynchronous events for downstream processing (analytics, reporting, partner notifications). Messier than pure event-driven but operationally more achievable.

When it fits: Almost every real mid-tier carrier integration architecture.

When it fails: When the carrier does not document which operations are synchronous and which are asynchronous. Result: inconsistent expectations and intermittent production issues.

Pattern 6: Batch file transfer (still relevant)

The oldest pattern - one system writes a file, another reads it on a schedule. Despite modern alternatives, batch file transfer is still appropriate for data warehouse loading, regulatory reporting feeds, retired-LoB wind-down, and reinsurance ceded reporting compliance.

When it fails: When batch is used for transactional integration where API would be appropriate. The latency mismatch destroys the new system’s value proposition.

Pattern comparison

Strangler Fig and Anti-Corruption Layer - patterns that actually work

The Strangler Fig pattern and the Anti-Corruption Layer are two architectural patterns that came from outside insurance (Martin Fowler and Eric Evans respectively) but map exceptionally well onto P&C insurance modernization. They are the patterns I see actually working in production for mid-tier carriers, as opposed to the patterns that work in vendor demos.

The Strangler Fig pattern in insurance

Martin Fowler’s Strangler Fig Application describes incremental replacement of a legacy system by building new capabilities alongside it and gradually routing more traffic to the new system. The “strangling” happens when the new system has absorbed enough of the old system’s traffic that the old system can be retired.

In an insurance context, the Strangler Fig pattern usually plays out in five phases over 18-36 months:

Phase 1: Build the new system alongside the legacy. The new PAS, claims platform, or workbench gets built. It does not yet handle production transactions. Team focus: architecture, data model, integration contracts.

Phase 2: Route shadow traffic to the new system. Real production transactions go to both legacy and new systems. Legacy is authoritative; new runs in parallel and its outputs are compared to legacy outputs. Discrepancies get triaged.

Phase 3: Switch read traffic to the new system. Reporting, queries, and read-only operations move to the new system. Legacy continues handling writes. Typical duration: 4-8 weeks per line of business.

Phase 4: Switch write traffic for new business. New policies, claims, bindings go to the new system. Legacy continues handling the existing book. This is where the cutover actually happens, and where most projects discover the integration patterns that did not work in shadow mode.

Phase 5: Migrate the existing book progressively. Old policies migrate to the new system at natural lifecycle events (renewal, endorsement, claim). Legacy shrinks until it can be retired.

The pattern works because at no point is the carrier forced into a single big-bang cutover. Each phase has clear gates, measurable progress, and rollback options. The risk profile is fundamentally different from a 12-month rip-and-replace.

The Anti-Corruption Layer pattern

Eric Evans’s Domain-Driven Design introduced the Anti-Corruption Layer (ACL) - a protective boundary between a modern system’s domain model and the legacy system’s data model. The ACL translates between the two worlds so that the modern system can model its domain cleanly without inheriting the legacy system’s structural problems.

In insurance modernization, the ACL is often the difference between a clean modern PAS and a modern PAS that ends up looking like a re-skinned version of the legacy. Without an ACL, the modern system’s policy object slowly accretes legacy fields, legacy field naming, legacy null-handling quirks, and legacy validation rules. With an ACL, the modern system stays clean and the translation work happens explicitly in the ACL boundary.

The ACL implementation typically includes a translation layer mapping legacy data structures to modern domain objects, validation rules that reject legacy data inconsistent with modern domain invariants (routing it to a triage queue), an explicit contract document specifying what gets translated and what gets rejected, and monitoring that surfaces translation failures as operational signals rather than silent data corruption.

Strangler Fig + ACL in production

In my experience, the carriers who deploy Strangler Fig with a proper ACL are the carriers who finish their modernization with a clean modern system that actually realizes the architectural benefits. The carriers who skip the ACL end up with a modern system that has the legacy data model wearing modern clothes - which produces the operational improvements but not the architectural ones.

The pattern is documented in Warta’s multi-line modernization on Higson, where each line of business migrated through its own Strangler Fig sequence with a clean domain model preserved through ACL discipline. The result was a system that could absorb new product lines without re-architecture, not just a faster version of the legacy.

For carriers thinking about the broader modernization sequence and how the integration work fits with the data migration work, our coverage of the 8 critical implementation challenges in insurance software covers the program structure that makes Strangler Fig actually work in practice.

COBOL and DB2 data migration approaches

COBOL on z/OS mainframe with DB2 backend is the legacy stack at a meaningful share of mid-tier U.S. P&C carriers. The 1980s and 1990s systems that processed insurance through the industry’s first computerization wave are still running, still profitable, and still impossible to fully understand from the outside. Migrating COBOL and DB2 data is its own discipline within legacy integration, and it is where most modernization projects discover what they did not know.

Three COBOL migration approaches

There are three approaches I see working in practice for COBOL/DB2 modernization. The choice depends on the carrier’s risk tolerance, modernization timeline, and operational team capacity.

Approach 1: Lift and shift (rehosting). The COBOL code moves to a modern infrastructure platform (typically x86 hardware running a COBOL emulation environment, or a cloud-native COBOL runtime). Application logic stays the same. Integration surface gets modernized through API wrappers around the COBOL programs.

• When it fits: COBOL business logic is mature and well-understood; the modernization goal is operational infrastructure renewal rather than business capability change. 18-month timeline is realistic.
• When it fails: When the carrier expects this to be a stepping stone to “real” modernization. Lift and shift can extend COBOL operational life another 10-15 years; it does not usually lead to actual COBOL retirement.

Approach 2: Schema transformation with parallel run. DB2 data structure gets analyzed, cleaned, and mapped to a modern relational or NoSQL hybrid schema. New system runs in parallel with COBOL - both writing to their respective databases, data reconciled continuously. Once the new system has full feature parity, COBOL gets retired.

• When it fits: Carrier has operational capacity to run two systems in parallel for 6-18 months; data quality is good enough that schema transformation produces clean modern data; team has discipline to maintain dual writes through migration.
• When it fails: When the dual-write architecture is not built carefully. Asymmetric failure modes between the two systems create data divergence discovered months later in production.

Approach 3: Event-replay reconstruction. COBOL transaction history gets exported as a stream of business events. New system consumes those events from a starting point (usually a clean baseline date) and reconstructs policy state by replaying every transaction since the baseline.

• When it fits: COBOL transaction history is complete and auditable; new system is designed event-sourced anyway; team has architectural discipline to maintain the event stream as the source of truth.
• When it fails: When the COBOL system has decades of “fixups” that bypassed normal transaction flow. The event stream is incomplete; the replay produces a state that does not match production.

What the three approaches share

All three approaches share four requirements that determine project success regardless of which approach is chosen:

Data quality assessment as a pre-contract activity. The 8-15% of records that fail validation must be identified before the project commits to a migration approach. I cover this in detail in our coverage of the 8 critical implementation challenges in insurance software.

ACORD compliance throughout the migration. P&C carriers must produce ACORD-compliant output from the new system regardless of how the data was migrated. The migration should produce data that meets ACORD standards, not data that needs another transformation later.

Audit trail continuity. Every transaction in the COBOL system must be traceable through the migration to its equivalent in the new system. Regulators do not accept “we migrated the data, trust us” - they want the lineage.

Operational rollback capability. Every phase of the migration must be reversible. If the dual-write architecture starts producing data divergence, the team must be able to revert to legacy-authoritative without data loss. The rollback architecture is part of the migration architecture, not an afterthought.

For carriers thinking about the broader data migration pattern that supports legacy retirement at scale, the data migration deep dive in our coverage of insurance data migration challenges goes through the operational discipline that makes any of these three approaches actually work in production.

Five-step legacy integration framework

After 20+ years building integration architectures for European and U.S. insurance carriers, I have consolidated the work into a five-step framework. The framework is not original to me; it is the synthesis of what I see working across 100+ insurance projects. The carriers who follow this sequence finish their integration work on time. The carriers who skip steps usually fail at the step they skipped.

Step 1: Inventory the integration surface (4-6 weeks, before vendor selection)

The first deliverable is a written inventory of every integration point in the current architecture. For most mid-tier carriers, this produces a document of 14-22 integrations, each with: source and target systems, direction, synchronicity (real-time, near-real-time, batch), data format (ACORD XML, JSON, fixed-width, proprietary), failure mode, operational ownership, and volume.

This inventory is the input to vendor selection and architecture design. Carriers who skip this step end up discovering integrations during implementation, usually at the worst possible time.

Step 2: Map the data flow and identify critical paths (3-4 weeks)

The inventory shows what is connected. The data flow analysis shows which flows are critical to business operations and which are nice-to-have. A typical mid-tier carrier has 4-6 critical-path integrations (quote-to-bind, FNOL-to-payment, premium billing, reinsurance ceded reporting) and 10-15 supporting integrations.

The critical paths get the architectural investment. Supporting integrations can often be simplified, batched, or temporarily replaced with manual processes during the migration. Without this prioritization, every integration gets equal weight and the project tries to modernize everything simultaneously.

Step 3: Design the future-state integration architecture (6-8 weeks)

The future-state architecture document specifies the integration pattern for each connection (API gateway, event-driven, batch file, etc.), the data contracts for each interface (OpenAPI specifications, ACORD mappings), the operational monitoring approach, and the rollback design.

The output is a written architecture that the vendor’s implementation team and the carrier’s operations team can both work from. The architecture is not “we will use APIs” - it is the specific list of contracts, error handling, monitoring, and operational procedures.

Step 4: Sequence the integration build with Strangler Fig phases (continuous through implementation)

The integration build does not happen in a single phase. It happens line-by-line, with each line of business going through the five Strangler Fig phases independently. The sequencing produces a multi-line carrier modernization that takes 24-36 months for full migration but starts producing business value in months 9-12 with the first line’s go-live.

The sequencing decision - which line goes first, which goes second, what the parallel run period looks like for each - is the most consequential operational decision in the program. Generally I recommend starting with the least complex line (often personal property or personal auto) to build operational confidence, then progressing through commercial and specialty lines.

Step 5: Retire legacy systematically (months 24-48 after first go-live)

Legacy retirement is the step that most projects defer indefinitely. The new system goes live, the integration works, and the legacy keeps running in parallel because “we might need it for the audit trail” or “we have not finished migrating the old policies.” Without a deliberate retirement plan, the carrier ends up running both systems forever and never realizes the legacy maintenance savings.

The retirement plan should be in the original project scope, not added later. It should include the specific milestones that trigger legacy system shutdown (last policy migrated, all open claims closed, audit retention period elapsed, regulatory filings transitioned), the data archival approach for retained records, and the operational date when the legacy system goes read-only and then offline.

When not to integrate - the case for replacement

Integration is the right pattern for most mid-tier P&C carrier modernization. But not always. There are specific situations where integration extends the legacy system’s life past its useful point, and the right answer is a focused replacement project rather than a multi-year integration program.

Four cases where replacement beats integration

Case 1: The legacy system is end-of-life and unsupported. When the vendor has discontinued support, when the operating system version is past end-of-life, when the underlying hardware is no longer manufactured, the integration window has effectively closed. Continuing to integrate against a system that is about to fail operationally adds risk rather than reducing it.

Case 2: The data model corruption is severe enough to require ACL on every operation. If the carrier finds that 30%+ of legacy data requires translation through the Anti-Corruption Layer, the legacy system has effectively become a data quality problem, not a system of record. At that scale of translation, building a replacement and migrating the clean records is usually faster than maintaining indefinite ACL operations.

Case 3: The compliance burden of the legacy system exceeds the migration cost. Some legacy systems have grown 50-state regulatory exceptions, manual workarounds, and undocumented compliance processes to the point where keeping the system compliant is more expensive than building a modern compliance-by-design replacement. The math favors replacement.

Case 4: The integration cost exceeds the replacement cost over 5 years. This is the cleanest test. If the 5-year integration TCO (build + maintain + operational cost) is higher than the 5-year replacement TCO including parallel running, the project should be a replacement, not an integration. Mid-tier carriers should run this math explicitly during architecture review, not assume integration is cheaper because the headline price looks lower. Our Pillar Main walks through this exact 5-year TCO comparison in more depth, including the build-vs-buy-vs-partner framing that sits one level up from this integration-versus-replacement decision.

The honest framing on integration vs replacement

My take, after seeing carriers in both directions: integration is the right answer 70-80% of the time for mid-tier P&C carriers, replacement is the right answer 15-20% of the time, and the remaining 5-10% is the gray zone where reasonable architects disagree. The disagreement usually comes down to risk tolerance and operational confidence rather than architectural correctness.

The mistake I see most often is not picking the wrong pattern; it is failing to make the decision explicitly. Carriers default into integration because it sounds safer, then discover three years in that the integration is producing diminishing returns and the legacy system is consuming more budget than expected. The deliberate choice between integration and replacement, with documented rationale and explicit milestones, is the discipline that prevents this drift.

For carriers thinking about the vendor selection decision that follows from this architectural choice, our Build vs Buy vs Partner decision framework walks through the vendor evaluation criteria specifically for the replacement scenario and the partner-led integration scenario.

FAQ

How do you integrate new insurance software with legacy systems in 2026?

You integrate new insurance software with legacy systems through a combination of architectural patterns: an API gateway for synchronous operations, event-driven messaging for asynchronous decoupling, an Anti-Corruption Layer to protect the modern domain model from legacy data structures, and the Strangler Fig pattern for gradual replacement over 18-36 months. The specific pattern combination depends on the carrier’s legacy footprint, operational maturity, and modernization timeline. Most mid-tier P&C carriers use API gateway plus event-driven plus Strangler Fig as their core combination.

What are the biggest challenges of legacy integration in insurance?

The biggest challenges are data quality issues in 15-30 year old systems (8-15% of records typically fail modern validation), undocumented business logic embedded in COBOL or legacy code, ACORD compliance requirements that must be preserved through the migration, 50-state regulatory carve-outs in the data model, audit trail continuity for regulatory retention (typically 7 years), and operational availability requirements that prevent any single big-bang cutover.

What is an API gateway in insurance and when do you use one?

An API gateway in insurance is an architectural pattern where modern systems expose APIs through a centralized gateway that handles authentication, rate limiting, routing, and contract enforcement. Legacy systems get wrapped in adapters that present the same API surface. The pattern fits almost all modern mid-tier P&C carrier modernization programs because it combines decoupling with explicit contracts and operational manageability. It replaces the older Enterprise Service Bus (ESB) pattern that dominated insurance integration through the 2000s and 2010s.

What is the Strangler Fig pattern in insurance modernization?

The Strangler Fig pattern is an incremental replacement architecture where new insurance systems run alongside the legacy and gradually take over traffic until the legacy can be retired. The pattern typically runs in five phases over 18-36 months: build new alongside legacy, shadow traffic, switch read traffic, switch new-business writes, migrate the existing book at lifecycle events. The pattern eliminates the all-or-nothing risk of big-bang cutover and produces measurable business value starting in months 9-12 with the first line of business migration.

How do you handle COBOL data migration to a modern insurance platform?

COBOL data migration uses one of three approaches: lift and shift to a modern COBOL runtime (extends legacy life 10-15 years, does not retire COBOL); schema transformation with parallel run between legacy and modern systems for 6-18 months until feature parity; or event-replay reconstruction where the COBOL transaction history seeds the modern event-sourced system. All three approaches require data quality assessment as a pre-contract activity, ACORD compliance throughout the migration, audit trail continuity, and operational rollback capability.

When should a carrier replace the legacy system rather than integrate?

A carrier should replace rather than integrate when the legacy system is end-of-life and unsupported, when 30%+ of legacy data requires Anti-Corruption Layer translation on every operation, when the compliance burden of maintaining the legacy exceeds the replacement cost, or when the 5-year integration TCO exceeds the 5-year replacement TCO including parallel running. For most mid-tier P&C carriers, replacement is the right answer 15-20% of the time and integration is the right answer 70-80% of the time.

Talk to Decerto about IT Audit and Architecture Review

Insurance software integration with legacy systems is the architectural decision that determines whether the modernization program ships in 18-36 months or stalls in indefinite parallel running. The mid-tier carriers who finish their integration cleanly are the ones who picked patterns deliberately, documented architecture before vendor selection, and committed to Strangler Fig discipline through implementation.

In my experience, every carrier that has tried to make this decision from vendor demos has spent 6-12 months and significant consulting fees before reaching the same answer that a vendor-neutral 4-hour architecture review would have produced.

What we offer: a free 4-hour IT Audit with a senior architect from Decerto. The output is a 25-30 page report covering the carrier’s current integration surface, the realistic pattern combination for their legacy footprint (Pattern A through D from Section 3), the recommended Strangler Fig sequence with line-of-business prioritization, ACL design considerations for the carrier’s data model, and a 5-year TCO range with documented assumptions for integration versus replacement.

It is not a product demo or sales pitch. The audit can recommend the carrier extend legacy system life through targeted integration rather than committing to full modernization this year, and I have written that recommendation more than once. The output is an honest architectural assessment that the CIO and Daniel-level architect can defend to the Board.

The 20+ year context: Decerto has shipped 100+ insurance projects since 2003, including legacy integration programs at carriers writing across personal lines, commercial lines, and specialty programs. The verified case studies on our case study page include Warta’s multi-line modernization with Strangler Fig sequencing, Allianz Poland’s product management modernization on Higson, and BNP Paribas Cardif’s claims centralization on Higson. Higson, our flagship product, is built specifically for the API-first integration patterns that make Strangler Fig work for mid-tier P&C carriers $500M-$5B GWP. Higson is not the right fit for $5B+ enterprise carriers - Guidewire is the industry standard there.

Sources and citations

1. Fowler, M. (2004). StranglerFigApplication.
2. Fowler, M. (2011). AnticorruptionLayer.
3. Gartner. (2025). Magic Quadrant for SaaS P&C Core Platforms, North America. Gartner, Inc., 18 September 2025.
4. Krishnakanthan, K., Kaniyar, S., Catlin, T., & Ru, S. (2025). How P&C Insurers Can Successfully Modernize Core Systems. McKinsey & Company, May 12, 2025.
5. McKinsey & Company. (2026). Can Agentic AI (Finally) Modernize Core Technologies in Insurance?. McKinsey & Company, April 2026.
6. Deloitte. (2026). 2026 Insurance Industry Outlook: Property & Casualty Insurance.
7. Datos Insights (formerly Aite-Novarica Group). (2023). Property/Casualty Insurer IT Budgets and Projects.
8. NAIC. (2017, adopted). Insurance Data Security Model Law (#668).
9. ACORD. Property & Casualty Data Standards (AL3 and XML).
10. NY DFS. (2023). Cybersecurity Regulation 23 NYCRR 500 (legacy system integration security).
11. Evans, E. (2013). Getting Started with DDD When Surrounded by Legacy Systems. Domain Language, Inc.