What to keep in mind when you move your insurance book

By: Louw Hopley, CEO and co-founder of Root

A software architect’s guide to replacing policy administration systems

Taking the leap to undertake a Policy Administration System (PAS) replacement can be an intimidating prospect. On the one hand, there are myriad benefits in making the move. On the other, there are complexities, dependencies and risks that could make the process look as daunting as carrying out a heart transplant.

With the right planning and expert help, PAS replacement can be executed seamlessly and with limited risk, giving your insurance business a new engine.

Having helped many different organisations replace their PAS, here are some key points to bear in mind:

Step 1: When do you really need to replace your PAS?

Very few insurance companies are in a position to avoid considering a PAS replacement. Some want new systems to support innovation and deploy emerging technologies. Others have existing systems that are too challenging to manage and are limiting for business.

Some companies’ data is being held hostage by previous service providers, who may also be gatekeeping changes. In those cases, any changes are expensive and take a long time.

Your PAS could also be restricting innovation and new product releases if it is inflexible and purpose-built for a specific product type.

If your existing system is not flexible enough to accommodate new products, doesn’t cater for real-time embedded digital distribution, or has poor or non-existent APIs that make it hard for partners to integrate with you, it may be time to move on.

Step 2: Assess your risks

Many of the concerns around PAS replacement are warranted. Potential data integrity issues due to the book move are a key concern.

A new system could come with increased complexity and more systems to look after – particularly if there are delays in moving the book and you end up running two systems alongside each other.

There could also be unrealistically high expectations for the new system among stakeholders and users in the organisation. Or a temptation to overreach by trying to address all the organisation’s pains and dreams in one fell swoop.

On the other hand, there is also the maddening tendency to end up simply replicating exactly what you did on the old system on the new system (even though there is often no clear reason or understanding why you did it that way in the first place). If you do that, you’re just adding friction and missing the opportunity to make a big leap forward.

A good way around most of these risks is a Proof of Concept. Play around and test the solution in your environment before committing to a wholesale replacement.

Step 3: Decide on your guiding principles

In our experience, the insurance companies that get the best results are explicitly clear on their goals and follow four basic principles when replacing a PAS.

Principle #1: Lean into the opportunity – Sunk-cost fallacy is not only about letting go, but also about realising that holding on to unnecessary old technology will materially increase maintenance overhead and costs in the long term. This is an opportunity to set your organisation up for the future. Take it.

Principle #2: Simplify the environment – Reduce risk surface area, take out systems where possible, and avoid keeping or creating unnecessary dependencies. 

Principle #3: Take a holistic architecture view – Modern technology solves many of the previous generation technology problems out of the box. You used to need separate systems for pricing, communications and premium collection. These days, there are low-code insurance systems that can tackle all of these in one.

Principle #4: Replicate first, then iterate – Make sure you have the basic functionality in place before you start iterating. This allows your business to keep running without too much disruption, and lets you improve the system over time.

What is the right way to do a PAS migration?

We’ve seen three main options for PAS replacement, but there’s no silver bullet that works for everyone.

Option #1: Run the new system completely separately from the legacy stack, end-to-end 

Keep old policies on the old system, sell all new policies on the new system, and let the old book run off. The pros of this are that no major book move is needed, and you can slowly migrate internal users from the legacy system to the new system. This approach also gives you the freedom to truly innovate on new product design right away.

The cons, however, are that you will have to maintain two systems until the book is run off, which may be costly.

Option #2: Run the new system on top of the legacy system, syncing newly sold policies to the legacy PAS as you go

This gives you the option to fall back at any time if things don’t work out. Conversely, it also gives you the opportunity to lean in when things go well by turning off the legacy system behind the scenes.

The advantages of this are – again – that you do not require a book move, and you can rapidly innovate using the new system to distribute new products through new channels. Meanwhile, day-to-day operations continue as normal on the old system. Do bear in mind, though, that the new system’s potential may be hobbled by shortcomings and inflexibilities in the legacy system to which you have to synchronise the data. 

Another disadvantage is that you have to maintain two systems until the book is run off, with the associated extra costs. There are also the risks and challenges of integration between the old and new systems.

Option #3: Full system migration/replacement

This approach entails a complete move of the policies from the old system to the new one. You can innovate more effectively and avoid the costs and complexity of dealing with two systems.

However, this does mean a full book move and all the data integrity risks involved.

Step 4: Take action

Each alternative comes with its own pros and cons, so the ideal approach depends on the specifics of your business, its risk appetite and its budget.

Planning paralysis is a real risk in PAS replacements because the stakes are so high. That is precisely why it’s important to get some momentum going, and start taking action as soon as the general approach and strategy have been decided.

In our experience, the momentum created by a Proof of Concept on one small aspect can do wonders to crystallise thinking, and guide iterations. This principle is applicable across the board: we have seen all shapes and sizes, complexities and requirements, and they have all found a way to move forward with approaches that suit them.