Closed books may stop writing new business, but they are still relationships to be managed for decades across servicing, compliance, customer and operator experience.

Payments must still be processed. Customers continue to make enquiries and request changes. Policies are reinstated, amended and claimed against. Insurers must produce reports, investigate exceptions and show that regulatory obligations are being met.

Depending on the products involved, this activity may continue for decades.

That is why closed-book modernisation has to address more than the ageing platform. Moving policy data may reduce reliance on a legacy system, but it does not automatically change how the portfolio is serviced.

When the operating model is left untouched, manual processes, fragmented workflows and specialist dependencies are often recreated around the new platform.

Take a failed premium payment. Before migration, the exception might be exported to a spreadsheet, matched manually to the relevant policy and emailed to an operations team. Customer service may create the communication in a separate system, while finance updates another record once the payment has been resolved.

Focus only on the policy data and that process may survive almost unchanged. The policy sits on a modern platform, but the spreadsheets, email handoffs, manual reconciliation and reliance on individual knowledge remain.

The insurer has replaced the system while keeping the operating dependency around it. Did you simply want a faster horse or the best customer experience at the lowest operating cost with the power of automation ?

The book should be easier and safer to run after migration, not simply housed on a newer platform.

Costs do not fall in line with policy volumes

Insurers expect closed books to carry ongoing servicing costs. What matters is whether those costs remain proportionate to the size and strategic value of the portfolio.

As active policy numbers decline, the supporting environment rarely shrinks at the same rate. Hosting, infrastructure, security, integrations, specialist support, reporting processes and business-continuity arrangements may all remain necessary.

Operational demand continues as well. Payments fail, customer details change, policies are reinstated or altered, and claims, reconciliations and regulatory reporting still have to be handled.

Policy volumes fall, but much of the supporting complexity remains.

The full cost can be difficult to see because responsibility is spread across the organisation. Finance may own a reconciliation. Operations may handle a payment exception. Technology may maintain a reporting workaround. Customer service may need support from several teams before it can answer a policyholder’s question.

Each activity can look manageable in isolation. Together, they create a costly and increasingly fragile high risk operating model.

Delay, shifts risk rather than removing it

Closed-book migrations are often delayed because they have traditionally been expensive, disruptive and difficult to control. Those concerns are reasonable and traditionally accurate.

The data may be poorly documented. Product rules may have changed repeatedly over time. Important knowledge may sit with a small number of specialists.

Keeping the current environment in place can still increase risk.

Legacy risk rarely arrives as one major outage. More often, it builds gradually through workarounds and dependencies.

A spreadsheet becomes essential to a compliance process. A bespoke script is understood by one person. A necessary change is postponed because no one can predict its wider effect. A straightforward customer enquiry reaches a specialist team because the frontline system cannot show the full policy history.

Over time, the organisation becomes more dependent on institutional memory simply to maintain the status quo. The Legacy Tax builds.

Postponement may reduce the immediate risk of change, but it can make the eventual change more expensive and harder to control exposing the business further.

Define the operating model before planning the migration

Before migration begins, the insurer needs to decide how the closed book should run afterwards.

That means deciding which servicing activities can be automated, how payment exceptions will be managed, where human judgement remains necessary and how compliance evidence will be captured.

Operations teams need access to the right policy and customer information instantly. Customers want clear simply and easy ways to manage payments and ask questions or make changes. Existing workarounds should be assessed deliberately rather than reproduced by default.

Without a defined target operating model, the migration team is effectively being asked to rebuild the current environment somewhere else.

A successful implementation programme should reduce the manual, repetitive and predictable work and accelerate visibility of issues to specialist roles. Moving the policy records is one part of that job, delivering the flexible core for automation and approval of agentic solutions must be a key consideration.

A policy record carries rules and history

Closed-book migration is difficult because insurance data is more than a collection of fields.

A policy record reflects product rules, transaction histories, contractual obligations and financial outcomes. Its meaning may depend on the order in which events occurred, the way a status was calculated or an exception applied many years earlier.

Correct field mappings are only one part of validation.

Every value can land in the expected target field while the policy itself behaves incorrectly. Validation must show that policy status, premium calculations, paid-to dates, ownership changes, reinstatements and financial outcomes have been preserved.

The programme has to test the meaning of the data, not just its structure.

AI can help with parts of this work, provided its role is clearly controlled.

AI-assisted analysis can help teams interpret unfamiliar files, identify possible relationships, propose mappings and surface anomalies earlier. This means specialists do not have to begin every investigation with a blank mapping spreadsheet.

The accountable parts of the process still need to be transparent and repeatable. Approved transformations, validation, reconciliation and output generation should be deterministic. Subject-matter experts remain responsible for resolving ambiguity, confirming business meaning and signing off the result.

Used this way, AI reduces investigative work and leaves experienced people to concentrate on decisions that require judgement.

Servicing events need to trigger connected work flow

The target environment also needs to manage the operational events that continue throughout the life of the portfolio.

Return to the failed-payment example. In a fragmented environment, someone has to identify the event, locate the policy, reconstruct the customer context, decide what should happen, assign the work and generate a communication. The final action may then be recorded in another system or spreadsheet.

In a connected operating model, the payment event triggers the relevant servicing workflow. The policy and customer context are already available. Tasks and communications can be generated, exceptions routed for review and the final action recorded through one traceable process.

The aim is to reduce avoidable handoffs, make exceptions visible and give teams a clear view of workload, ownership and outcomes.

This also matters for customers. Policyholders experience one insurer, not a collection of acquired portfolios, product generations and administration systems. The age of the platform supporting their policy should not determine the quality of service they receive.

This infrastructure is also critical for tasks completed by Agentic AI and binary automated task completion.  System of record, system of action and system of automation.

Judge the programme by the operation it leaves behind

Technical milestones matter. Records must be extracted, mappings approved, data loaded and the legacy system decommissioned.

Those milestones alone do not show whether the programme has succeeded.

After migration, the insurer should be able to demonstrate that the cost to service each policy has fallen, manual handoffs and reconciliations have reduced, and teams have a clearer view of exceptions and ownership.

The predictable and repeatable tasks are autonomously completed and highly skilled operators are managing the complex tasks faster.

Compliance evidence should be produced in real time with connected reporting and data insights. Dependence on specialist knowledge should be lower. Customers should receive faster and more consistent service.

Decommissioning the old system is an important milestone. The programme is complete only when the closed book is materially simpler, safer and more efficient to run. At Simfuni, we work with life insurers to modernise the systems and processes behind closed books. Much of this work happens behind the scenes, but it has a direct impact on cost, risk and customer trust. In our experience, when systems make it easier for people to run the book well, operations become simpler and customers receive a more consistent service.

We’ve developed a closed-book guide to help insurers understand where cost, risk and legacy dependency are building, and think through the data, migration, servicing and operating-model decisions involved in modernisation.

‍