Data migration risks and mitigation: the notices a conversion owes

Data migration risks are the ways a move from one system to another can lose, corrupt or change data, and mitigation is the set of controls that catch each one before it does harm. For an insurer converting its in-force book onto a new policy administration system, the technical risks are real but well understood: incomplete loads, corrupted fields, downtime, overruns, security. The risks that cost most are different. A conversion can change a customer's premium or coverage without anyone deciding it should, and each such change can owe a notice under state law that nobody planned to send: a premium explanation, a conditional renewal, a statement of reduced coverage, or an offer that has to leave by a date the project no longer meets. Botminds' Policy Data Conversion exists to find those changes first, by re-rating and comparing every converted policy before its wave is signed.

What are the risks of a data migration for an insurer?

They fall into two groups. The technical risks, data lost, corrupted or exposed, systems down, budgets overrun, are the same for any migration and are controlled with counts, control totals, testing and security. The policyholder risks are particular to insurance: a converted policy that rates differently, covers less, renews late or loses the history its premium depends on. The first group is visible to the project. The second is visible to the customer, usually at renewal, and to the regulator if it reaches enough customers.

A technical register misses the second group because none of those risks breaks a load. In a fictional sample conversion run through Botminds' Policy Data Conversion, Larkhaven Mutual's third wave of 18,412 homeowners policies loaded cleanly, tied on Coverage A to the dollar and on forms and endorsements by count, and still had 472 policies whose premium or coverage differed at its third test load.

Risk 1: a premium that rises at renewal with no reason given

The most likely policyholder risk is a converted premium that is higher than the legacy system would have charged, for a reason nobody can explain because nobody chose it. In the sample wave, a protective device credit worth 1% of base premium dropped from 128 policies because the legacy field said only Y and the alarm type sat in a remark. Roof ages taken from the year the house was built raised 61 premiums by about $195 each.

New York now asks for an explanation when a renewal premium rises by more than 10%, measured "exclusive of any premium increase due to insured value added", for auto and residential property policies, with the rule taking effect on 24 August 2026; below that level the insurer must tell the policyholder they can ask, and answer within 20 days (NY DFS, Insurance Law §2356). A conversion error is not a primary rating factor anyone can honestly name. For commercial policies, an increase over 10% is one of the triggers for a conditional renewal notice under §3426. The mitigation is the same in every state: re-rate every converted policy at the legacy rate version and allow no unexplained difference to sign.

Risk 2: coverage that quietly shrinks

The most damaging risk is a coverage loss, because it does not show up in premium and the customer finds it at a claim. In the sample, Teresa Villanueva's scheduled personal property endorsement listed four jewelry items worth $18,400. The extract carried the schedule's $202.40 premium but not its items, so the converted policy had no items. Thirty-nine policies had the same problem, $333,900 of scheduled property in all.

Several statutes require a reduction of coverage at renewal to be stated. New York's commercial lines law lets an insurer renew on narrower terms, such as lower limits, a higher deductible, a new exclusion or a premium more than ten percent higher, but only with timely notice (N.Y. Ins. Law §3426(e)(1)(B); a sample of that notice is annotated in the conditional renewal notice sample). California's renewal offer must name each limit cut and each coverage removed (Cal. Ins. Code §678), and Texas protects a material change at renewal only with 30 days' written notice (Tex. Ins. Code §551.1055). A conversion that drops scheduled items has made exactly such a change without any of those notices. The mitigation: compare coverage by value, item by item, and refuse to sign a wave with any coverage difference.

Coverage that existed only on a scan

Risk 3: the offer that leaves late

Every wave has a latest safe go-live date, set by the earliest renewal offer or notice deadline among its policies, and a slip past it is a statutory breach on every policy in the wave. Iowa's personal lines deadline doubled at the start of 2025, from 30 days before the end of the term to 60. If an insurer misses it, the old policy simply runs on.

The policy or contract shall be extended on the same terms and conditions for another policy or contract term or until the effective date of similar insurance procured by the insured, whichever is earlier.

Iowa Code §515.129C(2)

New York's commercial rule is sharper on price. A late conditional renewal or nonrenewal notice sent before expiry keeps coverage on the expiring terms, at whichever is lower of the current and the prior period's rates, for sixty days after the notice goes out (N.Y. Ins. Law §3426(e)(5)(B); the commercial calendar around it is laid out in the commercial insurance renewal timeline).

A conversion calendar copied from an earlier programme, or set once in a project tool and never checked against the current statutes, is the usual cause. The mitigation is to compute each wave's go-live backwards from its own deadlines, state by state, and to freeze the wave early enough to fix what the last test load finds. The data migration plan template shows that calendar step by step.

Risk 4: the wrong rate version

A converted policy can be rated correctly by the new system and still be wrong, if the new system holds a different rate version from the one the legacy system used for that term. In 2024 an insurer reported to Texas that it had calculated rate deviation factors from superseded filings, and then a separate system error in implementing the filed rates; an estimated 409 policies were overcharged and refunded (Texas Department of Insurance, Order 2024-8700). That was not a conversion, but a conversion creates the same exposure: two rating engines, two sets of rate tables, and a period when both are live.

