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.
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.
You might want to read these awesome related
posts Insurance Data Migrations
