Preparing for an Insurance Data Migration : Agent/Agency Data
May 28, 2021
When your company decides to move to a new software solution, one of the biggest challenges you’ll face in the implementation process is data migration.
Data migrations are notoriously prone to failure – roughly 50 percent of software implementations struggle to manage data migration properly, and 20 percent of projects are canceled outright due to issues with data migration.
That’s a huge problem. If a data migration fails, then the change initiative it supports will likely also fail.
What is data migration, and why is it so important?
Consider innovation in the insurance industry alone. In 2020, insurtechs received $7.1 billion in funding. Those insurtechs are updating the industry by introducing new software solutions and technologies to drive efficiencies and retire legacy systems.
Insurance companies who want to remain competitive in the industry need to embrace these technologies and evolve with the industry or risk getting left behind. But change management is tricky, particularly for an old-school industry like insurance. And data migration just adds to the quagmire of change management, in large part because it’s so misunderstood.
So, let’s clear these muddy waters.
At a basic level, systems store and display data differently. When you implement a new system – this could be anything from a CRM to billing software – your previous data structure may not fit your new system. But with a bit of prep work and clean-up, you can help ensure your data will slot nicely into your new system and that your users will be able to work with the records they need.
Tried and true best practices for data migration
We’ve led many data migrations through the years and have put together this best-practice guide to data migration management to help ensure successful implementations.
We’ll cover these more at length below, but the top three things to think about when planning a data migration are:
- Populating required fields
- The quality of your data
- Formatting your data to meet vendor specifications
Populating required fields
The best place to start when preparing for data migration is with a vendor-provided template. This template clarifies requirements for each field within a new system. Your vendor should have this handy to share with you during tech discovery calls. Once you get it, consider the following:
- Understand the requirements that are laid out in the template and ask questions if they aren’t straightforward.
There’s a minimum level of information that’s required to create a record. As you get more complex with the information you’re migrating, you will also run into conditional requirements (IF adding this field, THEN an additional field is required). Collaborate with your vendor to think this through and identify any required conditions ahead of time.
- Work with your vendor to add additional fields to templates that are relevant for your company to track.
Discuss why these fields are important to your company and how they’re used so your vendor can guide you to the proper field type. Choosing a field type can have a big impact on your employees’ workflows. Do you want your users to have the ability to add a freehand response to a given field, or does it make more sense to have a pre-set list of options for them to choose from? These are important distinctions and should not be taken lightly.
- Do your due diligence and check your completed template before submitting it.
Make sure required fields are populated. If you don’t do this, you may experience countless emails confirming specific issues or spend extra hours in meetings reviewing data and results with your vendor.
The quality of your data
It’s essential to consider your end-user when planning a data migration. How easy is it for a user to quickly find the specific record they’re looking for?
When you implement new software, you look for opportunities to drive efficiencies in existing workflows. In other words, your new software should make your employees’ lives easier. What data do they need to do their job? How will this data migration change that?
Once you know the required fields for your new system, it’s time to clean that data up.
- Identify any duplicate data points and consolidate or update.
Duplicate data can negatively impact a new system by causing confusion about which record should be worked on or updated. There may sometimes be a need to show multiples of the same record – version history, for instance – but you should always work with your vendor to determine how a new system can handle that structure.
- Verify that the ID values your users (or integrated systems) may search for are relevant, accurate, and unique.
Your users may search for records using an ID or code. Downstream systems sometimes require legacy IDs or codes to function in your business process. It’s OK to continue creating IDs in your new system if it’s absolutely essential to a business process. But consider the following: Is the ID you want to migrate required for any business processes? If not, think about getting rid of it and training users on a more efficient way of searching for records.
If required, make sure IDs are formatted properly so your system recognizes they’re unique. It may seem pedantic, but issues arise from formatting errors as minor as the capitalization of letters. Some systems treat capitalized letters differently than lowercase letters. If you don’t prepare for these differences, then your data migration may teeter toward disaster.
- Work with your new software vendor to understand how records can be related to each other and organized logically.
If you’re making any changes from the previous two bullet points, you may be left with some information that could be lost in the migration. You need to partner with your vendor to identify the best way of relating records to each other in your new system so it both fits with the new data structure and allows you to keep all relevant information.
Formatting your data to meet vendor specifications
Data can be stored in different ways across legacy systems. After running an export query, your results may look – for lack of a better term – like a jumbled mess on your spreadsheet. Your goal with formatting is to make sure you’re providing your new software vendor with data that can fit into the new system you’re implementing.
The better formatted the data you provide, the easier it’ll be to read and the more useful it’ll be to you when your teams begin using the new system.
- Request an export of a sample of records from your vendor to see what your data will look like in the new system.
This can include custom fields that you’re looking to incorporate. Things to watch out for here are dates, currency, percentage, decimal places, and picklist values, to name a few.
- Verify formatting is accurate.
Filter specific columns to confirm that all values match character expectations for fields like phone, email, Social Security number, IDs, and dates. Check things like field length, if it needs to contain numbers or letters, and whether it contains special characters like “@” or “&.”
- Try a sample migration before providing all of the data to determine if you’re satisfied with the way your records display in the new system.
You may or may not be able to do a full migration as a test. Regardless, you should start small with a subset of your records to test and verify that the results will work for your business needs.
A successful data migration: onward and upward
There’s no one way to approach data migration. Every company has different requirements of vendors and different definitions of success when it comes to implementation.
But at the end of the day, the best way to ensure a data migration is successful is to prepare for it. Cross-departmental communication helps necessary stakeholders plan for vendor implementations. Understand what your employees need to do their jobs and, ultimately, think back to the change initiative that inspired the data migration in the first place. Once you’ve done that, you’re on your way to a successful data migration and a more efficient workplace.