Insurance transformation is forcing legacy system replacement

At a glance

What this is: This is Comarch’s case that insurance transformation is being driven by market pressure, operational inefficiency, and regulatory demands, and that legacy systems plus ad hoc overlays are no longer sustainable.

Why it matters: It matters because identity, access, and data governance programmes in insurers often get trapped inside brittle operating models, so practitioners need to plan for platform change rather than layer controls onto legacy complexity.

By the numbers:

• Highly digital insurance agencies develop on average 70% faster than other agencies, according to a report cited by Comarch.

Context

Insurance transformation in this article means replacing outdated operating models with a compatible environment that can absorb new business, service, and data requirements without constant patching. The governance problem is not simply modernisation, but whether insurers can keep operating with fragmented systems, manual work, and unstructured data without compounding complexity.

For identity and access teams, the relevance is structural: legacy platforms often lock in manual workflows, duplicated entitlements, and awkward integration points that make change harder to govern. The article’s central claim is that ad hoc overlays buy time, but they do not change the underlying control model.

The article treats transformation as unavoidable rather than discretionary, with external pressure coming from digitised customer service, economic pressure, and regulation. That starting position is typical for large insurers, where operational inertia usually becomes visible only after complexity has already accumulated.

Key questions

Q: How should insurers approach legacy system replacement during transformation?

A: Treat replacement as a business and governance programme, not a pure IT refresh. Start by identifying which legacy components block change, where overlays create duplicated control paths, and which systems must become authoritative for data and process ownership.

Q: Why do ad hoc overlays keep making insurance transformation harder?

A: They add another layer of logic on top of an already brittle core, which increases integration complexity, creates inconsistent rules, and leaves manual reconciliation in place. The result is usually more coordination effort, not less operational risk.

Q: What signs show that an insurer’s transformation programme is stuck in patchwork mode?

A: Look for growing numbers of disconnected systems, repeated manual work, duplicated data definitions, and change requests that require workarounds instead of platform updates. Those are signals that the organisation is modernising around the core rather than replacing the core.

Q: Should insurers prioritise cloud adoption or process redesign first?

A: Neither should be treated as independent. Cloud adoption can support flexibility, but if the operating model remains unchanged, the insurer simply recreates legacy constraints in a different environment. The right sequence is to redesign the control model alongside the infrastructure plan.

Technical breakdown

Why overlays on legacy insurance platforms keep failing

An overlay is a layer of process or software added on top of an old core system to expose new functionality without replacing the underlying platform. In insurance, overlays often create a second control plane: one set of rules in the legacy core and another in the modern interface. That split causes duplicated data models, inconsistent approvals, and more places where reconciliation has to happen by hand. The result is not just technical debt but governance drift, because the organisation starts managing exceptions instead of systems. Practical implication: stop treating overlays as a stable operating model when the underlying platform cannot support the change path you need.

Practical implication: treat overlays as temporary bridges, not the target architecture for governance or identity operations.

Why structured data models and APIs matter in transformation

The article points to structured data models and precisely described APIs as the mechanism that makes complex software architecture behave predictably. A structured model reduces ambiguity in how insurance data is represented, while precise APIs define what can be exchanged and under what conditions. This matters because transformation is often blocked by integration uncertainty rather than by user-facing features. When APIs are loosely defined, every downstream connection becomes a bespoke dependency, which slows product changes and increases operational risk. Practical implication: standardise data contracts before expanding the number of systems that must interoperate.

Practical implication: govern data contracts and API boundaries before extending insurance workflows across more systems.

Cloud adoption in insurance only helps when the operating model changes too

Moving to cloud infrastructure changes where systems run, but it does not automatically change how the business governs them. The article frames cloud as a way to expand ecosystem integration and adapt infrastructure across public clouds such as AWS and Azure. That only works when teams also redesign processes for portability, partner connectivity, and future change. Otherwise, the insurer recreates legacy constraints in a new hosting model and keeps the same bottlenecks, only faster. Practical implication: align cloud strategy with process redesign, not just migration plans.

