Legacy Policy Administration System Blocking New Services? How UK Insurers Build Around It

The broker portal project stalls because your legacy policy administration system can only export a nightly batch file. The core vendor is winding down support, and the package vendor quotes a change request measured in quarters. Most insurers should not replace the core first: build the new services around it, then retire it in stages.

Key takeaways

• A legacy policy administration system holds every live policy, so replacing it in one move is the riskiest option an insurer has.
• An integration layer can serve current data to a broker portal even when the core only exports batch files.
• The strangler pattern lets new services take over functions from the core step by step, until the core can be retired.
• Package, configure, build around the core and full replacement each suit different situations; the comparison table below helps you choose.
• The deciding question is which option lets you prove you can recover an important business service within its impact tolerance.

Why do legacy policy administration systems block new services in insurance?

Legacy policy administration systems block new services because they were built for products and channels that have since changed. They expose data through batch files or direct database access, not the APIs a broker portal or claims workflow needs.

A policy administration system is the platform that issues, changes and renews policies and holds the record of every live one. Because it holds that record, it cannot simply be swapped out. Every product, rating rule and document template depends on it.

Packaged portals do not solve the problem either. They assume a standard data model, so an insurer with distinctive products adds a workaround for each difference. Each workaround becomes technical debt that the next upgrade has to carry.

None of this is the IT team’s fault. The core was chosen years ago, for a distribution model that has moved on. Acquisitions added a second or third platform. The team has kept everything running while the demands on it grew.

What does a legacy policy administration system put at risk for an insurer?

A legacy policy administration system puts an insurer’s operational resilience, security and Consumer Duty evidence at risk. The effort spent on workarounds also crowds out new products.

The day-to-day symptoms are familiar to any CTO or IT Director:

• Rekeying: underwriters copy data from the core into spreadsheets and broker systems by hand.
• Delay: brokers see yesterday’s data, because the batch runs overnight.
• Evidence gaps: Consumer Duty outcome reporting lives in spreadsheets that nobody can trace.
• Security exposure: platforms near the end of vendor support stop receiving patches.

Public data shows the wider pattern. The UK government’s State of digital government review estimated that legacy technology made up 28% of central government systems in 2024, up from 26% in 2023, and 22% of those legacy systems were rated red for risk. The same forces of age, lost vendor support and scarce skills apply to insurers’ cores. The Cyber Security Breaches Survey 2025 found that 74% of large businesses identified a breach or attack in the previous 12 months.

Regulators connect these risks directly to consumers. The Financial Conduct Authority (FCA) says that “operational disruptions and the unavailability of important business services can cause wide-reaching harm to consumers” (FCA operational resilience). An important business service is a service whose disruption could cause intolerable harm to consumers or markets. Firms in scope had until 31 March 2025 to show they could operate those services within their impact tolerances, and new FCA incident and third-party reporting requirements come into force on 18 March 2027.

How do insurers build new services around a legacy policy administration system?

Insurers build around a legacy policy administration system by delivering new services in short, visible phases, with the core kept as the system of record until a planned migration retires it. The phases follow agile delivery as the GDS Service Manual describes, starting with discovery.

The diagram shows the path, with the fork where the core either stays or retires.

1. Run discovery workshops. Map user needs with underwriting, operations, compliance and IT, using journey mapping, card sorting and personas. Outcome: a specification and a prioritised backlog.
2. Prototype before code. Produce wireframes and clickable prototypes with accessibility designed in. Outcome: problems found while they are still quick to fix.
3. Build in short sprints. End each sprint with working software your team reviews and tests. Outcome: visible progress at every sprint review.
4. Connect to or migrate off the core. If the core stays as the system of record, connect the new services to it, your CRM and third-party APIs. If it is retiring, migrate the data clean and structured. Outcome: one source of truth.
5. Test continuously. Run functional, integration, load, cross-browser and accessibility tests in every sprint, then independent penetration testing that follows the NCSC penetration testing guidance. Outcome: issues caught early.
6. Train and hand over. Provide role-specific materials, a practice environment and recorded guides. Outcome: your team runs the system confidently.

Secure development matters at every step. Thornacre follows the NCSC secure development and deployment guidance and verifies applications against the OWASP Application Security Verification Standard.

How does a broker portal work with a batch-only policy system?

A broker portal works with a batch-only policy system through an integration layer that loads each batch, validates it and serves current data to the portal. The portal never queries the core directly.

The integration layer does three jobs:

1. Load and validate each batch file, rejecting records that fail the rules before brokers see them.
2. Serve the validated data to the portal through documented APIs.
3. Queue changes the broker makes, then pass them back to the core in the form it accepts.

Where brokers need data the batch cannot give, discovery tests what other interfaces the core offers, such as database views or vendor APIs. That test usually shapes the whole plan, which is why it comes first.

