The first thing that breaks rankings in a site migration is almost always redirects: broken or missing 301s from old URLs to their new equivalents. When the old-to-new mapping is incomplete or wrong, the accrued ranking signal tied to those old URLs has nowhere to flow, and visitors and crawlers hit 404s at scale. That is the load-bearing wall of a migration, and it fails before most of the more exotic problems people worry about. So if you are triaging where a migration goes wrong, redirects are the prime suspect to check first.
The reason this breaks first is that every ranking a page has earned is attached to its specific URL. Change the URL and that equity does not automatically follow; a correctly configured permanent redirect is what tells Google the page has moved and passes the signal to the new address. Skip it, point it to the wrong place, or chain it through several hops, and the new URL starts closer to scratch while the old one returns errors. Multiply that across a whole site and you get a sudden, broad ranking drop, the classic post-launch crash that traces straight back to the redirect map rather than to content or design.
It breaks first because it is both high-impact and easy to get wrong at volume. A site of any size has hundreds or thousands of URLs, and an automated rule that misses edge cases, dropped parameters, or pages that quietly changed slugs leaves gaps that only show up as lost traffic. Other failures, template changes, internal linking, speed, do matter, but the redirect map is what most reliably takes rankings down first and fastest.
Before you launch, build and check the complete old-to-new redirect map so every old URL points to its closest new match with a single permanent redirect. Then verify it again right after launch by crawling the old URLs and confirming they resolve correctly with no 404s and no chains. Get that wall standing and you remove the migration’s single most common cause of a ranking collapse.