From buying a new car to investing in a new home, we get so caught up in the vision of the end goal that we tend to ignore what we consider small roadblocks. For instance, home buyers might underestimate the cost of homeownership or in the case of buying a car, ignore the out-the-door price and end up paying for unnecessary extras. Similarly, within the context of implementing a new policy administration system, data migration is often treated as an afterthought and that can be a costly oversight in migration efforts.
Here are some ground realities that insurance carriers should be aware of when policy data is migrated to a new policy administration system. The difference between success and failure often comes down to gaps in the preplanned strategy that should ideally identify every possible risk and set out a detailed contingency plan. This is one reason among many, why the SimpleInspire core platform implementation has a defined implementation time that we stick to.
Continuing with the car analogy used earlier, you are hardly interested in the logistics involved in getting the car to you, it is handled by your car dealership. This is not so when it comes to implementing a new policy core platform. Yes, the software platform is provided by your vendor but the data is yours and the software is effective only if the source data migrated to the new system is not subpar. That comes down to the technology vendor demonstrating a reliable roadmap to handle the complexity of the insurer's data.
During the evaluation of PAS platforms, most insurance carriers focus more on how the new system will match the present and future business requirements. It is just as important that the selection criteria should also deep dive into how legacy data will be handled during PAS migration. Does it all need to be migrated? Is it still relevant? Will migration be all at one go (big bang migration) or should it be phased out by product or statewide (trickle migration)? Further, data added in real-time will require a continuous migration plan till the switch is flipped after continuous testing and audits. Finally, a clear governance structure needs to be laid out that covers:
Communication between the business teams and data configuration/PAS migration teams to prevent nasty surprises down the road.
Clear visibility for the client as to the status of the migrated data.
During the design stage, security plans for protected data should be woven into the data migration strategy.
Data migration is moving data from one system to another and multiple specialists are involved in this process apart from the project management team. The data owners who best understand the existing data structure and business requirements. The functional team who are the experts on the target system data design. The third is the data migration team, the specialists in legacy data profiling, cleansing, transformation, and migration. They will also need to quickly fill the gaps where there is no clear knowledge in some areas of the legacy data.
Data complexity of older insurance platforms is often a result of:
Data captured decades ago might be structured in a way that made sense then but over time there is no documentation left that can fully decipher it.
Often, non-standard data formats might be used, for instance, non-standard free text clauses are added by underwriters in some policies and these would require specific exception handling.
Data stored in disparate systems might not have been updated in years. Often, older policies might not meet the current regulatory compliances that are built into the new systems. Businesses and actuaries will need to be involved to resolve such issues on a case-by-case basis.
Before a PAS migration, source data must be thoroughly audited and resolved. In short, this phase is critical to setting the stage for a smooth migration. In addition to a structured procedure, the process will also need to bring on the right software and tools for data migration.
Insurance carriers should evaluate vendors for their automation capabilities to deliver conversion events with a high degree of success.
The process of integrating data first starts with replicating it from various sources. It is then merged and transformed into a format that is compatible with the destination system. That is where the reconciliation process comes in. It is a verification phase that compares the target data with the original source data to ensure that the data transfer is accurate.
The traditional approach to data reconciliation usually depended on a record count. For example, if 50,000 records in one data migration cycle were extracted but only 48,980 are transformed and 48,960 records were loaded into the new target system. The reconciliation process would need to identify where and why the lost 40 records dropped off.
However, while this would handle missing records and duplicated records, there are other mistakes in mapping logic that it would not pick up. These issues in database migration could point to:
Missing values
Incorrect values
Poorly formatted values
Broken relationships across tables or systems
A high amount of processing power is needed to perform this field-by-field validation. Modern data migration strategy must include data prototyping functionality and comparative reconciliation capabilities to ensure a full volume data reconciliation testing. A common tactic that might be opted is to break the data into subsets and build out and test one category at a time. However, with high-volume policy data, different categories can be built and tested in parallel.
A technology partner, like SImpleSolve, Inc, will use automation intervention to reduce manual effort requirements and also leverage insights from previous data migrations. However, use cases can differ from organization to organization as well as from different technology vendors. Insurance organizations and their new technology partner will need to identify the risks and challenges in their mitigation plan for a smooth transition experience. Talk to our insurtech experts for a demo on how data migration is built into our implementation process.