What Migration Testing Turns Up in Your Own Old Code
Comparing an old website with its replacement, request by request, is meant to catch mistakes in the new version. It also has a less comfortable side effect: it finds mistakes that were in the old version all along.
September 25, 2026
The old site isn't the gold standard
Migration testing usually treats the old site as correct and the new one as the thing being checked. In practice, when the two disagree, sometimes the old one is wrong. It has simply been wrong quietly, in a way no customer happened to notice.
What turned up this month
JAMARQ's own earlier code was not exempt. On one restaurant site, replaying recorded traffic surfaced 19 bugs in the code being replaced. Two were security issues: login tokens that kept working after an account was deleted, and staff accounts that could open any job application rather than only the ones they should see. On a music venue site, the same process found 28 production bugs.
All of them were fixed before cutover.
Why this is good news
Finding bugs in your own past work is uncomfortable, but it is far better than the alternative. Those problems existed either way. A move with careful testing is one of the few times every request a site handles gets examined side by side.
Fix, don't copy
The temptation in a migration is to reproduce the old behavior exactly, including its mistakes, so the comparison passes. When the old behavior is a bug, the right move is to fix it and record why that one difference is intentional.
Write it down
Each fix belongs in the project's change log with a plain explanation. That record shows the owner what was improved and helps the next person understand why the new site differs from the old one in exactly those places.