Practical implication: pair cloud adoption with process and integration redesign so legacy constraints are not re-created in new environments.

NHI Mgmt Group analysis

Legacy replacement is now a governance problem, not a technology preference. The article is right to frame transformation as unavoidable, because insurers that delay replacement end up governing business change through systems that were never designed for it. That creates rising exception handling, more manual reconciliation, and weaker visibility into who can change what. The practitioner lesson is that the architecture itself becomes part of the control problem, not just the delivery problem.

Ad hoc overlays create an integration debt that eventually behaves like access debt. Each overlay adds another place where rules, entitlements, and data flows can diverge from the source system. Over time, that divergence makes it harder to know which control is authoritative, which is a classic failure mode in large insurance estates. Teams should read this as a warning that patching around legacy systems postpones but does not reduce governance exposure.

Flexible insurance operations require modular control boundaries, not just modular products. The article’s focus on configurable offerings and ecosystem expansion points to a broader market shift toward composable operating models. That shift is not only commercial, it is administrative: insurers need cleaner boundaries for approvals, data flows, and service ownership. The more modular the business becomes, the more important it is to keep control boundaries explicit and maintainable.

Structured APIs are now a prerequisite for trustworthy change at scale. When an insurer cannot describe data exchange precisely, every new partner, channel, or self-service journey increases ambiguity. That is why the combination of data model discipline and API precision matters more than slogans about digital transformation. The practical conclusion is straightforward: insurers that want speed must first make the control surface legible.

What this signals

Integration debt is the real blocker: insurers do not just inherit old systems, they inherit old decision paths, manual exceptions, and unclear ownership that make every new channel harder to govern. Transformation succeeds when the control surface becomes simpler than the legacy estate it replaces.

The article’s strongest signal for practitioners is that flexibility has to be designed into the operating model, not bolted on after the fact. In insurance, that means cleaner data contracts, clearer system boundaries, and fewer places where business change depends on one-off fixes.

For practitioners

• Define a legacy replacement roadmap Inventory core systems, overlays, manual workarounds, and duplicated data paths, then classify which components can be retired, re-platformed, or isolated while change is underway.
• Standardise data contracts across channels Create a governed data model and enforce consistent API definitions so sales, service, and back-office processes use the same authoritative fields and state transitions.
• Separate temporary overlays from target-state controls Document which overlays are transitional and set explicit exit criteria, because permanent overlays usually create more integration points than they remove.
• Align cloud strategy with operating-model change Treat AWS, Azure, or other cloud adoption as part of a broader redesign of service ownership, integration governance, and change management rather than a hosting migration alone.

Key takeaways

• Legacy insurance transformation is being driven by market pressure, digitisation, and regulation, not by optional innovation cycles.
• Patchwork overlays may extend the life of old systems, but they also deepen integration complexity and slow future change.
• Insurers need modular architecture, governed APIs, and a replacement mindset if they want flexibility without multiplying control debt.

Key terms

• Legacy system replacement: The retirement or re-platforming of older core systems that constrain business change. In insurance, this usually means moving beyond overlays and manual workarounds so the organisation can govern processes, data, and integration on a more consistent operating model.
• Transformation overlay: A temporary layer added on top of an existing system to expose new capabilities without replacing the underlying core. Overlays can help bridge gaps, but they often duplicate logic and create extra integration and governance complexity if they become permanent.
• Structured Data: Structured data is information organized in a fixed schema, such as rows, columns, fields, or database records. It is easy to search, query, and analyze because its format is predictable. In security programs, structured data is simpler to classify and govern, but still needs access control, retention rules, and validation to prevent misuse.
• Operating model flexibility: The ability of an organisation to absorb business, technology, and regulatory change without redesigning everything from scratch. For insurers, flexibility depends on architecture, process ownership, and integration discipline, not just on new tools or hosting choices.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.