Owen Greenwood, Client Partner – Insurance
For insurers managing more than one policy administration system migration, there is a simple question worth asking:
How much of the work from the first migration should have to be done again?
The answer should not be all of it and that is the thinking behind our factory approach to PAS migration. It replaces a one-off migration mindset with a more repeatable approach. Teams can reuse the work they do to understand the source, map it to the target, build the transformation logic and test the migration across subsequent migrations where appropriate.
That matters because insurers are rarely dealing with a single migration in isolation. Often there are multiple PAS migrations to manage, potentially into one future-state system. M&A can make this even more pronounced, with several legacy systems needing to be brought into a more consolidated target environment.
Treating every one of those migrations as a completely separate exercise can create unnecessary effort and cost.
The opportunity is to build an approach that becomes more efficient as the programme progresses.
The factory should start with the source and the target
So where should the starting point be? It’s not automation for automation’s sake. It’s understanding the data properly.
For each migration, the team needs to assess the source data in detail, including its structure, quality and overall data model. From there, the team needs an equally clear understanding of the future-state target.
Our teams have worked with a number of major policy administration system providers, including Acturis, Open GI and Insly, so in many cases there is already familiarity with the target data models and frameworks.
That matters because PAS migration is not simply about extracting data from one system and loading it into another. The team has to map the source to the target.
For each relevant element of data, the team needs to understand where it belongs in the future state and what transformation is required to get it there.
Sometimes that transformation may be relatively simple. The team may only need to convert a date into the format expected by the target.
In other cases, the transformation is more complex because insurance data itself is complex. Policy records can contain information relating to quotes, renewals, endorsements, cancellations, premiums, tax and risk, and the team needs to handle all of it correctly as the data moves. Owen also makes the point that this can become particularly challenging in more complex insurance products and specialty risk.
Once the team defines those mappings and transformations, it can build them into the migration engine. That engine is what creates the opportunity for repeatability
The first migration should leave something behind
Once the team has built the migration engine for a given client and target, it may be able to reuse a significant proportion of it.
The reason is straightforward: if the target remains the same, the team does not need to relearn the target model from the beginning every time. The source data will vary. There may be differences in structure, quality and content, and the team still needs to understand and handle those differences properly.
But variation in the source does not automatically mean the team needs to rebuild the entire migration approach. Where elements of the engine, mappings or transformation logic remain relevant, the team can reuse and adapt them for the next migration. That is exactly the advantage of a factory model: not pretending every source is identical, but avoiding a return to the starting point when the team has already completed and proven the work.
The first migration is therefore not only about getting one source into one target. It is also about creating a repeatable approach that can support the migrations that follow.
What does the 70% figure actually mean?
The level of efficiency will always depend on the individual situation, so the same percentage will not apply to every PAS migration.
But where a team is migrating multiple sources into the same target, and assumes roughly 30% variation between those source datasets, we believe around 70% efficiency can be a reasonable estimate.
A useful point is that once the team has built the initial migration capability, the programme may no longer need to recreate the same work from the beginning for each subsequent source.
There is also another efficiency that comes with continuity: the team develops much closer familiarity with the client’s data and its particular nuances over time. Knowledge here is crucial.
The team already understands the target. They know where complexity has appeared before, where it has already tested the transformation logic and it is more familiar with the client-specific nuances. The programme is not starting again from zero.
Repeatability should increase confidence
The factory approach is not only about reuse between migrations. It also changes how the team tests each individual migration.
Once the team has built the source-to-target mappings and transformation engine, it can run the migration repeatedly during testing. The aim is to prove the migration before the final cutover.
In practice, by the time the organisation reaches the point of moving the data for real, the team may already have executed the migration hundreds of times during testing.
That gives the team repeated opportunities to identify problems, refine the mappings and transformations, and improve the approach before the final migration takes place.
The outcome should be a much higher level of confidence in the source-to-target movement when cutover arrives.
That matters in insurance because the data itself can be difficult to move. Policies are time-dependent, not static records, and can contain interconnected information across renewals, endorsements, cancellations, premium, tax and risk.
The more complexity the team exposes and addresses during repeated testing, the less the final migration has to discover.
Repeatability doesn’t mean identical
A factory approach doesn’t mean treating every PAS, book or dataset as though it is the same because they aren’t.
Different source systems will contain different structures and different quality issues. Insurance products vary, and more complex risks can create more complex data. That’s why a repeatable approach still depends on experienced people who understand both the data and the insurance context.
In my opinion, the value comes from separating what genuinely requires a unique approach from what the team has already solved. The team may already understand the target model and a transformation pattern may already exist.
The team may already have proven parts of the migration engine repeatedly and they may already understand many of the client-specific nuances.
Those are assets. A good factory approach uses them rather than ignoring them and starting again.
A programme should become more efficient as it progresses
For insurers undertaking several PAS migrations, the first migration will inevitably involve significant upfront work. The source needs careful analysis. The team needs to understand the target, develop the mappings and transformations, and build and test the migration engine.
BUT that investment should create value beyond the first migration. Where the team uses the same target, much of the knowledge and capability it created initially can continue into the next migration.
That’s why we believe insurers should treat PAS migration as a repeatable capability rather than a sequence of disconnected projects.
The aim is not to make every migration identical, it’s to avoid rebuilding what the team already understands and has developed and proven.
In the right circumstances, that can create around 70% efficiency across subsequent migrations.
But the bigger principle is simpler: The first migration should make the next one easier to deliver.
That’s the real value of a migration factory.
How Dufrain can help
Whether you’re still deciding which PAS is right for your business, working through what should migrate and what shouldn’t, or looking to reduce the risk and effort of moving multiple legacy systems, we can help.
From early-stage PAS strategy and platform selection through to data migration and legacy retirement, Dufrain helps insurers make better decisions, reduce delivery risk and create a more repeatable route to PAS transformation.
Talk to us about your PAS transformation plans, or ask us how a repeatable migration approach could help reduce risk, accelerate legacy retirement and improve delivery efficiency.
For some of our FAQs on PAS Migration – view Owens recent article here.
View some of our client stories here.