Migrations
What a migration QA pass actually checks.
Most migration damage is not caused by the plan. It is caused by the gap between the plan and what actually shipped, and the only thing that closes that gap is checking the live site against the thing you signed off.
The redirect map is not the redirect behaviour
A redirect map is a spreadsheet. What matters is what the server does when Googlebot asks for the old URL, and those two things come apart more often than anyone expects: chains that were meant to be single hops, rules that fire in the wrong order, parameters that get dropped. Every row gets requested and the response recorded, because a map that says 301 and a server that says 302 are a different outcome.
Sometimes the right answer is to stop
At the BBC an external recommendation to consolidate bbc.co.uk onto bbc.com was built on flawed data. I made the risk case to senior stakeholders and stopped a programme that already had board-level momentum. The realistic downside to overall BBC search traffic was more than 10%, and preventing it was the biggest win of the job. The full case study is here.
Check the things that are cheap to break
Canonical tags pointing at the staging domain. A robots.txt that shipped with the staging disallow still in it. Meta robots tags left on noindex. Structured data that parses on the old template and silently fails on the new one. None of these are hard problems. All of them are invisible until traffic moves, which is why they belong on a list somebody works through rather than in somebody's head.
A migration QA pass is not a sign-off ritual. It is the last point at which a mistake is cheap, and the work is to find the difference between what was agreed and what is actually live while that is still true.