Every insurer we spoke to had the same story: a migration programme that cost too much, took too long, and still didn't deliver the evidence the board needed. We built KeystoneMigrate because we lived that problem from both sides of the table – and nobody else was solving the root cause.
Between 2016 and 2019, I worked vendor-side on one of the largest personal lines PAS migrations in the UK market. A major insurer migrating 1M+ policies from mainframe to Duck Creek. I was the data lead on the vendor side. Tom Richardson – now my co-founder and CPO – was on the customer side, responsible for the platform the data was landing in.
We were looking at the same problem from opposite angles. And we were both watching it fail.
The migration consumed three years and eight figures. Not because the people were incompetent – the SI was one of the largest in the world, the vendor team was experienced, and the insurer had committed significant internal resource.
It failed because the methodology was wrong.
The team started with schema mapping. They built ETL pipelines based on data dictionaries. They tested individual transformation rules. Every sprint delivered working code. Every test case passed.
But the full-book reconciliation kept failing. Endorsement chains that looked correct individually produced wrong results when you traced the cumulative effect. Reserve calculations that matched at the policy level didn't reconcile at the portfolio level. Bordereaux outputs generated from migrated data couldn't be matched against source.
The problem wasn't any single transformation. It was the approach of treating insurance migration as a data movement exercise when it's actually a business logic preservation exercise.
Tom saw it from the customer side: migrated data arriving in his platform that looked structurally correct but was semantically wrong. Endorsement chains that the system accepted but that didn't reflect the actual contractual position. Reserve calculations that produced numbers but not the right numbers.
I saw it from the vendor side: a delivery team hitting every milestone on the project plan while the actual migration wasn't converging. More sprints, more code, more test cases passing – but the reconciliation gap wasn't closing.
After the programme ended, Tom and I both moved on – but we kept seeing the same pattern. Different insurers, different vendors, different SIs. Same structural failure.
The Big SI approach: Major consulting firms treat PAS migration as an enterprise IT programme. Agile sprints. DevOps pipelines. User acceptance testing. The problem: insurance migration isn't an IT exercise. It's a regulatory and actuarial exercise. The SI delivers working code, but the book doesn't reconcile.
The PAS vendor tooling approach: PAS vendors offer migration accelerators bundled with the platform sale. The promise is "we'll migrate your data as part of the implementation." The problem: the vendor's tooling is optimised for their target schema, not for understanding the source. They can load data efficiently, but they can't tell you whether the loaded data is correct.
The general ETL approach: Platforms like Informatica, Talend, or custom Spark pipelines. Technically powerful. The problem: they're built for data movement, not for insurance business logic. They can transform a record. They can't validate that an endorsement chain preserves the correct contractual position after transformation.
None of these approaches address the root cause: insurance migration requires evidence that business logic has been preserved, not just evidence that data has been moved.
The turning point came in H2 2025. An agricultural specialist insurer – Farm, Ranch, and Equine lines – had acquired a book stuck on a black-box legacy PAS. No documentation. No vendor support. No data dictionary. The previous vendor had walked away.
Tom and I delivered the migration ourselves, using the methodology we'd been developing since the major insurer programme. No product platform yet – just the methodology, applied by the team that built it.
The results:
This wasn't a proof of concept. It was a real engagement, with real policyholder data, delivered under real time pressure by a team of two.
The agricultural specialist engagement proved the methodology works. But it also proved that delivering it as a bespoke consulting engagement doesn't scale. The discovery techniques, the validation engine, the evidence generation – these should be software, not services.
That's what KeystoneMigrate is: the product we wish had existed when we were the ones running these programmes.
We're building it for insurance specifically. Not "data migration with an insurance template." Purpose-built migration control for an industry where the data carries regulatory obligations, policyholder contracts, and reserve calculations that actuaries have to sign off on.
We're a small team. We've done this work ourselves. We're not selling a vision of what migration could look like – we're productising the methodology we've already proven works.
The insurance industry has a migration problem that's costing carriers millions and preventing them from adopting modern platforms. Nobody was solving the root cause. That's why we built KeystoneMigrate.
Facing a migration that's stalled, failed, or not yet started? Book a discovery call to talk about 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