Moving rating to a new platform without premium drift

A move to a new policy administration platform, to the cloud, or to a new rating engine is usually sold as a technology programme. For the business, it is something narrower and riskier: every premium is about to be calculated by a different system. The question every state's sign-off depends on is whether the premium changed with it.

Why sampled parity checks are not enough

Migration programmes typically prove rating with a sample: a few dozen quotes per state, keyed into both systems, compared by hand. The sample passes. The state cuts over. The defects that slip through are the ones the sample never touched: an edge class, a territory, a deviation, a minimum premium rule, a date boundary.

Rating logic is configuration built up over years, often across several editions per state. A sample tells you the common path works. It does not tell you the rest does.

Premium parity, defined

Premium parity means that for the same risk, on the same date, the legacy system and the new platform charge the same premium, to the cent. Proving it needs three things:

1. One independent reference. A rating model built from your rate manuals and filings, sitting between the two systems. It is not the legacy code, and it is not the new configuration.
2. Cases that cover the rating, not just the volume. Generated from the rate tables so that every row and every decision path is read, plus cases either side of every effective date.
3. A result per case. A match, or a mismatch that names the first rating step where the calculations part ways. Anything unexplained stays open.

With an independent reference, a disagreement is never a debate about which system is right. It points to the side that departs from the filing.

State by state, then release by release

Migrations move one state or one line at a time. Each one should sign off on evidence: a report per state, with every case matched or explained.

Parity is also not a one-time event. Once you are on the new platform, it updates on its own schedule, and every release is another chance for a premium to drift. Re-running the same graded cases after each release turns parity into a standing check rather than a project milestone.

Keep it inside your perimeter

Rate tables and policy data are exactly what your security team does not want leaving the building. Run the independent reference inside your network, with no outbound calls and no hosted control plane, and use your own language model only where AI helps draft the rating model.

Questions

When should premium parity testing start in a migration? Before the first state is configured, so the reference exists when the first comparison is due. Building it from the rate manuals also flushes out ambiguities in the rules early.

Does parity testing need access to both systems' APIs? No. Cases can be rated through each system's screens, through adapters in non-production environments, or exchanged as sheets.