Keys to Migrating Policy Data

Insurance policy data migration, namely the process by which insurance policies are transferred from one or more source systems to one or more target systems, can be of strategic importance to insurers undergoing core policy system transformation for a number of reasons:

1. When a legacy policy system is replaced with a net new policy platform, the new platform may deliver additional functionality, but it is the policy data migration that has the potential to deliver mature, profitable books of business to the new platform. As such, in many cases, the underlying business case for a core policy system replacement relies heavily on successful policy data migration.
2. Legacy policy system decommissioning relies on successful data migration; it is not possible to decommission a policy system until all significant books of business have been migrated off it. As a consequence, building a strong data migration capability able to quickly migrate books of business off legacy policy systems cuits the cost of running the IT estate, freeing funds and resources for other value add activities.
3. Unsuccessful data migration carries significant downside: poor data quality of migrated policies, lost-in-translation policies that are extracted from the source system but that never land in the target system and data breaches related to migrated records. It is in the interest of insurers to invest in data migration upfront to get it right the first time around.

See also: 4 Steps to Ease Data Migration   Although each policy data migration has its own characteristics, most share the following architectural components:

• Source System/s: the source system/s from which policies are being migrated.
• Source System Extract Engine: component extracting policies from the source system/s.
• Transform Engine: component transforming the policies extracted from the source system into a format that can be accepted by the target system/s.
• Target System/s: the target system/s into which policies are being migrated.
• Load Engine: component committing the output of the Transform Engine into the target system/s.
• Reconciliation Solution: component counting migrated records at key steps in the policy data migration flow, to ensure that all extracted policies ultimately land in the target system/s.

Below are some points to consider when designing insurance policy data migration, paired with some experience-based points of view. 1. Target system/s and architecture should be built so that policy data migration can be effective:

• When designing the target policy system, and all the systems around it, the impact of solution decisions on data migration should be considered. For example, a decision to introduce a net new solution to handle party-centricity may have a limited impact on new business flows, but a significant impact on data migration. If the data migration impact is disregarded, then the project may find further down the line that data migration is prohibitively complex to perform because of the party-centricity solution.

2. Policy data migration should be considered at a company level, rather than at a divisional level:

• Within insurance companies, in many cases books of business residing on source systems relate to multiple divisions. For example, source systems X, Y and Z may each have books of business from retail, commercial and specialty. When this is the case, it is important to ensure that data migration is considered at a company level, to ensure that books of business are migrated in such a way that decommissioning is feasible. Otherwise, the risk is that policy data migration programs driven by a single division may fail to capture the value derived from decommissioning source systems, as on each source system there may be books of business other than those that the specific division is migrating.

3. The pipeline of policy data migrations should be developed in parallel to the timelines for core policy system replacement:

• A common error related to policy data migration planning is to delay it until after the detailed planning for the core policy system replacement program is complete. The risk is that only too late will it become apparent that the rate at which books of policies can be migrated is insufficient to complete the data migration within the program timelines. In some cases, the rate may be so slow, for example no more than two books of business per calendar year, that it is not even possible to migrate all books from source to target before the target itself becomes legacy and is replaced.

4. Migration reconciliation should be catered for with either an automated or manual solution:

• Reconciliation with regard to policy data migration entails two elements: firstly, counting that all the records that are extracted are transformed, and that all the records that are transformed are then loaded into the target architecture, and secondly, determining what has happened to dropped records. For example, if during a data migration cycle 100.000 records should be extracted, transformed and loaded, but only 99,980 are extracted, 99,960 are transformed and 99,940 are loaded, it is the reconciliation solution that should highlight that 20 records have been dropped at each step, and that should indicate what has happened to each of the 60 records.

5. There is significant benefit in defining the goals of each policy data migration in a single sentence:

• Not everyone is familiar with data migration, so defining what data migration is looking to achieve in a concise manner provides a clear platform to engage non data migration stakeholders. Below is a template sentence using letters to highlight key data migration elements:
  • The data migration for book of business X needs to migrate Y records from source system M into target system Z at a load success percent of T at a rate of R records per second.

6. The decision on whether to migrate policies as quotes or as live policies should be made early in the solution process:

• When performing policy data migration, the options are to migrate policies into the target system/s as live policies, or as quotes that then convert into live policies a number of days before their renewal date. The advice is that unless there are strong reasons to migrate records as live policies, it is best to migrate as quotes that then convert into policies, as loading as live policies introduces complexity around the live elements of the policies, such as billing accounts.

7. Policy data migration performance implications should be considered upfront:

• Where the data migration components use transactions that are either shared with new business, or particularly complex and performance-heavy, it is important to ensure that performance implications are considered. For example, a transaction that is used 10 times per minute in new business may be used 1,000 times per minute in data migration, which may cause contention issues. Consequently, both the target architecture and the data migration solution should be designed to avoid performance bottlenecks.

See also: The Rise of Big (Bad) Data   Key takeaways:

• Policy data migration in insurance has the potential to drive significant business value in that it can deliver mature books of business to net new policy handling systems, and it may allow decommissioning of legacy systems.
• Most policy data migrations share common components, namely Source System/s, Source System/s Extract Engine, Transform Engine, Target System/s, Load Engine and Reconciliation Solution.
• Designing a policy data migration is not simple; leveraging insights from previous data migrations may be the difference between success and failure.