Overview

Data migrations involve transferring historical data from one system (which had its own growing pains and unique issues), and loading it into a new system, with the aim that the data looks, feels and works as if it had been running on the new system all along. A typical example would be a client moving their existing policy and related data from a legacy policy administration system onto Root.

Migrations are hard. We take the utmost care to ensure that we protect the integrity of our clients’ data. This is done by identifying potential risks, and completing thorough testing to ensure these risks are mitigated. To ensure alignment with our clients before and throughout the process, we continually raise awareness of possible difficulties which may be encountered and will work with our clients to overcome them.

A successful data migration takes time, focus, testing and iteration. The extent to which a client requires assistance from the Root team varies, and will be set out in a Service Order or Implementation Plan.

Data integrity

During the migration, we support our clients by defining the type and format of the data required. However, to accommodate data migrations, Root Platform's import functionality bypasses standard product module validation.

Outside of migrations, policies are issued on Root via a multi-step process. At the quote and application steps, various validation rules are applied regarding data types and the relationships between fields.

Since data imports bypass this validation, this creates a risk that erroneous data will be written to the platform. Performing further operations on erroneously written policies such as alterations, anniversary logic and other actions may be impossible as the imported policy data does not match what the product module code expects. In addition, the premium on an imported policy may differ from what would be calculated by the latest product module logic on Root.

We mitigate this risk by applying programmatic validation to the data during the import process, by means of the following steps.

1. We import only the rating factors (“input” fields) required to calculate the premium. This simplifies the client’s data preparation task as you need to prepare only the input fields as opposed to all policy fields.
2. We run a script to apply an alteration to all the imported policies to calculate the premium and all other “output” fields that need to be stored on the policy. This ensures that the premium and other policy “output” fields are aligned with the product module on Root, as opposed to the client’s previous system.
3. In the event that the input data does not match the product module validation, the alteration would output an error and notify the user performing the import. This allows us to identify where the imported data does not match the product module validation so that we can advise the client of any fixes required to the data, or alternatively amend the validation in the product module code.
4. Once all the data passes validation, we compare the policy premium (and other “output” fields) calculated on Root to the premium on the old system. This allows us to identify any discrepancies and work through them with our clients.

Although we have designed this process to minimise the risk of importing erroneous data, ultimately we rely on the accuracy of the data provided by our clients. The integrity of the data that is finally imported is therefore the client's responsibility.

Data migration process

Before and during the migration, both we and our clients need to perform certain tasks. The data migration process typically involves the following steps:

Process flows

Root will communicate and confirm the following process flows with the client before beginning the data migration process. In each case, keeping any differences between the two systems in mind will be important.

Under normal circumstances, most of these flows would trigger notifications (email and/or SMS) to the customer. Therefore Root and the client need to coordinate on the notifications that customers will receive, and disable notifications that should not be triggered as part of the migration process.