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.
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.
- 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.
- 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.
- 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.
- 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.
Before and during the migration, both we and our clients need to perform certain tasks. The data migration process typically involves the following steps:
|1. Confirmation of various insurance process flows - see the insurance process flows section||Root and client||This includes intended change-over expectations, specifically relating to operational impact of the client on the day of migration:|
1.1. Client: Pause running of existing policy administration system (PAS)
1.2. Client: No longer submit payments on existing PAS
1.3. Root and client: Anything else you may require to achieve your operational requirements
|2. Planning the intended dates for migration||Root and client||Including end of existing flows on the legacy system, and the start of new flows on Root|
|3. Supplying the client with the data migration specification template||Root||This template specifies the data required for the migration, and is adapted for each individual insurance product|
|4. Client supplies data to be migrated, according to the specification||Client|
|5. Transformation and testing of migrations and addressing errors||Root and client||5.1. Root: Supplies the client with results of the test migrations|
5.2. Client: Client updates data resolving any issues identified in tests.
5.3. Root: Retest and resupply results.
5.4. Root and client: Repeat above until no more errors are identified.
|6. Confirmation of acceptance of the final migration data and results||Client|
|7. Conducting migration dry-runs||Root||Repeat until the process is smooth and runs appropriately|
|8. Final migration||Root||8.1. Data imported into production|
8.2. Scripts are run
8.3. Results communicated to the client
|9. Monitoring of imported policies for any irregularities||Root||Billing runs are closely monitored for any issues|
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.
|Policy flows||Premium collection flows||Claims process flows|
- Policy issue
- Policy anniversaries
- Policy event history (not currently supported for import)
|- Collection types required|
- Collection types offered
- Collection strategy
- Pro-rata considerations
- Transaction history considerations.
- Unpaids - pre- and post-migration
|- Premium collections impacts|
- Policy impacts and correlations
Updated 7 months ago