Website and Domain Migrations

Why migrations go wrong

A migration is any change that moves URLs: a redesign with a new structure, a replatform onto different ecommerce software, a move to a new domain name, a merge of several sites into one, a split of one site into several, or a switch from HTTP to HTTPS. They all share the same risk. The addresses that search engines have indexed, that other sites link to, and that people have bookmarked stop resolving to the same content.

Migrations fail for boringly predictable reasons. Nobody built a complete inventory of the old URLs. Redirects went to the homepage instead of to equivalent pages. The staging site's noindex directive shipped to production. The redirect map was implemented as a chain three hops long. The old domain's DNS was canceled a week after launch. The launch happened on a Friday.

None of that is exotic. It is what happens when a migration is treated as a development milestone rather than as a search event that a development team happens to execute.

Building the URL inventory

The first deliverable is a complete list of every URL the old site is responsible for. Complete is the operative word, and one source is never enough. I combine a full crawl of the live site, server logs covering a long enough period to catch seasonal and low-frequency pages, Search Console performance and index coverage data, analytics landing page reports going back at least a year, the existing XML sitemaps, and a backlink export so that externally linked URLs are represented even when nothing internal points at them any more.

Each source finds URLs the others miss. Logs surface pages that lost their internal links but are still crawled. Backlink data surfaces old campaign pages and PDFs that carry some of the most valuable links on the site. Analytics surfaces pages that convert but rank for nothing, and that would otherwise be judged worthless and dropped.

Once the inventory exists it gets ranked — by organic sessions, by revenue, by referring domains, by conversions. That ranking decides which URLs are mapped individually and which can be handled by a pattern rule.

Redirect mapping

A redirect map pairs every old URL with the closest equivalent on the new site. The rules are simple to state and routinely broken.

Map to the closest equivalent page, not to the homepage or a top-level category. A mass redirect to the homepage is treated as a soft 404, and whatever that page had earned is gone.
Use 301 permanent redirects for permanent moves, and use 302 only where the move genuinely is temporary.
Redirect in one hop. Chains dilute value, waste crawl budget and slow real users down. When a site migrates a second time, the new map has to be composed against the old one so that the oldest URLs still land in a single step.
Do not redirect a URL that should return 410. Content that is genuinely gone should say so rather than land somebody on an unrelated page.
Carry the details across — canonical tags, hreflang annotations, structured data and robots directives — and update internal links to point at the new destinations instead of relying on the redirects to do it.

The map is then tested against the full old inventory before launch, not after.

DNS, certificates and the cutover

Domain changes add a layer that redesigns do not: name resolution itself. I plan that with whoever controls DNS well before launch day, because it is the part that cannot be rolled back quickly.

Time to live values on the relevant records are lowered days in advance so the cutover propagates in minutes rather than a day. TLS certificates are issued and tested for every hostname involved, including the old ones that will only serve redirects, because a certificate error on the old domain breaks every redirect passing through it. Mail records are checked before anyone touches the zone, since a nameserver change made carelessly takes email down with it. CDN and firewall configuration is updated to serve and cache the new host. And the old domain is kept registered, renewed, locked and redirecting indefinitely rather than for a year, because links to it will keep arriving for as long as the old content is referenced anywhere.

Where the domain is being acquired rather than already owned, the transfer is scheduled first. A transfer takes days and cannot be hurried on launch morning.

Launch and the monitoring window

Migrations should not launch on a Friday, into a holiday, or during the trading peak the business depends on. Beyond timing, the launch checklist is short and non-negotiable: remove the staging noindex and the staging robots.txt, confirm the production robots.txt is the intended file, submit the new sitemaps, keep the old sitemaps reachable briefly so the redirects get discovered, and file a change of address in Search Console when the move is between domains.

Then the monitoring starts, and it runs for months rather than for a week. I watch index coverage on the new URLs, crawl rate and status codes in the logs, 404s arriving from both real traffic and crawlers, rankings on the highest-value terms, and revenue by landing page against the equivalent period before the move.

A short dip is normal while search engines reprocess the site. A dip that has not begun to recover is a signal to go and find the specific broken thing, not to wait it out.

Recovering a migration that has already failed

I am often brought in after the move, when traffic has fallen and the team that executed it has moved on to other work. Recovery is a forensic exercise, and the sequence matters more than the tooling.

The first step is reconstructing the old URL set from whatever survives: archived crawls, logs from before the cutover, backlink exports, analytics history, the Wayback Machine, and the search index itself. The second is establishing what each of those URLs does now — 404, redirect to the homepage, redirect through a chain, resolve to a page about something else, or fail on a certificate. The third is comparing traffic and rankings by URL and by section rather than in aggregate, because migration damage is almost never evenly distributed. Usually one template or one directory absorbed the loss and the site-wide number hides which.

Most of what I find is fixable. Rebuilding a correct one-hop redirect map, restoring canonical and hreflang annotations, undoing an accidental noindex and repairing internal links recovers a large part of what was lost, though it takes longer than getting it right the first time would have.

How a migration project runs

A migration is a defined project with a start, a deliverable and an end. In practice that means a pre-launch phase covering inventory, mapping, technical review of the new build on staging and the launch plan itself; a launch-week phase; and a monitoring phase that continues long enough to demonstrate the move worked.

The most useful thing I contribute is often the least technical: getting the search, development, hosting and DNS decisions into one plan with one order of operations, agreed before anything ships. Migration projects are handled through Hartzer Consulting.

Frequently asked questions

How far ahead should migration planning start?

Before the new site's URL structure is finalized, which is earlier than most teams expect. The URL inventory, the redirect map and the technical review of the staging build all have to be finished before launch, and the inventory alone takes time because it draws on log files, backlink data and a year or more of analytics history. Coming in after the new structure is locked means the mapping has to work around decisions that could have been made differently at no cost at all.

Will I lose traffic when I migrate?

Expect a short, shallow dip while search engines recrawl and reprocess the site, even when the migration is done well. What is not normal is a decline that keeps going, or one that never recovers. That points to a specific fault: broken or chained redirects, a staging noindex shipped to production, a blocking robots.txt, lost canonical or hreflang annotations, or a redirect map that sent everything to the homepage. The distinction matters, because one situation calls for patience and the other calls for intervention.

Can rankings be recovered after a migration has gone wrong?

In most cases a substantial part can. Recovery begins by reconstructing the old URL set from archived crawls, logs, backlink exports and analytics history, then establishing what each of those URLs does now, then comparing performance by section rather than site-wide, since the damage is usually concentrated in one template or directory. Rebuilding a correct one-hop redirect map, restoring canonical tags, undoing accidental noindex directives and repairing internal links recovers much of the loss, though it takes longer than doing it correctly the first time.

Should I change domain names and redesign at the same time?

I would not. Each change introduces its own variables, and combining them makes diagnosis very hard when something goes wrong, because you cannot tell whether the problem is the domain, the URL structure, the templates or the platform. Where the schedule allows, move the domain first with the site otherwise unchanged, confirm the move has settled, then redesign. Where the schedule does not allow it, the mitigation is a far more rigorous inventory, a stricter redirect test, and a longer monitoring window afterwards.

How long do redirects need to stay in place?

Indefinitely. There is a common belief that redirects can be retired after a year once search engines have reprocessed the move, but the search engine is only part of the reason to keep them. Links on other people's sites, bookmarks, printed material, email archives and citations in documents keep sending people to the old addresses for years afterwards. The old domain should stay registered, locked, renewed and redirecting, and the redirect rules should stay in the new site's configuration permanently.