The methodology we built after years of watching insurance migrations fail for the same structural reasons. Three phases that turn migration risk into auditable evidence – drawn from real engagements where we achieved 96% source-to-target data mapping from completely undocumented systems.
Most insurance PAS migrations fail before they start. Not because of technical incompetence – because they begin with a fundamental misunderstanding of what migration actually requires.
I know this because I've been on both sides. As CPO of an insurtech PAS platform, I built the system that migration data had to land in. I saw first-hand what happened when poorly mapped data arrived: endorsement chains that referenced non-existent policy versions, reserve calculations that silently produced wrong numbers, bordereaux outputs that couldn't be reconciled against source.
The Plan/Run/Prove methodology exists because every migration team encounters the same failure modes. The question isn't whether you'll hit them – it's whether your methodology surfaces them before or after cutover.
A typical PAS migration project starts with a kickoff meeting, a data dictionary, and a schema mapping exercise. Three months later, the team discovers that the data dictionary was aspirational – it describes what the source system was supposed to do, not what it actually does.
Endorsement chains reference policy versions that were never formally recorded. Bordereaux outputs depend on batch jobs that run at 2am with hardcoded business rules nobody documented. Reserve calculations work differently for different lines of business, and the only person who knows why left the company two years ago.
At this point, most projects do one of two things: they push ahead with incomplete knowledge and hope the gaps close during testing, or they stop to conduct a comprehensive discovery phase – which the business interprets as "the migration is already behind schedule."
Before writing a single migration rule, we map the entire book. Not the data dictionary version – the reality.
This is where AI-powered discovery changes the equation. In our most recent engagement – an agricultural specialist insurer with Farm, Ranch, and Equine lines stuck on a completely undocumented black-box legacy PAS – we used automated schema inference and DataArc mapping to rebuild what didn't exist. No documentation. No data dictionary. No vendor support for the source system.
The result: 96% source-to-target data mapping achieved programmatically, in a fraction of the time traditional discovery would have required.
What the Plan phase actually produces:
Policy class inventory with usage patterns. Not just "what classes exist" but "which classes have active policies, what endorsement types attach to them, and what business logic governs the transitions." For the agricultural specialist, this meant mapping Farm, Ranch, and Equine policy variants along with their custom rating structures and class-specific endorsement rules.
Endorsement chain reconciliation model. How endorsements actually chain together in practice – including the cases where the third endorsement references terms modified by the first, but the source system treats each as an independent record. This is where most migrations silently break.
Business logic extraction from batch jobs. The logic that exists only in scheduled jobs, stored procedures, and the spreadsheets underwriters maintain because they don't fully trust the system. We've seen custom rating algorithms that existed solely in nightly batch processes with no UI representation.
Reserve calculation re-derivation rules. How reserves are actually calculated for each line of business, including the exceptions that the actuarial team knows about but never formally documented.
Deliverable: A migration blueprint validated by underwriters, actuaries, and compliance. Not a technical schema mapping – a business-verified model of the actual book.
KeystoneMigrate executes within the client's data platform (Databricks, Snowflake, Fabric, or similar). Policy data never leaves their security perimeter. The migration runs in parallel with the live system – no downtime, no disruption to business-as-usual operations.
This matters for insurance in ways it doesn't for other industries. Policyholder data is regulated. Moving it to a vendor environment for transformation creates data sovereignty issues, regulatory risk, and audit complications that most migration vendors handwave away.
When anomalies surface (and they always do on complex books), the validation engine flags them in real time:
Endorsement chains that don't reconcile are quarantined, investigated, and resolved before they corrupt downstream records. We validate chains as chains – not individual endorsements in isolation.
Reserve calculations that produce different results are flagged with full derivation trails so actuaries can determine whether the source or target is correct. (In our agricultural specialist engagement, we found cases where the source system had been calculating incorrectly for years – the migrated version was actually more accurate.)
Bordereaux output mismatches are traced to the specific policies causing variance, with drill-down to the transformation rule that produced the discrepancy.
The migration team can see progress. The underwriting team can inspect results. 100% programmatic – zero manual rekeying.
Deliverable: Checkpoint validation reports at every stage. Anomaly resolution logs. Full data lineage for every migrated record.
The Prove phase is where this methodology diverges most sharply from traditional approaches. We don't ask clients to trust that the migration worked. We prove it.
The deliverable isn't a test report. It's auditable evidence that the migration preserved the business meaning of every policy, every endorsement, and every calculation in the book.
In our agricultural specialist engagement, we delivered this in 6 months – from engagement to completion. The typical timeline for a migration of comparable complexity is 12-18 months. The difference was the methodology: Plan compressed discovery by using AI-powered inference instead of manual documentation archaeology. Run eliminated manual rekeying entirely. Prove produced evidence that the board could actually evaluate, not a technical report they had to take on trust.
Deliverable: Full-book reconciliation report. Regulatory evidence pack. Actuarial sign-off. Board-ready migration completion summary.
Insurance PAS migrations are different from typical data migrations because the data isn't just records – it's regulatory obligations, policyholder contracts, and reserve calculations that actuaries sign off on.
A failed migration isn't just inconvenient. It can trigger regulatory intervention, breach policyholder contracts, and corrupt reserve calculations that underpin solvency reporting.
The Plan/Run/Prove methodology addresses this by making evidence the primary deliverable at every phase. Not documentation that describes the plan – evidence that the plan worked.
We built this methodology because we needed it ourselves. Now we're building KeystoneMigrate to make it repeatable for every insurer facing the same problem.
Want to see how this methodology would apply to your migration? Book a discovery call to discuss the specific challenges of your book.
Get insurance migration insights delivered to your inbox. No spam — just methodology updates, industry analysis, and product news.
View our Privacy Policy