On-the-Fly Product Migration
Product Migration challenges
Product migrations in insurance are usually a tedious and time-consuming task. Typically, when a new version of an insurance product is launched, the existing portfolio must be migrated so that the new product features can be used. When you have a large portfolio of insurance policies, doing that migration to each one of the policies can take an inordinate amount of time or computing power. Imagine that you have a life insurance portfolio of 10 million policies, which is not unusual, migrating all these policies to the new product features overnight can present a massive scaling problem.
While there are several options to make this migration feasible, starting early with the migrations so that all migrations are completed before the official product launch, is not always the best solution. This approach may result in the migrations being in the system before their effective dates, leading to “out of sequence endorsements” when clients need other changes made to their policies. This should be avoided if possible.
On the other hand, starting the product migrations only on the effective date of the new product version can create problems when clients want to view their policy using your online client portal. This is because they may not see the modified policy version simply because the migrations may not be complete yet. To minimize the duration in which this problem might arrive one could upscale the system by launching many more pods in a Kubernetes style deployment of LUNOS. This however may not be a cost-effective solution.
This article explains how product migrations are done with LUNOS in a very cost-effective way without impacting customer service.
LUNOS Solution to the Product Migration Problem
With LUNOS, migrating a policy from one product version to the next is done with a policy transaction defined on the new version of the product. Note that this policy transaction cannot be defined on the old version of the product because when the old version of the product was published, we did not yet know what new version of the product we would migrate to, or when this migration would occur. Therefore, product migrations are always driven from the new product version.
To explain this process, we start with the fact that in LUNOS a product is an object. In fact, it is a whole tree of objects related together, but to keep things simple, here we will keep that tree very small. The starting point is a set of policies that is based on the old version of the product.
This diagram only shows one policy, but in reality, there could be several million policies based on the same product which the policies know as their specification.
When the product modelers introduce a new version of the product, it leads to the following diagram:
In addition to creating the new version of the product, the product modelers also added the “migration request specification”. In LUNOS, a Request Specification is the definition for a transaction (a Request) that can be performed on an Agreement. In this case, the Migration Request Specification defines the Migration Requests which will take the old policy versions to new versions based on the new product version.
Typically, the Request Specification defines the logic that needs to be executed to populate new data in the new policy versions. This logic will be specific for every product migration, but the mechanism to create the new policy versions based on the new product versions and the information present in the old policy versions is standard functionality in LUNOS.
The Product Migration
A product migration is just another policy transaction. It is executed by creating a migration request based on the migration request specification included in the new product version. Such a product migration can therefore be done at any time, so we’ll do it when it is most convenient. But first, let’s look at how product migrations work.
In the previous step, the new product version was launched. Now, when we want to migrate policy version 4.0.0, the migration request is first created based on the migration request specification for the new product version. The old policy version (4.0.0) is used as the target of the migration request. The migration request is then executed, and the LUNOS implementation for the migration process creates the new policy version using the new product version and the data in the previous policy version. This leads to the situation in the diagram below.
Migration request transactions can be executed at any point in time using the LUNOS platform, which offers flexibility in scheduling batch jobs to migrate the entire portfolio without impacting the performance of the policy administration system. However, this approach presents a challenge when a client requests to modify a policy that is still being migrated, leading to potential delays in servicing their needs.
On The Fly Product Migrations
To resolve this problem, we have introduced the technique of the “on the fly product migration”. This technique involves forcing a product migration before acting on the client’s requests in the online customer portal. Even if the policy has not yet been migrated, the migrated policy version must be displayed to the client. To achieve this, LUNOS intercepts the client’s request, triggers a product migration, and executes the client’s request only when the product migration is complete, using the migrated policy data. It is important to note that coordination between the batch job and the “on the fly” transaction must be ensured, to avoid working on the same policy at the same time.
Conclusion
Using this solution, Silvermoon clients have been able to migrate portfolios of several millions of policies without having to increase their computing power and whilst keeping customer service uninterrupted.
