How Long Should You Run Excel and a Claims Platform in Parallel?

Every migration guide says "run in parallel for a while". This article answers the question the guides skip: how long is a while, what do you compare, and how do you know you're done?

The answer: one full scheme cycle — typically one quarter. Long enough to watch a scheme announced, claims submitted, validated, and settled in both systems. Longer than that and you're not derisking anymore — you're feeding the shadow-Excel trap.

What a parallel run is actually for

A parallel run proves three things, and only these three:

1. The data feeds are right — the sales register and claim files landing in the platform match what Excel was fed.
2. The scheme mapping is right — the slab and target logic migrated from formulas into agreement terms computes the same entitlements.
3. The outputs agree where money moves — accruals, validated claim amounts and settlement figures match, or every variance has a named cause.

It is not for building comfort, and it is not a training period — training happens before. A parallel run without defined comparisons is just double work with a deadline nobody set.

What to compare, weekly

Comparison	What matches	Variance means
Accrual by scheme × distributor	Accrued amount both sides	Feed gap or slab mis-mapping
Claim validation outcomes	Approved/rejected amounts + reasons	Terms mapped differently than written
Settlement computations	Amount and credit-note basis	Rate, window or rounding differences
Exception lists	What each system flagged	One system sees data the other doesn't

Run the comparison weekly, small and boring, on the same day each week. Log every variance with its resolution — that log becomes the evidence for exit. Expect an uncomfortable discovery: some variances will be Excel that was wrong for years, because spreadsheet scheme math fails quietly — the failure modes are catalogued in calculating sales incentives in Excel.

The exit criteria

Exit when the evidence says so, not when it feels safe:

• Two consecutive settlement runs matched (or every variance traced and resolved).
• Weekly variance count trending to zero, with no unexplained items open.
• The distributor-facing numbers — claim statuses, settled amounts — have been agreed by the pilot distributors, not just internally.
• The scheme cycle that started in parallel has closed in parallel.
• A named owner signs the exit: after this date, the platform's number is the number.

The shadow-Excel trap

The most common migration failure isn't a bad cutover — it's a parallel run that never ends. The spreadsheet keeps being maintained "just in case", which means every future discrepancy is settled by asking Excel, which means the platform never becomes the system of record, which means you're paying for software while running spreadsheets. Psychologically it feels prudent. Operationally it's a decision not to migrate, made by nobody, with no date on it.

The cure is structural: the exit is a declared date with named sign-off, and after it the spreadsheet is archived — kept readable for reference, no longer updated. If leadership can't sign that, the open items on the variance log are the real blocker; work those, not the calendar.

Who signs off

The same three people who carry the migration overall (the full cast is in who needs to be on a claims-system implementation): the commercial owner signs that scheme terms compute correctly, the accounts owner signs that settlements and credit notes reconcile, and the decision-maker signs the exit itself. If opening balances were loaded with distributor sign-off, the exit is dramatically easier — the baseline was agreed before the comparison started.