Phasing out a legacy system: data migration

THE REQUEST

Outdated legacy systems constitute a major cost for insurers, particularly if they run on outdated IT infrastructures. And it was for this reason, a large insurer recently decided to phase out one of its legacy applications, the policy and claims administration. Because some of the administered products in this application were out of synch with the client’s current product strategy, rather than migrating it to an internal application it was decided to outsource the management and execution of the portfolio to a service provider. We helped this insurer migrate the data to this service provider: from setting up the strategy to the actual migration.

OUR APPROACH

How? In accordance with our standardised and controlled migration approach, we provided support in the areas of Product Owner, Business Analyst, IT Manager and Project Leader. The migration process was broken down into the following four steps.

1. Choice of service provider and applying for DNB approval

First of all, it was necessary to decide which service provider the portfolio was to be migrated to. Given the complexity of the products, the many activities to be carried out and the tight migration deadline, it called for an experienced and knowledgeable player. After making the choice, the collaboration between the insurer and service provider was registered with the DNB. This was an important step, because without DNB (the Netherlands’ Central Bank) approval of the collaboration the migration would not be possible.

2. Preparing for the migration

Secondly, the following components were analysed and mapped out.

The implementation of the interfaces with external systems, bearing in mind the links to:
- a remuneration package for the payment of claims; the ADN messaging service to communicate with insurance advisers;
- the tax office, to facilitate the annual transferral of data.
The management information that the service provider is obliged to give the insurer after the conversion. Think here in terms of:
- the provision of policy and claims data to the actuarial department and Pricing & Underwriting;
- the making of journal entries in the insurer’s general ledger.
The processes and stakeholders that are part of the portfolio. After the conversion the service provider is obliged to underscore the continuation of these processes, as well as, for some processes, collaborate with the insurer. These include, for example:
- the calculation of the annual premium and the ensuing communication with the customers.
The products and contracts that are part of the portfolio.
The data that the service provider needs for the proper administration of the portfolio.
The prioritisation of the conversion objects, to ascertain which activities should be carried out first.

3. The migration

Thirdly, was the data migration, comprising: 1) mapping the data, 2) cleansing the data and 3) the actual conversion.

Mapping the data
The analysis made it clear how the administration of the service provider had to be organised and what data would be needed. Afterwards, it was possible to map the existing data to the service provider. The alignment of the mapping process was very important because it ensured that everyone was “reading from the same page”. Organisations can use different terminologies and sometimes an attribute name used by one stakeholder can mean something quite different for another. In some cases, this can require a conversion of the data before migration can take place.

Cleansing the data
After the mapping process, the data was supplied in accordance with a specific template and the filled templates were delivered from Scrum teams. To ensure that the correct data was migrated, where necessary it was first cleansed and enriched by the insurer’s specialists.

The conversion
After this cleansed and business-approved data was read into an acceptance environment, several checks were carried out. To ensure that the data was also correct in terms of content, these checks, which related to financial entries, output & data links, were carried out by all stakeholders involved in the process. When all stakeholders agreed, the same activities were carried out in a production context, thus making the chain operational and ready for the conversion.

4. Control and validation

Finally, the quality of the migrated data was validated and underscored via a conversion framework.

Validation
Given that the migration was carried out in such a short time-frame, it was decided to validate the complete transfer of data at the end. The validation was done by carrying out a complete dossier transfer from the insurer to the service provider for all migrated claims. For every dossier, it was verified that the migration had been carried out correctly and that, where necessary, the relevant supplements/mutations had been made.

Conversion framework
To underscore the quality of the migration, a conversion framework was used. In conjunction with the underlying burden of proof, this framework constituted a complete conversion dossier that served as an audit trail for the project, the business owner, risk management, as well as external stakeholders, such as the accountant and the DNB. A conversion framework adds structure to a project and contributes to its effective organisation, as well as preparation, implementation and aftercare of the conversion.

THE RESULT

ITDS helped ensure a smooth and flexible migration to the service provider. Thanks to what was a flawless migration, the legacy application could be switched off by the agreed deadline. The portfolio was successfully taken over by the service provider and the customers are satisfied with the current service. What’s more, the insurer now benefits from a substantial monthly cost saving.

Want to know more about our Implementation services? Click her e