Migration of insurance data often turns out to be a nightmare. Policyholder data in legacy systems do not fit the expectations of new systems: Mandatory factors required to calculate premiums in the new world are just not available for migration, underwriting rules in the new world do not accept legacy data, premium cash flows do not match. Addresses and customer data in particular do not pass validations of modern address validation tools.

If data is migrated incorrectly, the carrier will lose goodwill as angry policyholders complain. On the other hand, if the time taken to fix all issues related to migration is too high, the benefits of moving to the newer and presumably better system will be lost.

Given these conflicting constraints of time and quality, do we plan a successful insurance data migration project ?

Here are a few pointers:

a) Start with a gap analysis:

A business analyst should identify gaps from the frontend. While data analysts profile data and record data model gaps from backend. Covers that are no longer offered and retired products/policies in particular need to be reviewed critically to decide whether they justify migration.

b) Prioritize :

Use the profiling information gathered in study phase to determine how many policies are affected by each requirement. For example, if subrogration functionality been used only by 1 policy in 250,000, then it’s low priority

c) Iterate, iterate and re-iterate :

Data drives migration projects. Even if you have worked out a complete mapping, you have to take policies through their entire life cycle (endorsements, mid-term adjustments, addition of covers ,deductibles and so on) to be sure that they have been migrated correctly. Plan for at least 3 rehearsals before you go-live with full size loads to be certain that the migration works for all policies. Be sure to test the result with all interfaces (such as the ISO claims search, the direct debit bank interface – using stubs if necessary)  in the trial runs.

d) Dont try to solve all problems:

If you do that, you will never go live. Or it may take so much time to go live that the whole competitive advantage of moving to the new system will be lost.

e) Do not mix data cleaning and data migration:

Data cleaning is a separate project by itself. This is not to say simple technical activities like removal of junk characters cannot be included in data migration. It is activities like address cleaning and deduplication of contacts that should not be mixed with policy data migration.

f) Dont mix the migration project with other initiatives :

I add this because I have seen many migration projects derailed because of a sudden decision to upgrade the database or the programming language.

Do let us have your views,experiences and comments on the above suggestions. Also, be sure to check out the insurance data migration case studies on this site if you need more information.

Posted by Sanjay Rao
Comments (1)
March 22nd, 2010

Comments (1)

Ankur MIttal - August 9th, 2010

Nice article..well thought out points..

Comments are closed.