Ask an insurance CIO what keeps growth slow and the answer is usually the same system that keeps the company running. The policy admin core works. It has worked for twenty years. And every new capability the business asks for seems to require touching it.
Legacy system modernization is how carriers get out of that trap. But the word "modernization" has been hijacked by its most expensive version: the full core replacement, the multi-year program, the big cutover weekend. That version fails often enough that many carriers simply stop, and keep bridging the gaps by hand instead.
There is a less dramatic path. The modernization projects I've seen deliver, quarter after quarter, never bet the company on a cutover. They work in slices: wrap, extend, extract. This guide explains what that means in practice.
What is legacy system modernization?
Legacy system modernization means updating how an insurer's core systems, policy administration above all, connect to the rest of the operation: modern interfaces, APIs, integrations and data access built around the existing core. Replacing the core is one form of modernization. It is the riskiest form, and it is rarely the right place to start.
The core itself is rarely the real problem. A policy administration system that has run for two decades is holding your rating logic, your policy history and thousands of business rules nobody ever wrote down. What hurts is everything around it: underwriters swiveling between screens, staff rekeying the same submission into three systems, month-end extracts because nothing can read the data live, and a queue of product ideas waiting because every change goes through the core team.
Why do rip-and-replace projects fail so often?
Because replacement turns decades of embedded business rules into a single project with a single cutover. Scope grows as those rules surface, timelines stretch across budget cycles, and the business freezes while it waits. When these programs collapse, the cause is almost always scoping, not technology: the work was never one project.
I have sat in the meetings where a replacement program asks for its third extension. Nobody in that room made a bad technical decision. The original plan just assumed the core's behavior was documented, and it never is. The documentation is the system itself, and you discover what it really does one migrated policy at a time.
The other cost is quieter. While the replacement program runs, everything else stops: the portal the brokers asked for, the intake automation, the reporting the CFO wants. All of it waits for a platform that keeps not arriving.
What does modernizing in slices look like?
Modernizing in slices means shipping value in independent steps while the core stays live: wrap the core with an API layer, extend it with new capabilities built alongside it, and extract individual functions only when they have clearly outgrown the old system. Each slice pays for itself before the next one starts.
The three moves, in order:
- Wrap. Put an API layer around the core. The core keeps doing exactly what it does today; everything new talks to the wrapper instead of a green screen. This is the least glamorous slice and the one that makes every later slice cheaper.
- Extend. Build the capability the core could never offer, a broker portal, a submission intake pipeline, an underwriting workbench, as a separate system that reads and writes through the wrapper. The core doesn't change. The operation does.
- Extract. When one function has clearly outgrown the core, rating for a new product line, document generation, move that single function out to its own service and leave the rest alone. Extraction is a scalpel, not a default.
The order matters. Wrapping first means every later project builds against a stable interface. Extending proves value without touching what works. And each slice ships on its own schedule, so a slow one delays a project, not the company.
Where should a carrier start?
Start with the slice attached to a measurable bottleneck. For most carriers that is intake: broker submissions and loss runs arriving as PDFs that people retype into the core. Standardizing that data feeds underwriting, rating and reporting downstream, which is why intake is the beachhead I recommend most often.
The first slices I've seen keep delivering:
- Submission and loss run intake. Turn the PDFs brokers send into structured data once, at the front door, instead of retyping them at every desk that touches the risk.
- An underwriting workbench. One screen that pulls from the core and external data sources, so underwriters stop assembling the picture by hand before they can start judging the risk.
- A quoting front-end for one product line. Narrow on purpose: one line, one team, one measurable cycle time.
Notice what is not on that list: anything that requires the core itself to change.
What does this mean for your AI plans?
Every AI capability carriers are evaluating right now, document extraction for loss runs, underwriting copilots, depends on data the core alone cannot serve: clean, structured, reachable through APIs. Modernization in slices builds exactly those paths. That is why the wrap step is also the honest first step of any carrier AI roadmap.
We build AI systems for carriers, and the pattern is consistent: the model is the small part, the data path is the project. A carrier that has wrapped its core and standardized intake can put an underwriting copilot into production without touching the mainframe. A carrier that hasn't will spend the AI budget on plumbing and call the result an AI disappointment. That is a planning failure, not an AI failure. Our insurance page covers what we build on top of these foundations.
How do you keep the core stable while you modernize?
Treat the core like the production infrastructure it is: start read-only, route every write through one gate, parallel-run any extracted function before cutover, and keep a rollback path. Above all, keep the people who know the core inside the project. Their knowledge is the real specification.
Four rules from delivery:
- Read before you write. The first version of the wrapper only reads. You learn how the core actually behaves before anything depends on changing it.
- One door in. Every write goes through the wrapper, so there is one place to test, audit and shut off.
- Parallel-run extractions. An extracted function runs alongside the core's version until the outputs match. Then you cut over, with a way back.
- Keep the core team close. The engineers and analysts who have maintained the system for years are not the obstacle to modernization. They are the map.
How do you get started?
Pick one slice with a number attached, run a short discovery, and staff a small team you can scale on evidence. Two to three weeks of discovery should produce a fixed scope for a first slice that lands in three to four months, while your operation keeps running.
A focused pod of three or four engineers is enough for a first slice. Our team augmentation page explains how we staff that model with teams across San Diego and Tijuana, working your business hours. And if you're still weighing whether custom work is justified at all, start with our guide to insurance software development.
Bring us the bottleneck and the number attached to it. If a slice won't move that number, we'll tell you before you spend anything.
Frequently asked questions
Do we ever actually replace the core?
Sometimes, and the slices approach makes it safer when you do. After wrapping and a few extractions, what remains of the core is smaller, better understood and easier to migrate. Full replacement becomes a deliberate final step you might take someday, not a leap you start with. Many carriers find they never need it.
How long until the first slice delivers?
Discovery typically takes two to three weeks. A first slice, an API wrapper plus one capability such as standardized submission intake, usually reaches production in three to four months. That first delivery is the test of the whole approach: if a slice can't ship in roughly a quarter, the scope is wrong.
What about our AS400?
It is probably not going anywhere soon, and that is fine. AS400-era systems are stable, fast and paid for. The problem was never the machine; it is that nothing modern can talk to it. Wrapped with an API layer, it becomes a dependable backend for portals, workbenches and AI pipelines.
Is modernization the same as moving to the cloud?
No. Cloud migration changes where systems run. Modernization changes what your operation can do: new capabilities, integrations and data access. Lifting an old core into the cloud unchanged gives you the same constraints on rented hardware. Cloud is often part of a slice, but hosting is not the goal.
