The comparison job ran for a day before reads moved, and it did not report zero. It reported three disagreements, all from the same source.
All three were rows written by the overnight batch, and all three were the same shape: a timestamp that the old schema stored without a timezone and the new one stores with. The values were not wrong; they were incomparable, and a naive equality check called that a disagreement.
Two things follow, and the second is the one worth carrying:
- The comparison had a bug, not the migration. Fixed by normalising before comparing.
- It only surfaced because the job ran across an overnight boundary. An hour of comparison during the working day would have reported zero and been believed. The full-day requirement in
verify-before-cutover-not-afterwas argued for on general principle; this is the specific thing it caught, and it would have shipped as a real defect the first time anyone compared those timestamps for real.
Cutover proceeded after the fix, with a clean day. The old columns are still in place — see when-to-drop-the-old-columns, which is still open.