The strangler pattern is an approach where new services gradually take over functions from the legacy core until the core can be retired. The broker portal is often the first function to move, because it has clear users and a narrow data need.

How do insurers choose between a package, a custom build and core replacement?

Insurers should buy a package for commodity functions and build custom services around the core where products, channels or evidence needs are distinctive. Compare the options on what matters to a CTO and a risk committee:

Option	Fit to your products	Making later changes	Ongoing effort	Exit and ownership
Off-the-shelf package	Standard products only	Wait for the vendor roadmap	Upgrades on the vendor’s schedule	Vendor controls roadmap
Configure existing platform	Limited by vendor model	Vendor change requests	Change requests negotiated with the vendor	Vendor controls roadmap
Custom build around the core	Built to your products	Your own backlog	Your support, patching and hosting	You own the code
Full core replacement	High, once complete	Frozen until migration ends	Highest: two systems in dual running	Depends on new vendor

Use these rules:

• If the function is the same across insurers, such as payroll or ledger, buy it.
• If a package needs heavy customisation to model your products, build the service around your core instead.
• If the core vendor is ending support, build the new services first, then migrate data in stages.

The deciding question for an insurer is not build or buy. It is which option lets you prove you can recover an important business service within its impact tolerance.

Ownership also matters to the Prudential Regulation Authority (PRA). SS2/21 gives a full chapter to business continuity and exit plans for outsourcing. Code you own, with documentation another team can pick up, makes an exit plan credible.

When is building around the core not the right choice?

Building around the core is the wrong choice for commodity functions and for an insurer that cannot sustain ownership after launch. Custom software needs support, patching and change every year, and a product owner who can make decisions each sprint.

The common objection is: “We should just replace the legacy system.” Full replacement of a policy administration system means migrating every live policy, dual running and regression testing every product at once. Few insurers can absorb that alongside business as usual. Building around the core reduces the risk in steps, and still ends with the core retired.

Internal politics matter too. Procurement wants fewer suppliers, underwriting wants new products next quarter and compliance wants evidence first. A phased plan with a working release at the end of each sprint gives each of them something to sign off.

Waiting is not neutral. Every year on an unsupported core adds maintenance effort and security exposure, and the 2027 FCA reporting requirements will ask for evidence of incidents and third-party arrangements that a fragile core makes harder to produce.

What should a CTO at an insurer do first?

A CTO should first list the three services the policy administration system blocks today and the data each one needs from the core. That list turns a vague modernisation debate into a backlog.

Take these steps this week:

1. Name the three blocked services, such as a broker portal, a claims workflow or a product launch.
2. Write down the data each service needs and how fresh it must be.
3. Check what the core offers for each: batch files, database views or vendor APIs.
4. Mark which services support an important business service, so the risk committee sees the resilience case.

Frequently Asked Questions

What does discovery produce before an insurer commits to a build?

Discovery produces a specification, a prioritised backlog and a tested view of how the legacy policy administration system can share data. It follows the GDS discovery phase approach: understand users and constraints before choosing a solution. Discovery can also conclude that a package fits better, which is a valid outcome.

What is the main risk of building around a legacy core?

The main risk of building around a legacy core is integration, because legacy systems often expose data only through batch files or direct database access. Discovery tests those interfaces first, and independent penetration testing to NCSC guidance checks the finished software. Short sprints keep any problem small and visible.

Will we be locked in to the supplier that builds the new services?

An insurer should not be locked in to the supplier that builds its new services. Own the data, content and codebase outright, and require documentation and a structured handover so another supplier or your own team can take over. PRA SS2/21 sets out expectations for exit plans, and ownership is what makes an exit plan workable.

Can the new services work alongside our in-house developers?

New services can be built alongside in-house developers, with your reviewers testing each sprint deliverable and shaping the next one. Code goes through peer review and the same automated quality gates, whoever writes it. Training, documentation and recorded guides then let your developers maintain the software after handover.

Do new broker and customer portals need to meet accessibility standards?

New broker and customer portals should meet WCAG 2.2 Level AA as a minimum, so disabled customers and brokers can use them. Consumer Duty also asks firms to support customers in vulnerable circumstances, and an inaccessible portal works against that. Thornacre’s accessibility service tests against WCAG 2.2 before launch.

How do we start?

Start by listing the three services your policy administration system blocks today and the integration each one needs. Thornacre’s custom software development service then runs discovery workshops with your underwriting, compliance and IT leads to agree which service to tackle first. For data moving off the core, see data migrations.

---

Email your list of blocked services to hello@thornacre.com and Thornacre will run a workshop with your IT, underwriting and compliance leads to decide which to build, buy or migrate. For connecting the core to your CRM, see CRM and ERP integration.

This article is general guidance only; consult your legal or compliance teams for your specific requirements.