Insurance Data Migration within 19 Hours: All You Need to Know

Key takeaways

• Data migration is an essential stage that requires a close look.
• Often insurtech vendors underestimate their dependency on third-party systems.
• Process steps of data migration usually depend on the type of data we migrate. Make sure to ask your vendor to present it to you.

Data migration is a process occurring in situations when you need to move sensitive customer data like claim- or policy-related information from one place to another.

Most commonly, this happens when you want to replace a legacy administration platform with a new one to get additional functionality to address market needs better.

At Cloud Insurance, we’ve been successfully implementing various migrations within 19 hours. So here are some tips on what to expect and monitor when working on migration with your insurtech vendors.

‍

‍

Why is data migration so important?

Regardless of the project scope, data migration is often one of the essential stages, which requires your close look. It has to do with your most important asset as an insurer – data, which represents your business value and claims experience. If not done right, may cause long delays, frustration and afterwards cancellation of the project. Why? Because moving data always involves both complexity and risk – adapting it to a new system might take too much time.

What is the focus of data migration?

The first thing to keep in mind is proper data migration planning with a focus on speed and integrity. Aim for high data quality and 19 hours for migration. This way, new features from the upgrade become quickly available to contract administrators and parties.

How early to plan migration?

If you work with a professional vendor, they will start addressing migration as early as possible. They will look at the different scenarios and make a time plan, both based on existing procedures that you have and the processes, which they have as a default. Combining both might take some hours, but it’s crucial for synchronised migration.

When to do live data testing?

Another important thing is to do a live migration test quite early. And not just simulated migrating, but a complete migration with live data running it in the vendor’s test system. Such testing will help to analyse actual data quality and define missing information in the existing system. If not done earlier, you and your vendor will run into much more problems when doing the actual migration.

How synchronised should be vendors and third-party systems?

Often insurtech vendors underestimate their dependency on third-party systems. Let’s imagine a situation where your vendor estimated each email to be auto-sent to a customer within 1-2 seconds. But your vendor uses another email-sender system, and that one sends an email within 30 seconds. Thus, instead of finishing migration at noon, you’d have to wait another day and find your vendor in a legal breach with sending information to the customers. So make sure your vendor has prior experience working with all relevant 3rd party systems planned in the project.

Why look at APIs?

API is an application programming interface. It helps your existing administration system talk to a new one to pass the data more efficiently. Make sure you or your team analyse APIs that will be used for new customers. Those may help you understand your vendor’s data model, which will speed up things when working on your part of the migration. In other words, processing live data through the new system models often gives a more in-depth insight into the legacy data.

What are the data migration process steps?

Process steps of data migration usually depend on the type of data we migrate. Make sure to ask your vendor to present it to you. However, there are two steps which will always be there: migration export and migration import.

Here’s an example of the data migration process with an auto-sending policy to customers.

• Step 0: Migration export.

You or your team implements this step.

• Step1: Migration import.

Your vendor is responsible for the implementation of this step (development team and script). It involves uploading the data into a new system (creating policies, customers, documents in Docx format, etc.). Your duration threshold here is 1-2 seconds per customer.

• Step 2: Creating documents.

Vendors should have a script in place to implement it automatically. Aim for one second per customer.

• Step 3: Auto-sending docs to customers.

Vendors should have a script in place to implement it automatically. Aim for one second per customer.