The mitigation is a rule, not a review: compare a converted policy only at the rate version the legacy system used. Any intended rate change then goes through its own filing and its own notice, and never hides inside a conversion result.

Same rate version on both sides, so the only difference left is the conversion

Risk 5: history nobody can reproduce

Retiring the legacy system before its records stop being needed is a slow-burning risk: it surfaces years later, in an examination, a complaint or a lawsuit about a policy term that only the old system could explain. The NAIC's model regulation on market conduct records expects a policy file "for the duration of the current policy term plus three (3) years" and notes that for some states the period "may be five (5) years"; it also expects records kept in a computer format to be "archival in nature, so as to preclude the alteration of the record after the initial transfer to a computer format" (NAIC Model Regulation #910).

Some states ask for longer. In a 2023 consent order, New York found an insurer had "failed to retain certain policy records for six years after the policies were no longer in effect" (NY DFS consent order, 2023). For a conversion that means the archive plan has to cover every term still inside the longest retention period, in a form that can be read and cannot be changed, before the legacy system is switched off.

Risk 6: the vendor holding the book

During a conversion, copies of the whole in-force book, with names, addresses, coverage and claims history, sit in extracts, staging databases and test environments, often at an integrator. The NAIC's data security model law expects an insurer to choose such vendors with due diligence, to "define and periodically reevaluate a schedule for retention of Nonpublic Information and a mechanism for its destruction when no longer needed", and to maintain "procedures for the secure disposal of Nonpublic Information in any format" (NAIC Model Law #668, §4).

Mitigation is mostly paperwork done early: contract terms on where copies live and who can see them, a register of every extract and test copy, and a disposal step after each wave signs. A tool that is read-only on the legacy system and keeps every converted value tied to its source makes that register easier to keep.

Risk matrix for data migration: how many policies each risk touches

A risk matrix scores likelihood against impact. For a conversion, likelihood is best measured, not guessed: count how many policies in a test load each risk actually touches. In the sample wave at test load 3, before any fix, the customer-facing risks far outnumbered the policies that could not load at all.

Impact then follows from the rules above. A coverage loss carries the highest impact per policy, because it is found at a claim. A premium rise carries the widest exposure, because it reaches every affected customer at once and may trigger an explanation duty. A fall costs the insurer revenue it will rarely recover once the policy has renewed. The scoring belongs in the reconciliation itself; the reconciliation report example shows the measures.

Insurance data migration challenges a technical risk register misses

Three challenges are particular to insurance and rarely appear on a technical register. Rating inputs live outside fields, in remarks and on scans, so a field-level test cannot see them. Coverage is compared by count rather than by value, so a schedule with no items still ties. And the calendar is set by statute, state by state, so a project date can be legal in one state and late in the next.

Each of those is a reason the conversion team, policy services and compliance should own parts of the register, not only the technical lead. Whether a given conversion is a renewal, a transfer or a rewrite in law, and so which notices it owes, is worked through in renewal vs rewrite.

Mitigation that works: prove every policy before its offer

The controls that retire these risks share one idea: compare every converted policy with the legacy policy, on premium and coverage, before the renewal offer is produced, and let nothing sign that has not been explained. Botminds' Policy Data Conversion runs that comparison with six agents: they read the legacy extracts and scanned documents, convert and re-rate every policy at the legacy rate version, group differences by cause and draft one rule per cause, and tie out each wave. People approve every rule and sign every wave; coverage differences cannot be accepted at all.

Questions people ask

What are the biggest data migration risks?

For any migration: data lost, corrupted or exposed, downtime and overruns. For an insurance conversion add the policyholder risks: premiums that change, coverage that shrinks, offers that leave late and history that cannot be reproduced. In the sample wave, 472 policies differed after a load that tied on Coverage A, forms and endorsements.

How do you mitigate data migration risks in insurance?

Compare every converted policy with the legacy policy before its renewal offer: re-rate it at the legacy rate version, compare coverage by value, trace each difference to its cause and fix it by rule. Set each wave's dates from the current state deadlines, and keep any policy that cannot convert on the legacy system.

What is a data migration risk assessment?

A structured list of what could go wrong in the move, how likely each risk is, what it would cost and who owns the control. For a conversion, measure likelihood by counting the policies each risk touches in a test load, and tie each risk to the statute that sets its cost.

Who owns the risk of a policy conversion?

The insurer, even when a vendor does the work. Inside the insurer the risk is shared: the conversion lead for premium differences, the forms specialist for coverage, policy services for offers and unconvertible policies, compliance for notices, and the programme manager for the sign-off.

What are the most common data migration issues in a policy conversion?

Values with no clean target, defaults filled in silently, rating inputs held in remarks or on scans, codes that split or merge, and dates that reset history. In the sample wave those produced six causes: an alarm credit, roof ages, rounded deductibles, a split territory, loss-free years and unloaded jewelry schedules.