Policy management systems in private health insurance are often long in the tooth. The core of these systems has often been developed in the 70s and 80s and have undergone continuous development since then, often under time constraints: Business conditions did not allow for more extensive reorganizations at all, or legislators’ deadlines did not provide any time to “cleanly” implement new requirements, such as:
Furthermore, developers and administrators who are still proficient in the programming languages of old systems — such as COBOL — are retiring due to old age. And younger generations are not interested in learning an outdated language.
Many insurance companies now face the task of modernizing the current system landscape. Regardless of whether you use a new, in-house development or standard software such as in|sure Health Policy: Migrating data from the (old) legacy system to the new target system remains the key problem in such modernization processes.
The challenges
Access to historical contract versions is necessary, particularly for private health insurance. In addition to various statistics for internal users, evaluations must also be created for the Association of Private Health Insurers (PKV-Verband) or the BaFin (Federal Financial Supervisory Authority). Furthermore, historical data — among others — is also used for determining the triggering factors and the recalculations when adjusting a premium. This data was prepared by legacy systems and sometimes prepared with a high degree of manual labor. A future-proof IT infrastructure aims to minimize this overhead by using a modern data warehouse or similar tools, although this can only be achieved with the appropriately high data quality.
And it is precisely this data quality that must be reviewed as part of a migration project and ideally improved by making corrections to the data. Portfolio data in legacy systems is not always of the highest quality. Frequent manual interventions (e g. necessary manual adjustments to the mathematical values), plausibility checks that were not always implemented completely and without errors or case-by-case decisions that caused unexpected data constellations are just a few of the possible causes.
The projects
Generally speaking, the data structure of the old system does not match that of the new one. It makes sense to first transfer the data from the old system to the target structure by means of defined transformation rules. These rules are saved as Java source code and / or based on mapping rules (e.g. in an Excel sheet). During the process, the source data remains preserved in the original format, thereby also ensuring the preservation of all historical contract data. MIGSuite — our solution for professional, complex data migrations — can assist with this process and can even offer to supply additional systems in the migration process. They include, among others:
To identify discrepancies between the legacy system and the new target system, it is recommended to simulate contract calculation in the new system (i.e., without saving the data in the database) and validate the results before they become persistent. For instance, MIGSuite transfers the contract state to be migrated to the policy management system, has it calculated there in a simulation and compares the results with (select) values from the legacy system. During this process, the comparison values must demonstrate flawless migration and enable a quick analysis of the rejection reason during the test phase. In this case, a practical example are the payment amount and the statutory surcharges. Depending on the complexity of the products to be migrated, it makes sense to increase the number of control values. In the MIGSuite, discrepancies in the control values that exceed a defined absolute or proportional limit will halt the migration for this contract. If the control value is not exceeded, it is ensured that the values of the old system are always transferred to the new one (e.g. in|sure Health Policy). As a result, the migration does not cause a change in the contract.
Migrations become exceptionally complex when a large history size is required. On the one hand, this increases the scope of the data. If the data quality is low, the entire history may need to be cleaned up in the legacy system. Since this data normally does not match the last contract version in the legacy system either, manual cleanup is also more cumbersome. On the other hand, the calculation rules and configurations of the target system must be implemented during the migration with the history in such a manner that the results are identical with those from the legacy system when retroactive changes are made. This also includes any errors (rounding errors, calculation errors, etc.) that were present in the legacy system. Implementing and testing the target system and maintaining the algorithms after the start of production can entail a significant amount of extra effort.
In any case, the introduction of a new, modern system is a good opportunity to get rid of precisely these “old habits”. Minimizing the history size and opting for provision from a central data warehouse during migration also makes sense. By doing so, the required statistics can be provided without maintaining an extensive history in the new policy management system. In addition, the optimum migration date reduces retroactive changes in the target system. And choosing the right migration strategy adds the final touch to successful data migration.
We are happy to advise you on your migration project!