What is Data Migration in Insurance?

Data migration in insurance is moving policy, claims, financial and customer data from a legacy system onto a new one, usually when a policy administration system is replaced. It covers extracting, mapping, cleansing, loading and reconciling the data so the new system can run the book from cutover.

This guide is for insurance operations, IT and product teams planning a core system replacement. It covers what gets migrated, the main approaches, why mapping and cleansing take longer than expected, how to prove the migration is right and the risks to plan for.

What data migration is in the context of replacing a core insurance system

Replacing a policy administration system has two halves. The first is configuring the new system: products, rating, rules, documents and integrations. The second is moving the business onto it. Data migration is the second half, and it is usually the harder one, because the data reflects every product version, workaround and manual correction the old system has seen.

The new system stores policies in its own structure, so each record from the old system has to be translated into that structure, checked and loaded in a form the new system can process. A migrated motor policy has to be renewable, adjustable and claimable in the new system exactly as it would have been in the old one, with the same premium, the same cover and the same history.

The work is normally broken into five steps: extract the data from the legacy system, map each field to its place in the new system, cleanse it to fix or remove errors, load it, then reconcile the result against the source. Most projects run those steps several times in rehearsal before the live migration.

What gets migrated

Live policies are the core: every policy in force at cutover, with its current cover, sums insured, premium, endorsements, excesses, renewal date and the parties attached to it. These records have to be complete, because the new system will be adjusting, renewing and paying claims on them from the first day.

The closed book and history are the policies that have expired or been cancelled, and the previous versions of live policies. Firms need this history for claims that arrive after a policy has ended, for complaints, for regulatory and audit requests and for underwriting analysis. Some migrate it in full, some migrate a summary and some leave it in an archive.

Claims data includes open claims with their reserves, payments and correspondence, and closed claims needed for analysis and possible reopening. Open claims are often the most sensitive records to move, because a handler is working on them and a customer is waiting.

Financial transactions cover premium charged, collected and outstanding, instalment plans, commission, taxes and claims payments. These have to reconcile to the general ledger before and after the move. Documents, such as schedules, certificates, endorsements and claims correspondence, may be migrated as files linked to the new records or held in a document store the new system can reach. Customer records, including contact details, consents and preferences, link everything together and are the records most likely to contain duplicates.

The main approaches

A big bang migration moves the whole book at once on a single cutover date. Its advantages are a clean break, no period of running two systems and a single set of processes from day one. Its risks are concentrated: if something goes wrong at cutover, everything is affected, and rollback is hard.

A phased migration moves the business in stages, typically by product, line of business, legal entity or distribution channel. An MGA might move its household book first and its commercial book six months later. Each phase is smaller, lessons from the first carry into the next and a problem affects only part of the business. The cost is a longer period of running two systems, with integrations, reporting and staff covering both.

Renewal-based migration moves each policy when it renews. New business goes onto the new system from the start date, and existing policies are re-quoted and issued on the new system at their renewal date, so that after twelve months the annual book has moved. It avoids converting mid-term policies, because each policy is created fresh in the new system. It still needs the legacy system to stay running for mid-term adjustments, claims and history on unrenewed policies, and it does not suit multi-year or long-tail business.

Many projects combine approaches, for example migrating open claims and long-term policies directly while moving annual policies at renewal.

Data mapping and cleansing: why the source data rarely maps cleanly onto the new system

Data mapping is the work of deciding where each piece of legacy data goes in the new system. On paper it is a spreadsheet of source fields and target fields. In practice it is where most of the effort goes.

Legacy systems store data in ways that made sense when they were built. A field labelled "occupation" may hold trade codes for commercial policies and free text for personal lines. A cover option may be held as a code that only one person in the business can interpret. Two products launched years apart may store the same information in different places. Each of those cases needs a rule, and many need a business decision.

Cleansing deals with the errors that accumulate in any system: duplicate customers, invalid postcodes, missing dates of birth, sums insured that do not match the schedule, policies left in an incomplete status and endorsements keyed in the wrong order. Some errors can be fixed by rule. Others need someone to check the record by hand.

There is also a question of how much to clean. Fixing every historical record can cost more than the records are used for, and deciding what to keep is partly a legal question: under the storage limitation principle in UK GDPR, explained by the Information Commissioner's Office, personal data should be kept no longer than necessary for the purposes it is held for. A migration is a good moment to apply the firm's retention policy, so that data past its retention period is not carried into the new system.

Testing and reconciliation: proving premium, claims and balances match before cutover

Reconciliation is how a project proves the migration is right. At its simplest, it compares totals: the number of live policies, total gross written premium, total outstanding premium, the number of open claims, total reserves and total paid to date should match between the legacy system and the new one, by product and by period.

Totals can match while individual records are wrong, so reconciliation also works at record level. Sample policies are compared field by field. A set of migrated policies is put through real transactions in the new system, such as a mid-term adjustment, a cancellation and a renewal, and the results are compared with what the legacy system produces for the same transaction. A renewal that rates differently on the new system is either a mapping error or a difference in rating logic, and the project needs to know which.

Most projects run several full rehearsals, or dress rehearsals, before the live migration, each time loading the full data set, reconciling it and timing the process. The live cutover then follows a tested plan with agreed criteria for going ahead or rolling back. Finance, underwriting and claims sign off the reconciliation, because they own the numbers.

Common risks

Hidden legacy logic is the most underestimated risk. Old systems often contain rules nobody has documented, such as a rounding method, a minimum premium on a particular product or a discount applied automatically to one broker's business. If the new system does not reproduce it, migrated policies renew at different prices and nobody knows why until customers or brokers complain.

Poor data quality slows every step: mapping takes longer, more records fail validation on load and reconciliation throws up more exceptions. Projects that profile the source data early can size the cleansing effort before it holds up the timetable.

Parallel running costs money. While both systems are live, the firm pays licence or hosting fees for the old one, maintains integrations to both and asks staff to work across two sets of screens. A phased or renewal-based plan that runs longer than expected can make this the largest single cost of the programme.

Loss of system knowledge is the last risk. The people who understand the legacy system may have retired, moved on or be needed for business as usual during the project. Their knowledge is often the only route to the hidden logic, so projects that capture it early, before cutover removes the reason to keep it, have fewer surprises.

How this applies to policy administration

The design of the new platform affects how hard the migration is. A system that lets the business configure products, rating and rules itself makes it quicker to reproduce legacy logic once it is found, and one that can run alongside the legacy system supports a phased or renewal-based plan. Moving to a software as a service (SaaS) platform also changes who runs the infrastructure, which removes one workstream from the migration.

Genasys says on its policy administration page that a legacy core system can be replaced in stages with old and new running side by side, that deployment can be phased by product, entity or distribution channel and that migration uses structured data import routines and reconciliation checks.

Data migration is one part of a wider replacement programme. For the full picture, including vendor selection, phasing and governance, see our practical guide to core system replacement and our glossary entry on digital transformation in insurance.