Data migrations are unpopular and tedious activities for companies in all industries. They mean a loss in time and costs and bind capacities. This is nothing different in the insurance industry either. In particular in life insurance, because there is also a row of particularities here:
- long term of insurance contracts (up to 60 years and more)
- complex actuarial mathematics
- great density of regulatory adjustments for life insurances throughout the decades (deregulation of life insurance (1994), tax reform (2005), VVG reform (2008), Solvency II as well as the Investment Tax Reform Act (2018))
- high number of products and tariffs to be managed through the continual introduction of product innovations
- technologically outdated policy management systems (frequently from the 60s and 70s) with just a few remaining employees with the necessary technical detailed knowledge to maintain the systems
The difficulties
Due to incomplete portfolio data functions in the old systems and the necessity of manual interventions in the budget (”hero dialog”), the data quality is often poor. New, modern policy management systems such as in|sure PSLife are implemented to improve the situation. The old system may first be shut down after a complete migration of the insurance policy. But many insurance companies are afraid of performing a migration project. On the one hand, the project risk of such a project is very high due to the many affected systems and the large external effect. On the other hand, the complexity of the affected systems is connected with great expenses. Insurance companies frequently tend to start projects of this type very late.
The basic requirement for a successful migration project is that the life insurance contracts will be transferred to the new system in a technically correct and consistent manner. The guarantees that were given to the policyholders must remain. The guarantee values from the source system must be transferred from the new software system for the life insurance, for example, in|sure PSLife. They will be considered as long as the life insurance does not change substantially on request (for example, with a premium change). Two other points that must definitely be considered include, on the one hand, that the insurance community may not be worse off at the expense of individuals. On the other hand, the company must fulfill supervisory provisions.
Source and target systems normally do not calculate the same due to deviating rounding rules and, if necessary, different calculation procedures. A migration process must be able to detect and evaluate such deviations. This is difficult to attain with a pure data migration.
The optimal migration process
This challenge can be taken on with a professionally performed migration. A software solution for migration such as MIGSuite provides the necessary components and the migration process for this.
The data is exported from the source system and stored temporarily. In a second step, the data in the target data structure is transformed. The transformed data can be forwarded to the target system, for example, in|sure PSLife. If necessary, interfaces from peripheral systems will also be connected during this. After data transfer to the new system, the contract will be newly calculated. In addition to this, the controlling values are determined as well. In MIGSuite, this may be compared with professional analog values from the source system. These values are selected so that they serve as a good indicator for the professionally consistent transfer of contracts. If an error occurs here during the migration process, the entire transaction will be subject to a rollback. The contract is therefore not transferred to the target system and both the source system and target system remain in a consistent state.
Due to deviations that may occur with the actuarial values, it is very tedious to consistently migrate a complete contract with all contract versions. In practice, it has proven to make sense to migrate life insurance contracts with only the most current contract version. MIGSuite offers the possibility to also provide all early contract versions later for informative purposes. It makes sense to select the migration effective date - the date at which the contract goes to the target system – in such a manner that no changes to the contract may occur before this date. Changes before this date cannot be made in the target system, because the target system does not contain any information about the contract version before the migration effective date.
The historic contract versions can no longer be calculated after shutting down the source system. The relevant actuarial values (in particular - but not only – coverage capital) must therefore be calculated and enriched during the extraction of the data from the source system.
In conclusion
The migration of life insurance contracts is a very complex project. It makes sense to use established migration processes. This allows insurance companies to concentrate entirely on the technical questions of the migration and preserves resources.
Find out more about the topic of data migration and our software solution for technically complex data migrations MIGSuite as well as our software solution for life insurances in|sure PSLife.
