Why migrations fail

Most migration disasters share the same root causes. Rushed redirect maps. Missing canonicals. Broken schema. Sitemaps that never get resubmitted. Search Console properties not updated for the new domain. Old URLs accidentally allowed to 404. Every one of those mistakes is preventable. None of them are mysteries.

What is missing on most migrations is a documented process that catches each issue before launch. Here is the one we use. None of it is proprietary. Most teams just do not take the time.

Step one: complete URL inventory

Before a single redirect is written, we crawl the existing site and inventory every indexable URL. Screaming Frog at minimum. We capture the URL, the HTTP status, the canonical tag, the title, the meta description, the H1, and the indexation status of every page.

The output is a spreadsheet. Every URL the existing site has must appear in this spreadsheet. No exceptions. No "we will figure that out later." No "those probably do not get traffic anyway." Every URL.

Step two: per-URL decision documentation

For every URL in the inventory, we make and document one of three decisions:

  1. Keep: the URL exists on the new site at the same path. No redirect needed. Record the new URL anyway, even if identical, for verification.
  2. Redirect: the URL is changing. Document the exact new destination. The destination must be a 200-status page, not another redirect, and not a homepage catch-all.
  3. Remove: the URL is being retired. Document the reason. If the page had any backlinks, document where it should redirect to instead. Removing pages with backlinks is rarely the right call.

The URL mapping spreadsheet is reviewed by both us and the client before any redirect is implemented. The client signs off on the map. This sounds like overkill. It is not. It is the single most important step.

Step three: redirect implementation rules

Every redirect is a 301 (permanent), not a 302 (temporary). Every redirect is tested in staging before deploying to production. No redirect chains. A redirect chain is when URL A redirects to URL B, which redirects to URL C. Each hop loses link equity and confuses search engines. We flatten chains aggressively.

The redirect implementation must be a 1-to-1 map from the URL spreadsheet. No bulk regex catch-alls. No "anything matching this pattern goes to homepage." Specific source, specific destination, every time.

Step four: schema migration

Existing schema markup gets transferred completely to the new platform. New schema gets added where the old site had gaps. Every JSON-LD block is re-validated post-launch through Google's Rich Results Test. It is depressingly common for migrations to drop schema entirely, and the ranking impact is felt within days even if the agency does not admit it.

We document the schema state of the existing site as part of the inventory. The new site must match or exceed it.

Step five: sitemap and robots.txt rebuild

XML sitemap regenerated for the new URL structure. Submitted in Google Search Console for the new domain. Submitted in Bing Webmaster Tools. Old sitemap retired with a 301 to the new sitemap so search engines find it.

robots.txt updated to reflect any changes in indexable directories. Common mistake: staging environments often have aggressive robots.txt blocks. Forgetting to update robots.txt to allow crawling on production is one of the fastest ways to tank a migration.

Step six: staging validation

The new site runs through our full pre-launch checklist on staging. Crawl, schema, links, performance, conversion paths. If a check fails, the launch is delayed. Every time. We have walked away from launches when the client wanted to push past failures and the agency wanted to allow it.

The launch deadline is never more important than the verification that the launch will not destroy traffic.

Step seven: post-launch monitoring

The first 48 hours after launch are critical. We run:

Most migration problems show up between day 3 and day 14, not on launch day. Daily monitoring during that window catches them before they compound.

Why this works

None of this is mysterious. It is documented best practice that most teams skip because it is tedious. The single most important thing in any migration is a complete, accurate URL map signed off before any redirects are written. Most migration disasters trace back to incomplete URL maps. Once the map is right, the technical execution is comparatively straightforward.

We have used this process across 150+ migrations with zero traffic loss. The platform combinations vary. The methodology does not. WordPress to Webflow, WordPress to custom builds, Wix to WordPress, Squarespace to Webflow, Shopify to BigCommerce, custom platforms to Webflow, multilingual sites to subfolder structures, multisite networks to consolidated single sites, and countless domain consolidations.

What to ask the agency proposing your migration

If you are planning a migration, ask the agency proposing it for their documented URL mapping process. Ask to see a sample mapping spreadsheet from a previous migration. Ask what their post-launch monitoring window is. Ask what their policy is on launch delays when checks fail.

If they cannot answer these questions specifically, walk away. Find a team that takes the map seriously, because the map is the migration.

Planning a migration? Send us your URL plus a description of what you are planning. We will tell you what to watch for in your specific case, what to require from your migration team, and what to verify before launch. Free consultation, even if you do not hire us.