Most platform migrations we get called in to triage have the same shape: traffic was healthy pre-launch, traffic dropped 30 to 80 percent at launch, and the team is now in the painful phase of asking what went wrong. The pattern is consistent enough that we've turned the prevention work into a defined seven-stage methodology — one we run from the moment a client is considering a replatform, not from the moment the new site goes live.
The methodology's organizing principle is canonical preservation: every URL, every redirect, every schema entity, every internal link, and every external signal that pointed at the old site must have a defined, lossless mapping to the new site by launch day. Where canonical preservation fails, traffic drops. Where it holds, the launch can be near-invisible from a search-traffic perspective.
Here are the seven stages, what each protects, and where the failure modes typically hide.
Stage 1: Pre-migration audit
Before any platform decision is final, we run a complete pre-migration audit of the existing site. The audit covers:
URL inventory. Every indexed URL, with current traffic, current ranking, current internal link weight, and current external link inbound count. This is the "what we have to preserve" inventory.
Schema inventory. Every structured data type currently emitted, with the page templates that emit each.
Content inventory. Every meaningful page of content, with its content depth, last-updated date, and any unique data the page surfaces (case studies, datasheets, FAQ blocks, etc.).
External signal inventory. Backlink profile, citations, social profiles, knowledge-graph relationships — anything that points at the existing site.
The inventory is the source of truth for the rest of the methodology. Stages 2 through 7 each refer back to it.
Stage 2: Platform choice and architecture alignment
The new platform is not just a vehicle for the migration — it's an architectural decision that shapes what's preservable. The questions we walk through at this stage:
Does the new platform support the URL structures we need? Some platforms (Shopify in particular) impose URL patterns that may not match the old structure. Where they can't, we plan the redirect map up front.
Does the new platform support the schema we need? Some platforms generate schema automatically (with varying quality); some require custom work. We don't accept "schema later" as a launch plan.
Does the new platform support the internal linking structure we need? Faceted nav, breadcrumbs, related products, content-to-product cross-links — all of these need to be designed before launch, not improvised after.
This is also the stage where the BigCommerce vs Shopify for B2B kind of comparison conversation happens. The platform decision changes what's possible later.
Stage 3: URL mapping and redirect strategy
This is the load-bearing stage of any migration. Every URL in the pre-migration inventory must have a defined target on the new site. The targets fall into one of three categories:
Preserved URLs — the same path on the new site, no redirect needed.
Mapped URLs — a different path on the new site, requires a 301 redirect.
Retired URLs — the page is going away. The redirect targets the closest semantic equivalent (a category page, a parent page, or the homepage as a last resort). Avoid mass-redirecting everything to the homepage; that's a soft-404 trigger.
For each mapped URL, the redirect type matters: 301 (permanent) for canonical handoff, not 302 (temporary). The redirect must be a single hop — no redirect chains that pass through two or three intermediate URLs before reaching the destination.
The redirect map is finalized before the new platform is built, not after. Building the new site without a clear redirect map invites the failure mode where the new URLs don't have semantic equivalents to the old.
Stage 4: Schema, content, and metadata parity
Every page that's preserved or mapped must carry its schema, content, and metadata forward. The parity checklist per page:
Title tag — preserved or improved, never silently stripped.
Meta description — preserved or improved.
H1 — preserved unless there's an editorial reason to change.
Body content — preserved at least to the depth it had pre-migration. Migrations are often paired with content rewrites; if so, the rewrite must not strip the content thinner.
Schema — all structured data preserved or upgraded. A migration is the moment to upgrade schema, not to lose it.
Internal links — every inbound internal link from elsewhere on the site updated to the new URL.
The mistake to avoid: trusting that "the CMS will handle it." Most migrations involve at least one CMS-side translation step where content is normalized or transformed, and the transformation often silently drops fields the SEO team needed preserved.
Stage 5: Pre-launch staging audit
Before launch, the staging environment is audited the same way the production site will be audited post-launch. The audit covers:
Crawling the staging site to confirm every preserved/mapped page loads correctly with its expected content, title, meta, H1, and schema.
Spot-checking the redirect map by hitting a sample of old URLs and confirming they 301 to the right new URLs.
Validating schema with the Rich Results Test and the Schema.org validator.
Checking robots.txt, XML sitemaps, and canonical tags for the new site — and confirming the staging robots.txt won't accidentally be promoted to production.
Confirming that AI engine user-agents (ChatGPT-User, PerplexityBot, ClaudeBot, GoogleOther) are allowed in the new robots.txt.
Running a Core Web Vitals pass on representative templates.
The staging audit is the last chance to catch a structural problem cheaply. Catching it post-launch is several times more expensive.
Stage 6: Launch execution
Launch day has its own discipline. The execution checklist:
DNS cutover at a planned, low-traffic window (typically overnight in the brand's primary market).
301 redirect map activated at the cutover moment — not "shortly after" or "by end of day."
Submit the new sitemap to Google Search Console and Bing Webmaster Tools immediately at launch.
Verify the redirect map by hitting a sample of old URLs and confirming the 301s are firing.
Monitor Search Console for indexing errors hourly for the first 24 hours, daily for the first week.
Monitor Core Web Vitals on real-user metrics, not just lab data.
Monitor analytics for any unexpected traffic shape changes — sharp drops on specific page types often indicate a redirect or content gap missed by the staging audit.
Launch day is not the moment for new feature work. Launch day is the moment for verification of work already done.
Stage 7: Post-launch validation and recovery
The first 30 to 90 days post-launch are where the migration is either confirmed successful or where the recovery work happens. The post-launch validation pass covers:
Indexing convergence. Google's index transitions from old URLs to new URLs over several weeks. Monitor the shift; flag any URLs that aren't transitioning.
Ranking continuity. For tracked keywords, the new URLs should hold ranking. Any rankings that don't transition are flagged for investigation — usually a content parity issue or an internal-linking issue.
Traffic shape. Compare day-of-week and hour-of-day traffic patterns pre- and post-launch. Differences often indicate either a redirect gap or an unintended page-type change.
Citation share for AI engines. AI engines have their own indexing cadence. Citation share typically dips for two to four weeks post-launch, then recovers — if the content and schema parity were preserved. If it doesn't recover, there's a structural issue to address.
The full methodology, with the per-stage artifacts and the platform-specific patterns, is on migration SEO methodology.
Where canonical preservation most often fails
In the migrations we triage after the fact, the failure modes cluster:
Redirect map gaps — URLs that existed pre-migration and have no redirect target on the new site, returning 404s or being redirected en masse to the homepage.
Content depth loss — the new platform's CMS truncated long-form content during import, or the rewrite paired with the migration thinned the content unintentionally.
Schema regression — the new platform's schema generation is shallower than the old site's, dropping properties that engines were using.
Internal link breakage — internal links updated only at the navigation level, leaving in-body links pointing to old URLs.
Robots.txt accident — the staging robots.txt (typically
Disallow: /) accidentally promoted to production at launch.AI user-agent blocking — the new robots.txt blocks AI engine crawlers that the old site allowed, causing AI citation rate to drop quietly.
Canonical tag conflicts — the new platform emits canonical tags that point to URLs different from the actual URLs, fragmenting the index.
Each of these is preventable in the methodology above. Each is expensive to fix after the fact.
When the methodology pays off most
Migrations vary in scope. A flat HTML site to WordPress is a different project than a Magento 1 site to BigCommerce or a custom platform to Shopify Plus. The seven-stage methodology runs the same in all of them, but the relative weight of each stage shifts. For high-content sites with deep editorial archives, content parity (stage 4) is the dominant risk. For high-SKU catalogs, URL mapping (stage 3) is the dominant risk. For sites with rich structured data, schema parity is the dominant risk.
For teams planning a migration, the right time to engage the SEO methodology is at platform selection — stage 2 — not at staging. The decisions made at platform selection shape what's possible at every later stage.
The cornerstone view is on migration SEO methodology. The audit-side framing — when a migration didn't go well and the diagnostic work is the priority — is on SEO audit services.
If you have a migration in flight or in the planning stages and want a methodology-led second opinion, we'd like to hear from you.