Migrating 20+ insurance products to a new back office
I joined Insify to replace a back-office system. We ended up fixing it first, and replacing it two years later with a hybrid: an off-the-shelf insurance core with our own configuration layer and policy administration on top. This is how that went and what I would change.
Where we started
When I started, Insify had recently implemented a third-party back-office system, and the implementation had not landed the way the company hoped. The most important things worked. But the system had no dedicated owner, and small gaps were starting to cause real problems.
Two examples. Any change depended on the vendor's sprints, so the minimum turnaround was three weeks. And failed payments were neither recognised by the system nor retried. There were many more like these.
Fix first, replace later
The brief was to replace the system. Instead of building a new one from scratch right away, we agreed on something smaller: fix the obvious issues, add enough configurability to shorten our turnaround, and agree on ways of working that kept product changes and feature requests as efficient as they could be.
Over the two years that followed we kept looking at off-the-shelf alternatives. None of them would let Insify be as flexible as it wanted to be. The company's focus was the best possible customer experience for insurance, and most configurable platforms are built around one size fits all.
What we built
After two years the company had grown enough to invest in a hybrid. At its centre is an off-the-shelf insurance core system. Around it we built two things.
The first is a configuration layer. One product configuration generates both our internal set-up and the configuration for the core system. It covers:
- policy documents and pricing
- rules for mid-term adjustments and cancellations, including proration
- billing and charging
- access and policy administration rules for customer operations
The second is a full policy administration web interface, because the core system did not come with one. It handles quoting, on-the-spot changes to pricing and charge schedules, notes, a granular edit history, handover of quotes and changes between colleagues, and access control per field.
The goal was that a product configuration contains everything the system needs. Releasing a new product should never mean that customers can buy it but operations cannot manage it or cancel it. Everything had to be thought through before launch.
Decisions and trade-offs
Going this route meant building a lot in house, and that made testing very heavy. What we got in return was fast product delivery, which was the company's biggest ambition.
Keeping all configuration in code turned out to matter more than we expected. It made every change traceable and tracked. It also made the configurations a good fit for LLMs. By the time we went live, AI-assisted coding was becoming reliable, and teams could create new product configurations faster still.
What changed
More than 20 insurance products, with their active customers and payments, moved to the new set-up. Time to market for a new insurance product went from six to eight months down to two to six weeks. The product configuration work itself takes less than a week.
What I would do differently
We sliced the first release by product: one product live, end to end. That meant every part of the system had to exist before anything shipped. Slicing by feature would have given us smaller releases and a more agile process. There were financial reasons we did not go that way, but in hindsight it is the thing I would push harder on.