The insurance industry has a migration problem. Not because insurers lack technical talent – but because PAS migrations are treated like enterprise IT projects when they're actually regulatory and actuarial exercises. We lived this on a 1M+ policy migration that consumed three years and eight figures before anyone admitted the methodology was wrong.
Every year, mid-market and regional insurers launch PAS migration programmes. Many stall during data mapping. Some reach UAT and discover unreconciled discrepancies. A few make it to production and immediately roll back because policyholder data doesn't match.
The pattern repeats across the industry. Different insurers, different vendors, different SIs – same failure modes.
We lived this ourselves. On a major insurer programme between 2016 and 2019, we were part of a 1M+ personal lines migration from mainframe to Duck Creek. The programme consumed three years and eight figures before the business recognised the methodology was wrong. Not the technology. Not the team. The fundamental approach to how insurance data was being migrated.
That experience is why Keystone exists. Here's what we learned about why migrations fail – and what actually changes the outcome.
The source system's data dictionary was written fifteen years ago based on what the PAS was supposed to support. The actual data structures diverged within six months.
Endorsements were supposed to follow a formal versioning model. Instead, underwriters found workarounds. Rider logic was supposed to be declarative. Instead, batch jobs apply business rules at 2am that nobody formally documented.
The migration team builds transformation logic based on the data dictionary. Three months into testing, they discover the dictionary and the data don't match.
On the major insurer programme, we watched this play out at scale. The data dictionary described a clean endorsement model with sequential versioning. The actual data had endorsement chains where the third endorsement referenced terms modified by the first, but the migration tool treated each as an independent record. By the time the team discovered the gap, they'd built three months of transformation logic on a false assumption.
Ask an underwriter how endorsement chains work, and they'll describe the intended process. Ask them to reconcile a specific endorsement chain with unexpected values, and they'll pull up a spreadsheet they maintain because "the system gets this wrong sometimes."
This isn't a knowledge gap. It's endemic complexity. The system has accumulated fifteen years of edge cases, workarounds, and undocumented logic. The people who understand it best are the ones who have learned not to trust it.
Traditional migration testing validates individual transformation rules. Does this policy structure map correctly? Does this endorsement type transform as expected? Does this rider calculate the right premium?
But insurance isn't about individual transformations. It's about actuarial accuracy across the entire book. A transformation rule can be individually correct and still produce a book that doesn't reconcile.
The migration passes testing. It fails reconciliation. We've seen this happen on programmes where every individual test case passed, but the full-book reconciliation revealed systematic drift in reserve calculations that only became visible at portfolio level.
Migration programmes treat risk as something to be managed through governance. Risk registers. Mitigation plans. Contingency budgets.
But the actual risk isn't that something unexpected might happen – it's that the migration might silently corrupt data in ways that only become apparent months later when regulatory reporting fails or an underwriter discovers a policy that wasn't migrated correctly.
Planning doesn't address this. Evidence does.
The migrations that succeed share a pattern: they treat the migration as an actuarial and regulatory exercise, not just a technical one.
Successful migrations produce evidence at every stage. Not documentation that describes what should happen – evidence that it actually happened.
The Prove phase in our methodology delivers specific evidence artefacts: full-book reconciliation reports, reserve calculation re-derivation with variance analysis, bordereaux output matching against source, and regulatory evidence packs. The board doesn't take the migration team's word for it. They have auditable proof.
Successful migrations run the transformation in parallel with the live system. No downtime requirement. No "big bang" cutover. Data is migrated, validated, and reconciled while the source system continues to operate.
This allows the business to inspect results before committing. Underwriters can review their own policies. Actuaries can verify reserve calculations. Compliance can check regulatory outputs.
If something doesn't reconcile, the migration doesn't proceed. No pressure to accept "close enough" because the cutover window is closing.
Successful migrations don't move policyholder data to a vendor's environment for transformation. The migration executes where the data already lives – typically in the insurer's own data platform (Databricks, Snowflake, Fabric, or similar).
This solves three problems simultaneously:
The insurance industry doesn't have a vendor problem or a talent problem. It has a methodology problem.
PAS migrations are being run like enterprise IT projects (Agile sprints, DevOps pipelines, user acceptance testing) when they're actually regulatory and actuarial exercises (evidence-based validation, full-book reconciliation, actuarial sign-off).
The shift isn't technical. It's treating migration as an evidence problem, not a delivery problem.
We learned this the hard way on a programme that cost eight figures and three years. The methodology we've built since then – and proven on a real engagement where we achieved 96% data mapping from a completely undocumented system in 6 months – exists to make sure other insurers don't have to learn it the same way.
Is your migration programme stuck in one of these failure modes? Book a discovery call to discuss what evidence-first migration looks like for your book.
Get insurance migration insights delivered to your inbox. No spam — just methodology updates, industry analysis, and product news.
View our Privacy Policy