Project Retrospectives · Published May 22, 2026
Retrospective: Three Reruns for a Hundred Thousand Rows
The first run errored, the second disagreed on totals, the third passed. Each failure exposed a different problem.
A legacy replacement needed a hundred thousand customer and contract records migrated. Planned at two days, it took ten, and the final cutover had zero discrepancy.
Why each run failed
Run one: mismatched charsets turned Chinese customer names into garbage. Source was latin1, target utf8mb4.
Run two: precision loss. Source used floats and target used decimals, and rounding produced one-cent differences that accumulated.
Run three: broken contract relations. Legacy customer ids were strings with stray spaces, so joins failed.
What we keep from it
Truncate the target table before each rerun so the migration is idempotent and leftovers do not confuse analysis.
A verification script reports row counts, amount totals and null ratios for key fields automatically.
Migration logs keep original values so any record and field can be traced.
Migration time is almost always underestimated. Prioritise the verification script above migration speed.
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →