A claims system migration affects reserving through the data, not the claims: the same accidents and payments arrive in the next extract with new claim numbers, new coverage codes, different payment dates or less detail, and development triangles built across the cut-over compare unlike with like. The totals usually tie, which is why the damage is found late, as a development factor nobody would select. A reserving team's migration guide therefore has three parts: freeze and baseline the data before the first wave, compare every claim with the locked prior extract after each wave, and decide, document and disclose any restatement before factors are selected. Botminds' Reserving Data Validation, a data quality solution for actuaries, does the comparing on every extract, so a migration wave is found on the day the extract lands rather than in week three of the reserve review.
The migration events below come from a fictional mutual insurer whose claims platform was migrated in waves while its extracts ran through the solution. The plan is ours, written for a reserving team; claims IT will have its own.
A migration in two waves: what claims IT does, and what reserving checks at each step
- Plan and map codes3 mo
- Wave 1W1
- Run and patch8 mo
- Wave 2W2
- Retire legacy3 mo
- Lock baselines, agree maps3 mo
- Compare every claimDay 1
- Quarterly checks, change log read8 mo
- Compare every claimDay 1
- Restate, disclose, keep legacy extracts3 mo
How does a claims system migration affect reserving?
It breaks the consistency that development methods depend on. A development method assumes the past predicts the future: incurred development assumes case reserves are set with consistent adequacy, paid development that claims settle at a consistent speed. Friedland's CAS study text lists "new claims processing systems" first among operational changes after which "the assumption that the past will be predictive of the future may not hold true" (Friedland, CAS, 2010). The CAS Statement of Principles on reserves, reprinted in the same text, is plainer still:
The installation of a new computer system, an accounting change, a reorganization of claims responsibility or changes in claims handling practices or underwriting programs are examples of operational changes that can affect the continuity of the claims experience.
CAS Statement of Principles Regarding P&C Loss and LAE Reserves, Operational Changes, as reprinted by Friedland, CAS
The effects run both ways. Friedland notes that a claims department may push to clear a backlog before a transition, that "Sometimes, the speed-up is due to faster processing under the new system", and that "Sometimes the new system leads to a slowdown in closing, due to a learning curve necessary before the new system is fully operational." Any of the three moves a paid triangle without any change in what the claims will cost.
Why does data stop reconciling after a migration?
Because the new system describes the same claims differently, and the reconciliation compares descriptions. The NAIC's Actuarial Opinion (C) Working Group names the problem in its 2026 guidance: "The Working Group acknowledges that myriad circumstances (e.g., mergers, acquisitions, changes in claim systems, and the use of underwriting year data in the analysis) may make it difficult for the Appointed Actuary to reconcile the analysis data to Schedule P." It encourages appointed actuaries to disclose reconciliation issues in the Actuarial Report and, where data cannot be reconciled, to document the reasons (NAIC AOWG 2026 guidance).
Four mechanisms account for most breaks. Claim numbers change, so a claim-level comparison sees closures and new reports that are really the same claims. Code tables are rebuilt, so coverages land in different lines or segments. Dates are re-derived, so payments or accident dates move between periods. And detail is lost, so a split the analysis relied on, such as bodily injury from property damage, is no longer available. The Schedule P reconciliation guide covers what regulators expect when the tie cannot be made.
Before the first wave: freeze, map, baseline
The cheapest reserving work in a migration happens before it starts. Once legacy data has been converted, the question "what did this claim look like before?" can only be answered from an extract someone kept. Berquist and Sherman's 1977 interview list already asked the data processing executive: "Have new data processing systems been implemented in recent years? Have they had a significant impact on the rate of processing claims or on the length of time required from the reporting to the recording of a claim?" (Berquist and Sherman, PCAS, 1977). A reserving team that asks it before the project, rather than after, gets better answers.
Before the first wave: seven things for the reserving team to secure
- Lock the last legacy extract, and keep it
Read-only, with its coding tables. It is the baseline every converted claim is compared with.
- Get the old-to-new claim number map
Without it, renumbered claims look like closures and new reports.
- Get every coding-table change in writing
Old code, new code, the reporting line and reserving segment of each, and the effective date.
- Ask how existing claims take new codes
At conversion, or at their next transaction? Half-converted history mixes two codings in every triangle.
- Ask what happens to dates
Payment, report and accident dates: carried over, re-derived or defaulted when missing.
- List the fields the reserving analysis uses
Any field dropped or merged, such as bodily injury versus property damage, changes what can be analysed.
- Put actuarial on every change ticket’s impact list
So the change log names reserving as a consumer and the agents can tie breaks to tickets.
The UK Government Data Quality Framework puts the same advice in general terms: "proactively consider the impact of changes in systems on data quality" and "integrate quality processes into the design of new data systems" (UK Government Data Quality Framework, 2020). In the sample insurer the last item was the one missed: the ticket for the second wave listed claims dashboards, bordereaux and statistical reporting in its impact assessment, and actuarial was not listed.
During each wave: compare every claim with the last quarter
Compare claims, not totals, on the first extract after each wave. Totals tie across a migration almost by construction; the conversion team reconciles them. What does not tie is the position of each claim: its number, line, accident year and payment periods. A claim-by-claim comparison with the locked pre-wave extract shows every claim that moved, and a change log shows which moves were intended.
In the sample insurer's first migration quarter, the comparison found that wave 1 had renumbered 3,880 personal auto claims; two segments were held on the first day, and triangles were released two days after the extract landed. In the second, the comparison matched 471,902 claims to the prior extract and found 1,240 that had moved from Commercial Auto to General Liability; the change-log reader quoted the ticket that remapped hired and non-owned auto liability on 14 August, and noted that existing claims took the new code only at their next transaction. Both triangles would have mixed two codings.
A quarter-by-quarter view: how each break was found
How to validate claims data after a migration
Validate the relationships the conversion could have changed, against the last extract taken before it. Field rules still matter, but migrated data usually passes them: new claim numbers are unique, re-derived dates are valid dates, new codes exist in the new table. The table below lists the common migration effects and the check that shows each.
Migration effects, where they show in triangles, and the check that finds them
| Migration effect | Where it shows | Check that finds it |
|---|---|---|
| Claims renumbered | Reported counts jump; closed counts jump; open counts fail to roll forward | Open-claim roll-forward; claim-by-claim match using the number map |
| Coverage codes remapped to new lines | Incurred moves between line triangles; factors fall in one line and rise in another | Line of business unchanged since last quarter, claim by claim; coding-table versions |
| Existing claims recoded only at their next transaction | Both lines mix two codings; active claims move, dormant ones do not | Same check, with the change ticket quoted; a hold until a person decides |
| Payment dates re-derived or batched | Earlier diagonals change; the paid tie to the general ledger breaks for the period | Prior diagonals unchanged against the locked triangle; paid tie by segment |
| Missing accident dates defaulted | Claims jump accident year; a spike on one date | Accident date unchanged since last quarter; date distribution profile |
| Detail dropped or merged | A split the analysis used is no longer available | Field profile against the prior extract; a method change for the actuary to decide |
| Reopening rules changed | Reopened counts jump or vanish; counts double in some views | Reopened claims against the four-quarter average |
Should reserving methods change after a new claims system?
Sometimes, and the change has to be explained. The Academy's practice note on loss reserve opinions gives illustrative opinion wording for exactly this case. In one, a reported loss development method replaces the paid method used the year before, "necessitated by the implementation of a new claim payment system, distorting the paid data but leaving unchanged the case incurred." In another, "The change, developing auto liability losses with bodily injury and property damage combined rather than separated, was necessitated due to the implementation of a new claim system. The new system did not contain the data in the same detail as was available last year" (Academy practice note, 2025; illustrative, non-binding).
The examples show the two reasons a migration forces a method change: a measure becomes unreliable for a while, or a split disappears for good. A restatement can sometimes avoid both, by putting the data back on the old basis for reserving. Whether it should is the next question.
How do you restate triangles after a system change?
Choose between restating the new data to the old basis, restating the history to the new basis, or holding until the source is fixed, and document the choice with its claims. Each option keeps the triangle internally consistent; they differ in who has to act and what the segment means afterwards.
Three ways to restate after a recode, as offered on one held segment
| Option | What happens | Who decides | When it fits |
|---|---|---|---|
| Restate to the prior coding for reserving | The moved claims stay in their old segment for the triangles; the claims system keeps the new code | Reserving actuary; listed for the appointed actuary above $10 million | The new code is right for claims but wrong for reserving, and no back-conversion is planned |
| Accept as a true change and restate history | All claims with the coverage move to the new segment in every accident year, both triangles restated | Needs the appointed actuary: it changes segment definitions | The new grouping is better for reserving and the history can be re-cut consistently |
| Send back to claims data | Ask for a revert or a back-conversion; both segments stay held | Reserving actuary, with the claims data owner | The change was a mistake, or a back-conversion is cheap |
The ticket that caused the break, and the restatement decision
Whichever option is chosen, keep both versions: the triangle as extracted and as restated, with both rows of age-to-age factors. A restatement nobody can reverse becomes the next migration's baseline problem. How a recode moves indicated IBNR between lines, and why, is worked through in line of business mapping.
How do you disclose a data change in the actuarial opinion?
In summary in the data memo and the Actuarial Report, and in the opinion itself when it changed methods or limits reliance. The actuarial standard on data quality asks for summary disclosure of significant judgmental adjustments to the data and of known limitations (ASOP No. 23, section 4.1); the NAIC guidance encourages disclosure of reconciliation issues in the Actuarial Report; and a material change in methods forced by a new system is the kind of change the Academy's illustrative language describes. What the report itself must contain is set out in the actuarial report template.
Who signs off data after a claims migration?
The reserving actuary signs off what reaches the triangles; the claims data owner signs off the source. Migrations blur that line, because the project team owns the conversion and often reports success as "totals reconciled". A reserving team should ask for three sign-offs instead: the claims data owner's that the claim number and code maps are complete, the reserving actuary's that each segment is fit to release, and financial reporting's that paid and case reserves tie to the general ledger by segment.
In the sample configuration of Reserving Data Validation, only the reserving lead releases segments or accepts adjustments, analysts prepare but cannot release, restatements above $10 million and any change to segment definitions go to the appointed actuary, and the data memo is signed with the meaning "Prepared and reviewed". The agents never edit source data or select factors. How a claims data analyst works through a migration quarter is described in the claims data analyst guide, and the checks on every extract on the Reserving Data Validation page.
Questions people ask
What is a migration wave?
A wave is one cut-over in a phased migration: a set of lines, states, claim types or legacy codes moved to the new system at one time. Each wave changes the data reserving receives, so each needs its own before-and-after comparison, not just the first.
What is a claim system conversion?
A conversion moves existing claims, open and often closed, from a legacy system into a new one, translating numbers, codes and histories as it goes. It differs from running new claims on the new system while old ones run off on the legacy platform, which leaves reserving with two sources to combine every quarter.
How long should legacy extracts be kept after a migration?
At least as long as the triangles built from them are in use, which for long-tailed lines means years. In the sample configuration of Reserving Data Validation, locked prior-quarter extracts are read-only and kept for ten years.
Should a reserving team run old and new systems in parallel?
A parallel extract from both systems for one valuation date is the most direct test of a conversion, because the same claims can be compared field by field. Where that is not possible, the last legacy extract, locked, and the first converted extract serve the same purpose one quarter apart.
Can a claims migration change IBNR?
Not the true liability, but the estimate can move if the data move. In the fictional sample insurer, a recode during the second wave, left as extracted, would have cut Commercial Auto's indicated IBNR on all-year factors from $130.2 million to $99.8 million and raised General Liability's from $138.6 million to $171.6 million.