Insurance platforms accumulate rules rather than features. A policy administration system written fifteen years ago encodes every product variation, regulatory change and underwriting exception the business has ever shipped, and most of it is undocumented. That is why modernisation quotes vary so widely: the code is the specification, and nobody has read all of it. The cost is driven far less by the technology target than by how much of that embedded logic has to be recovered before anything can move. This is core insurtech work.
01The cost is in the rules, not the rewrite
Teams estimate a modernisation by sizing the new system. That is the wrong denominator. The expensive part is establishing what the current system actually does, because the behaviour that matters is spread across stored procedures, batch jobs, correction scripts and a decade of patches applied under deadline.
A product that looks like four variants in the brochure regularly turns out to be several dozen in the rating engine, each with its own effective dates and grandfathering rules. None of that appears in a requirements document, and discovering it late is what turns a fixed-price engagement into a dispute.
| Area | Share of effort | Why it runs over |
|---|---|---|
| Rule archaeology | Largest single block | Behaviour lives in code, not documentation |
| Data migration | Substantial | Historic policies carry states the new model forbids |
| Integrations | Substantial | Brokers and reinsurers each have bespoke feeds |
| New platform build | Smaller than expected | Well understood once the rules are known |
| Parallel running | Persistently underestimated | Two systems, reconciled daily, for months |
02Do not migrate the back book first
The instinct is to move everything at once so the old system can be switched off and its licence cost recovered. In practice the back book is the hardest part of the estate: old products, expired variants, policies in states the new data model was never designed to represent.
Writing new business on the new platform while the back book runs where it is puts the modern system in front of customers early, generates revenue against the investment, and leaves the archaeology to run at a sustainable pace. The old system stays until the last policy on it expires, which is a cost, but a smaller and far more predictable one than a big-bang cutover that fails.
03Regulatory reporting is a hard constraint, not a phase
Insurance reporting obligations do not pause for a migration. Whatever else changes, the returns still have to be produced on the same schedule, from data that is now split across two systems with different models.
Teams that treat reporting as a late workstream discover in month seven that the new schema cannot answer a question the regulator asks quarterly. Build the reporting extract against the new model early, run it in parallel with the existing one, and reconcile the outputs every cycle. Divergence found in a test cycle is a bug; the same divergence found in a filing is an incident.
- Identify every statutory and management report the current system feeds before design starts.
- Confirm the new data model can answer each one, including the historic comparatives.
- Run both extracts in parallel and reconcile line by line, not in aggregate.
- Keep a documented explanation for every accepted difference, because auditors will ask.
- Treat an unexplained variance as a release blocker.
04Integrations carry more risk than the core
A policy platform is rarely a closed system. Broker portals, aggregator feeds, reinsurance bordereaux, payment providers, document generation and claims systems all attach to it, and most of those interfaces were built to whatever the counterparty could accept at the time.
Each integration has an owner outside your organisation whose timeline you do not control. Enumerate them early and get written agreement on who tests what and when. The integration that nobody claimed responsibility for is the one that fails in production, and the counterparty's next available test window is often weeks away.
05What a credible estimate looks like
Any fixed number offered before the rule archaeology is done is a guess presented with unearned confidence. The honest structure is a paid discovery that produces a real inventory of products, rules, integrations and data states, followed by an estimate that the discovery actually supports.
That discovery is not a formality to get through. It is the deliverable that determines whether the rest of the programme is estimable at all, and a partner who offers to skip it is transferring risk to you while appearing to remove it.
| Question | What a weak answer sounds like |
|---|---|
| How many product variants are live? | "We will confirm during delivery" |
| Which rules have effective dating? | "The new engine handles that" |
| What states exist in historic policy data? | "We will clean it during migration" |
| Who owns each external interface? | "The client will coordinate" |
| How long is parallel running funded for? | No answer at all |
06Sequencing that survives contact with the business
Modernisation competes with the roadmap for the same engineers. A programme that freezes product change for eighteen months will be overruled the first time a competitor launches something, and the resulting scope negotiation usually damages the architecture.
Plan for the business to keep shipping. That means the new platform has to absorb product changes while it is being built, which in turn means the rating and rules layer must be configurable rather than coded. It is more work upfront and it is what makes the programme politically survivable.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.