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

Give every known address an intended outcome. Keep useful URLs unchanged where possible; use relevant redirects for genuine moves and record deliberate removals. Preserved URLs do not need redirects simply because the framework changes.

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.

Some of these addresses appear in sitemaps or crawls and some do not. Combine those sources with CMS records, existing redirects and available analytics, search and request data. Reconcile the lists instead of treating any one of them as complete.

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.

Inventory relevant structured data and verify it against the visible content and the search provider’s current eligibility rules. Rebuilding the visual template can omit this markup, but retaining it does not guarantee a particular search appearance. Do not assume historical rich-result features remain available.

Social sharing metadata needs its own checks. Validate the title, description and image programmatically where practical, then inspect representative previews in the services your team uses. Caching can affect what a service displays.

Keep a failure register, not just a list of pages

A failure register connects a possible problem to an observable check. It is useful because the visible page often cannot tell you whether the system behind it is healthy. The register should name the affected journey, the evidence expected, the person checking it and what happens if the check fails.

For a hypothetical lead-generation site, the register might begin like this:

Keep the register small enough to use. Repeated template behavior can be tested as a family, while critical business journeys deserve explicit checks. It should be possible to tell which results are automated, which were reviewed manually and which remain unresolved.

Test failure paths as well as success paths

Submitting a complete form once proves only that one path worked under those conditions. Try a missing required field, an invalid value and a temporary receiving-service error. Check whether the visitor gets a useful response and whether retrying can create duplicate records.

For a publishing workflow, deliberately introduce an invalid content value in a safe preview environment. Confirm that the team can see what failed and identify the record that caused it. A failed build that leaves the existing production release intact can be the correct behavior; a silent failure nobody monitors is still an operational problem.

For navigation, request an intentionally missing URL. The custom error page should be useful, but the response must also represent a missing page. Returning the homepage with a success status can make the site appear healthy while concealing route errors.

These checks should happen in an environment that cannot accidentally email customers or create real orders. Mark test records clearly and agree how to remove or exclude them from reporting after the exercise.

Distinguish a broken website from broken measurement

Suppose reported conversions fall immediately after launch. Before deciding that the new site is performing worse, compare the actual destination records with the analytics events. If the CRM is receiving the usual volume while analytics records fewer submissions, investigate tracking, consent and event naming first.

If both systems show a decline, inspect the journey itself: can visitors reach the form, use it on a phone, complete validation and receive a response? Then examine traffic and demand. The launch date is a useful clue, but it does not identify the cause on its own.

Keep a change log with deployment times, tag changes and known incidents. Compare like periods and important segments rather than mixing devices, regions and unrelated campaigns into one number. This makes it easier to connect a confirmed defect with the affected data and to avoid undoing good changes in response to a misleading total.

Decide which failures stop the release

Not every issue deserves the same response. Before launch, agree a short set of release blockers. Examples might include an important form losing submissions, widespread incorrect redirects, private content appearing publicly or the main publishing workflow being unusable.

A cosmetic spacing issue may be fixable after launch if the team accepts it. An unverified payment or lead-capture journey usually needs a different decision. Write down the distinction instead of negotiating it for the first time during cutover.

Assign one person to make the go-live decision and one person to coordinate technical recovery. They may be the same person on a small project, but the responsibilities should still be visible. Record which version is being released and what evidence justified the decision.

Monitor after the initial aftercare window

The first week is useful for concentrated operational checks. It is not a deadline after which migration problems become impossible. Search processing, infrequent campaigns, monthly reports and seldom-used downloads can reveal issues later.

Keep ownership of redirects, search monitoring and important integrations beyond the initial developer support period. The arrangement can be lightweight: named checks, a reporting cadence appropriate to the business, and a clear route for escalating confirmed problems.

The SEO migration guide explains how to monitor search changes without promising a recovery calendar. The migration checklist turns the wider checks into launch gates.

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.