Putting a P&C book into run-off stops the premium growth, but the operational headaches and data-silo nightmares are usually just getting started. The technology supporting it cannot be switched off. Existing policies still require servicing, and a long tail of claims, legal disputes, audits, and regulatory inquiries will continue to surface years after the final policy period ends.
The bigger decision comes when a carrier modernizes its core insurance platform. Millions of dollars can be tied up in closed or discontinued portfolios. Yet, moving everything to a new platform is rarely the right decision.
When our team at SimpleSolve works through modernization plans with a carrier, we look at what each product still needs to support and whether moving it would retire the legacy platform. Ultimately, there are three decisions to be made: Should the carrier migrate products that still need to operate, retain them on the existing platform if migration doesn't justify its cost, or archive products that need to remain accessible but no longer require policy administration?
That involves establishing what the product still needs to do and not reproducing everything the old system can do.
If a product is closed to new business, for instance, does the carrier still need its new-business quoting and eligibility workflows? Probably not. But it may still need the rating logic, coverage provisions, forms, and transaction rules required to service existing policies correctly.
That distinction can make a real difference to migration scope.
Insurance data is also part and parcel of the decision process. Moving policy records from one database to another isn't enough if the relationships between policies, endorsements, coverages, and transactions get lost along the way. A record of the historical transactions and effective dates may be essential to establish what coverage applied at a particular point in time.
At SimpleSolve, we emphasize data quality, prototyping, and reconciliation as part of policy data migration. Our guidance on data migration in PAS modernization explains why getting the data across is only part of the job.
Another important discussion is whether the migrated system can still handle the transactions required to service its remaining policies correctly. I'd test representative transactions in both environments and compare the results, including premium calculations where rating applies. Closing a product to new business doesn't remove the need to preserve the rules that govern its existing policies.
There's also the bigger financial picture. Moving one small book may not justify the expense if the carrier still needs the old platform for several other products. But migrating multiple books together could help eliminate licensing, infrastructure, support, and integration costs.
Before committing to migration, I'd look at both the cost of moving the product and what that move contributes to the larger platform exit.
When is it more viable not to migrate a discontinued product to a new system? That often comes down to whether only a small number of policies remain and if they rarely need servicing,
But there's a catch. The carrier needs to know what it actually costs to keep those policies there. There is always a cost attached - support, software licenses and infrastructure all add up. Also, legacy insurance software architectures were built as monoliths, so decoupling run-off products might be difficult if not impossible. For instance, they might still share the same centralized customer database as revenue-generating lines of business.
Before making that decision, the carrier also needs to check which business rules are still necessary. Years of system changes may have left behind workarounds that are no longer needed, alongside rules that still affect existing policies. Removing the wrong rule could cause problems when processing an endorsement or adjusting a premium.
If keeping the product where it’s at right now is the better option, assign someone to oversee it and review the decision periodically.
Most importantly, will keeping this one product force the carrier to maintain the entire legacy platform? If so, the cost of retaining it may be much higher than it first appears. Migrating the remaining policies or finding another way to support them may be more economical.
Eventually, a discontinued product will reach the point where the carrier no longer needs policy administration to support it and only needs to retain historical records. But an expired policy may still have an open claim or be involved in a dispute, so I'd confirm that the carrier no longer needs the old system for operational work before deciding to archive it.
But I wouldn't treat an archive as a database dump or a folder full of PDFs. The records have to tell the full story.
For instance, a commercial policy that has expired would have numerous endorsements during its lifespan. The final declarations page may not tell you what coverage applied before an earlier endorsement took effect. You may need the original policy, subsequent endorsements, applicable forms, effective dates, and transaction history to reconstruct the coverage on the off chance the need arises at any point in time.
All structured data needs the same care. A premium value without its associated coverage, rating context, transaction date, or policy version may be of little use when someone needs to explain how that premium was calculated.
Before archiving, I'd work with the appropriate business, legal, and compliance teams to establish what must be retained and why. Claims handling, litigation, regulatory examinations, audits, and customer inquiries may all require access to historical information. Retention periods vary by state and record type, so I'd never assume one rule fits every product. I'd also check whether any legal holds prevent records from being destroyed.
New York provides a concrete example of why this matters. Under 11 NYCRR § 243.2, insurers generally must retain policy records for six calendar years after a policy is no longer in force, or until after the filing of the examination report in which the records were reviewed, whichever is longer. Those records must include policy forms, declarations, endorsements, and information needed to reconstruct the policy's solicitation, rating, and underwriting. The rule also addresses retention of claim files after claims are resolved and closed. These are New York requirements, not a universal U.S. retention rule but you get the importance.
I'd also make sure authorized employees can find a policy, retrieve its records, and reconstruct its history without relying on the retired application. I'd test this with real-world questions: What coverage applied on a specific date? Which endorsement changed a policy term? Can the carrier retrieve the records needed to support a claim or respond to an audit?
Security and governance don't end when policy administration does, either. Access controls, audit trails, data integrity, and retention and disposal rules still apply.
My test is whether the archive can provide the required records, with enough context to establish what happened and when. If it can't, the archive isn't ready to replace the operational system.
The real test of a successful modernization is what a carrier can stop maintaining afterwards. A new platform may improve how the business operates, but the benefits aren’t complete if the old environment is still running and continues to consume resources. Planning for that exit from the outset helps carriers avoid simply adding another system to an already complex insurance technology environment.