Every migration plan has a parallel month in it, and most of them treat it as a formality — a box to tick before the old system is switched off. It is the most informative month of the whole project, and it is worth doing properly precisely once.
What you are actually testing
Not whether the new system adds up. It does. You are testing whether the two systems disagree, and every disagreement falls into one of three buckets:
- The new system is wrong. Rare, and the easiest to fix, because it is a defect.
- The old system was wrong. Common, uncomfortable, and the reason the parallel month is worth its cost.
- Both are right and a policy was ambiguous. The most valuable finding, because it is a decision nobody had realised they were making.
The third bucket is where the surprises live: a rounding convention, an entity allocation that had been done by hand for years, a category that two people had been coding differently and never compared.
How to run it
Close the old books first, without looking at the new ones. Then close the new ones, without adjusting toward the old figure. Then compare — and write down every difference before explaining any of them, because explanation-as-you-go is how a real finding gets talked into being a rounding issue.
Set a materiality threshold in advance and stick to it. Without one, the exercise expands to reconcile every cent and takes three weeks.
Why once is enough
Teams that run two or three parallel months rarely learn anything in the second. The differences found in month one are structural; month two finds the same ones again, more expensively, with a team that has stopped believing the exercise matters.
If month one produced no findings at all, that is not a green light — it is a sign nobody closed the new books independently.
Afterwards
Delete the old export. Genuinely. As long as it is available, someone will reconcile against it during a difficult close, and the whole point of one ledger is that there is nothing left to reconcile against.
