What actually breaks in a website migration

Nothing breaks loudly in a migration. That is the whole problem.

A site that fails on launch day gets fixed on launch day, because everybody is looking at it. The failures worth writing about are the ones where every visible part of the system reports success and something behind it has quietly stopped, and the discovery happens four to six weeks later when somebody asks a question the data can no longer answer.

Here is the list, in the order these things actually go wrong.

Redirects, and the ones people forget

The obvious half is easy. Every page that existed gets a rule pointing at where it lives now, and anybody doing this work does that half.

The half that gets missed is everything that was never a page in anyone's mental model. Pagination (/blog/page/7/), tag and category archives, author pages, feed URLs, the dated permalink structure from before somebody changed it, uppercase variants, URLs with tracking parameters appended that somebody pasted into a newsletter three years ago.

None of those appear in the sitemap conversation. All of them are live addresses that somebody else's link points at. The way to find them is not to reason about the site: it is to pull the real list from analytics and Search Console, going back further than feels necessary, and reconcile that against the crawl. Redirect mapping covers how to build the list and how to check it afterwards.

The second thing people forget is chains. A rule pointing at a URL that is itself redirected works, in the sense that the browser arrives. It also costs a hop, and after three migrations over six years you have sites where a link from 2019 takes four redirects to resolve. Flatten them to one.

Forms that silently stop

This is the failure I would put at the top if the list were ordered by damage rather than sequence.

A form has at least four things that can fail independently: the submission itself, the record arriving in the CRM, the fields on that record being correct, and the notification reaching whoever was meant to act on it. Testing the form means watching all four. Almost nobody does, because the button turns green and the thank-you page loads, and that looks exactly like working.

On one build the form submitted, HubSpot created the contact, and the source and campaign never arrived with it. The hidden fields sat on a React-controlled form: the values were being written into the DOM, React's own state disagreed, and what reached HubSpot was whatever React thought was there. Every visible part of the path succeeded. It surfaced a while later, when somebody asked which campaign had produced the quarter's leads and the answer came back as "direct" for all of them.

Analytics continuity

The measurement of the migration is usually the first casualty of the migration.

Three things go wrong. The tracking snippet is on the new site but not on every template, so a section of the site stops reporting and the total looks like a traffic drop. The events were rebuilt with slightly different names, so the historical series ends and a new one begins beside it. Or the consent banner is configured differently and a chunk of traffic is now uncounted, which reads as a decline that never happened.

All three produce the same symptom: a number that fell on launch week. And because the obvious explanation for a number falling after a migration is the migration, teams spend weeks chasing an SEO problem that is a measurement problem.

The prevention is dull and works. Write down what is being measured now, with the current event names and the current numbers, before anything moves. After launch, compare to that document rather than to memory.

Structured data and rich results

The last one, and the one with the longest lag between cause and effect.

If the old site was getting review stars, FAQ expansions, breadcrumb trails or event listings in search results, that came from structured data in its templates. Rebuilding the page visually does not rebuild the markup, and nothing about the new site looks wrong. The result is a listing that used to occupy four lines of a results page and now occupies two, with a click-through rate to match.

Open graph and Twitter card tags belong in the same paragraph. Nothing tests them, nothing fails, and the first anybody knows is a link shared in Slack with the wrong image or no image at all.

The thing to hand whoever is doing the work

None of this is exotic and none of it requires trusting me. It is the list I work through, and a migration quote that does not mention any of it is a quote for the build only. How to migrate without losing search traffic covers the sequencing side, and the migration guides go platform by platform through what moves and what gets rebuilt.