Your claims platform was never one system

By: Esteban Felipe

Ask a claims leader at a mid-market carrier to draw their claims environment, and you rarely get one box. You get a core system in the middle, usually Guidewire or Duck Creek, and then a ring of point solutions around it: a document intake tool from one vendor, a fraud model from another, an RPA bot someone built three years ago to close a reporting gap, a spreadsheet that still runs vendor management for total losses. Nobody planned that picture. It accumulated, one project and one budget cycle at a time, into the system adjusters actually use every day.

That is normal, not a failure. Every carrier that has been writing business for more than a decade looks something like this, and vendor demos promising a single platform that replaces the whole picture are selling a version of your business that never existed. The real decision in front of you is not whether to replace the core. It is which work moves into the layer above it, and in what order.

Fragmentation is normal

Depending on who you ask, there are somewhere around 30 core claims systems still active across North America, and the average P&C insurer manages well over 100 integrations around whichever one it runs. That is not evidence of bad architecture. Claims work touches medical bill review, special investigations, legal, reinsurance, and weather data; the system's core platform was never built to absorb on its own.

Replacing the core does not make that easier, and waiting for the workforce to retire does not either. A large share of the people who understand why a legacy routine handles subrogation the way it does are heading toward retirement over the next few years, and most of what they know about these systems was never written down.

Buying does not end the assembly work

Buying a new platform does not finish the job. It restarts it. A modern claims capability still needs workflow, engagement, triage, fraud, and document handling selected, connected, tested, and governed around whatever core you land on, and that work takes three to five years for an off-the-shelf project and five to ten for a custom build. That is the same layer that existed before the replacement, and it needs just as much attention after it.

Most carriers running transformation programs right now are continuing work already underway, not starting a new core replacement. Staged modernization is not a consolation prize. It is what the industry is actually doing.

None of this means replacement is dead. For the right carrier, replacement is real, and vendor fit sometimes genuinely is that strong. But for most established carriers, replacement is one phase in a longer modernization plan, not the plan itself, and treating it as the finish line is what stalls budgets for years at a time.

The work moved above the core

What we keep seeing in discovery engagements is that the real work now happens in a layer most carriers did not manage deliberately ten years ago: orchestration, APIs, events, low-code workflow, and document intelligence sitting on top of legacy and core systems, letting adjusters work across systems without touching the code inside any one of them. Even Guidewire built its own integration framework so integration logic could live outside its own core code. That is a core vendor building for the layer above itself.

One global reinsurance broker digitized its claims process with a workflow tool, changing how the team worked with no core replacement required. One large carrier connected its core system to an automation layer and took a claims activity from 20 minutes down to 90 seconds during a weather event that generated tens of thousands of claims in a single stretch. Neither one waited for a new core to get that value.

Some vendors now build systems specifically to sit next to legacy systems rather than replace them. The vendors closest to the problem stopped selling replacements years ago. They sell workbenches and connected claims now, not cores, because that is where the fragmentation actually hurts.

AI depends on that layer

AI follows the same pattern. Carriers are combining AI built within their core vendor's platform, custom copilots, and external tools, rather than waiting for one vendor to solve intelligence for them. One large European insurer built its own claims copilot for auto claims, later expanded into property, and people still make the coverage and payout calls. Other carriers are scaling document AI into legacy claims systems with confidence checks, so anything the model is unsure about is routed to a person instead of being silently trusted.

Adoption is still slow and uneven across most carriers, and many AI pilots will not make it to production. Pilots and copilots are real today. Autonomous claims decisions are not, and carriers are being asked to show their work: explain the decision, show the audit trail, keep a person in the loop. That is work done in the layer above the core, not inside it.

Manage it as a sequence of waves

If claims modernization is assembly, not procurement, the investment question changes. Instead of asking which platform to buy, ask a shorter set of questions:

1. Which claims work creates the most volume or delay right now?
2. Which systems need to stay because they work and the people around them know how to run them?
3. Which workflows need a coordination layer above the core before they can scale?
4. Which data needs to be cleaned and governed before AI can safely touch it?

Answer those in order, and you get a phased modernization plan rather than a single big bet. Fund the unglamorous layer first: APIs, event integration, workflow orchestration, and validated, standardized data, rather than data everyone just assumes is fine. That work does not demo well next to an AI copilot, but it decides whether the copilot, or the next core wave, works once it is live.

The discipline is knowing what to build, what to buy, and what to leave alone. Most carriers we talk to have not explicitly made that call. They are still waiting for a platform decision to make it for them.

At Claro, our AI and Automation Discovery conversations rarely start with which core to buy. They start by mapping the waves already underway, the integrations that hold the environment together, and the data that needs cleaning up before the next automation or AI investment can work in production. Modernizing legacy systems without a rip-and-replace program, wrapping what works in APIs, and automating the regulated processes in between is the actual work of the layer above the core.

You do not need a new platform decision to start your next wave. You need to know which wave is next and whether the integration layer can support it. Worth answering before the next vendor demo, not after.

FAQ

Does claims modernization require replacing the core claims system?

No. Insurers can modernize claims by improving integrations, workflows, APIs, automation and data around existing core systems. Core replacement can be one phase of modernization rather than the entire strategy. Your claims platform was never …

What is the integration layer in claims modernization?

The integration layer connects core and legacy systems through APIs, events, workflow orchestration, low-code tools and document intelligence, allowing claims teams to work across multiple systems more efficiently. Your claims platform was never …

How can insurers modernize legacy claims systems?

Insurers can modernize legacy environments by identifying high-friction workflows, preserving systems that still work, improving integrations and data, and introducing automation in phases instead of replacing everything simultaneously. Your claims platform was never …

How does claims modernization support AI?

AI requires reliable access to connected, governed data and workflows. APIs, integrations and orchestration help AI tools interact with claims systems while supporting human review, auditability and operational controls. Your claims platform was never …

What should insurers prioritize before implementing AI in claims?

Insurers should identify high-volume or delayed workflows, determine which systems should remain, establish necessary integrations, and clean and govern the data AI will depend on before scaling AI initiatives. Your claims platform was never …

What is a phased approach to claims modernization?

A phased approach divides modernization into manageable waves based on business priorities, system dependencies, workflow needs and data readiness instead of treating transformation as one large technology replacement project.