Replatforming and migration

TL;DR

Replatforming is a controlled surgery on a working system: you preserve every URL, every 301, every schema markup, every internal link that was earning traffic, while replacing the underlying platform. A well run migration loses under 10 percent of organic traffic during the first two weeks and recovers within 60 days. A poorly run migration can bleed 30 to 60 percent and take a year to recover. The variance is entirely process discipline.

The playbook, in one paragraph

Audit the current site completely (URL inventory, backlink profile, ranking pages, schema, tracking, integrations) before touching the new platform, design URL structure for the new platform to match or improve the old, build a complete 301 redirect map with automated testing, carry over schema markup on every migrated page, stage the new site on a subdomain for QA against real production data, run parallel tracking so post-launch anomalies are diagnosable, cut over with a rehearsed runbook, and monitor daily for the first 30 days with immediate rollback authority. Migration is not a launch. It is a controlled handoff.

Where this fits in the modern discovery layer

A migration is a stress test of every discovery surface at once. Google's index has to reprocess the entire site. Backlinks pointing to the old URLs need 301s to preserve equity. Structured data has to carry over so rich results survive. Local citations pointing to specific pages need to still resolve. AI answer engines that cached content need the same content to be findable at the new URL.

Of the 19 surfaces in the Playbook, migration touches all of them in the same window. SEO is the most obvious surface. Core Web Vitals often improve with a modern platform, but a rushed migration can degrade them. E-E-A-T signals (named authors, publish dates, methodology transparency) need to survive the CMS change. Reputation platforms may link to specific product or content URLs that must still resolve. LSO citations from Yelp, Apple Business Connect, and directory sites often point at specific URLs. VxSO and video embeds need their embed codes preserved.

The strategic point: migration risk compounds across surfaces. A single missing redirect on a high traffic page causes traffic loss, ranking loss, backlink devaluation, and sometimes citation breakage all at once. This is why the audit phase is the load bearing part of the project, not the redesign.

The five levers

1. Complete URL inventory before anything else

Screaming Frog crawl of the entire current site. Cross-referenced against Google Search Console (every URL that has received impressions in the last 12 months), Google Analytics (every URL that has received traffic), sitemap.xml, and any known orphaned pages surfaced by log analysis. The output is a spreadsheet of every URL, its current traffic, its current rankings, and its migration disposition (keep, redirect to X, retire with 410, retire with 301 to parent).

2. Redirect map that is validated, not just written

Every old URL that is not identical to a new URL gets a 301 redirect entry. The map is validated against a staging environment before cutover: 200 status on the new URL, 301 status on the old URL, chain length of exactly one hop. Automated crawler runs against the redirect map on staging catch the 3 to 8 percent of entries that would have broken silently. This is the difference between a smooth cutover and a scramble.

3. Schema, meta, and structured data carry-over

Every page has metadata that was earning it results: title tag, meta description, Open Graph tags, Twitter Card tags, canonical URL, robots directives, JSON-LD schema. The migration preserves all of it on every page. When rich results depend on specific schema (product, article, FAQ, review, breadcrumb, organization), those get audited pre-launch and validated post-launch with the Rich Results Test.

4. Staged cutover, not big bang

Content sites can migrate section by section over a matter of weeks: blog first, product pages second, main navigation last. Ecommerce sites typically require one cutover, but the staging environment lives on a subdomain (staging.example.com) with real production data and gets subjected to real user flows before DNS changes. Big bang launches with no staging test are how disasters happen.

5. Post-launch monitoring with immediate rollback authority

The first 30 days after cutover need daily monitoring: crawl errors in GSC, indexation changes, ranking movements, organic traffic by page, checkout conversion for ecommerce, form submission rate for lead gen. Somebody has to own the ability to roll back a specific change without a committee meeting. Migrations that discover a problem in week three and take another two weeks to decide what to do lose the recovery window.

First 30 / 60 / 90 days

Days 1 to 30: audit and inventory

Screaming Frog full site crawl. Google Search Console 12 month URL export. GA4 traffic export by page. Backlink profile export from Ahrefs and SEMrush.

URL inventory master spreadsheet built. Every URL categorized: keep (identical URL post-migration), redirect (specific new URL), retire (410 for pages with no equity or 301 to parent for pages with some equity).

Schema audit. Every schema type currently deployed catalogued: Organization, Article, Product, FAQ, Review, Breadcrumb, LocalBusiness. Migration must preserve every type. Rich results earned currently must be re-earnable on the new platform.

Integration inventory. Every third party connection catalogued: analytics, tag manager, CRM, email platform, review platform, live chat, personalization, A/B testing tool. Each needs to be re-implemented on the new platform.

Backlink profile. Top 200 referring domains identified. Highest value backlinks pointing to specific URLs mapped to their new destinations. This is where individual outreach for the highest value links pays off (an editor can update the link if you ask).

Metric moving in month one: 100 percent of URLs with traffic in the last 12 months documented, categorized, and mapped. Any missed URLs become post-launch traffic loss.

Days 31 to 60: build and stage

New platform build in parallel with content and structure work. URL structure for the new platform defined and approved before any content is migrated. Schema templates for each content type built into the CMS or theme.

Redirect map built. Every old URL mapped to a new URL or a retirement disposition. Redirect map imported into the new platform or configured at the CDN or reverse proxy level.

Staging environment stood up on a subdomain with real production data. QA runs against staging: manual review of the top 100 pages by traffic, automated crawler validating that every old URL returns 301 to the correct new URL, Rich Results Test against sample pages, PageSpeed Insights against sample pages, checkout or form submission end to end.

Tracking parallelization. GA4 and any other analytics set up to fire on both old and new sites during the staging period so post-launch anomalies have baseline data to compare against.

Metric moving in month two: staging passes a full QA runbook. Every checklist item green before scheduling cutover.

Days 61 to 90: cutover and monitor

Cutover runbook rehearsed. Team roles assigned (redirect verification, tracking verification, checkout verification, ranking verification, rollback authority). Cutover scheduled during the lowest traffic window (Tuesday 2am Eastern for most US sites, adjusted for the actual traffic curve).

Cutover executed. DNS updated. Redirect map verified with automated crawl within the hour. Sitemap.xml resubmitted to Google Search Console. Bing Webmaster Tools sitemap resubmitted.

First 72 hours: daily monitoring of crawl errors, index coverage, organic traffic, conversion metrics. Any anomaly triggers investigation within four hours.

Days 4 through 30: daily standup on migration health. Weekly ranking check on the top 100 keywords. Weekly backlink status check on the top 200 referring domains. Any traffic loss over 10 percent triggers immediate diagnostic.

Deliverable at day 90: the new platform is stable, organic traffic has recovered to pre-migration levels or better, redirect map is 100 percent validated, and the team has a documented playbook of what shifted and what held. Post-launch reports go to stakeholders with revenue impact reconciled.

Tools I use

Screaming Frog is the single most important tool in a migration. Full site crawls, redirect map validation, internal link auditing, schema markup extraction, orphan page detection. If I could keep one tool for migrations it would be Screaming Frog.

Google Search Console for the 12 month URL export, ranking data, indexation status, crawl error reporting, and sitemap submission. Free, essential, checked daily during migration windows.

GA4 for traffic baselines and post-launch verification. Parallel tracking on staging and production during the transition window prevents attribution confusion.

Ahrefs and SEMrush for backlink profiles, keyword ranking baselines, and competitive verification. I run both because backlink data varies between them and the union gives a more complete picture.

Google Rich Results Test and Schema Markup Validator for structured data validation pre and post launch. These catch schema errors that would silently lose rich results.

PageSpeed Insights and Lighthouse for Core Web Vitals verification. A migration that improves LCP and INP is a migration that pays back in ranking within weeks. A migration that degrades them is a slow burn to fix.

The platform of choice. Shopify Plus for ecommerce under $100M, Magento or Adobe Commerce for complex B2B commerce, WordPress for content sites, Webflow for marketing sites needing visual editing. Platform choice depends on the client's actual needs, not on what the vendor is pitching this quarter.

Cloudflare or similar CDN for redirect management at the edge. Managing redirects in the CDN layer keeps them out of the application and makes them easier to audit and update.

Google Sheets for the redirect map, URL inventory, and QA runbook. Migration lives in a spreadsheet. The spreadsheet is the source of truth.

What kills the program

1. Incomplete URL inventory

The team pulled URLs from the sitemap. The sitemap misses 30 percent of the URLs Google actually knows about. Post-launch, orphan URLs return 404, backlinks devalue, and rankings drop on pages nobody remembered. Cross-referencing sitemap plus GSC plus GA4 plus a full Screaming Frog crawl is the only complete inventory method.

2. Redirect chains and 302s

The migration script generated redirects. Half of them are 302 (temporary) instead of 301 (permanent), so PageRank does not fully transfer. The other half chain through two or three hops because a previous migration left old redirects in place. Chains lose equity at each hop. Every redirect should be 301 and one hop only.

3. Missing schema on the new platform

The old site had Product schema, Review schema, Breadcrumb schema. The new theme has none. Rich results disappear from search overnight. The team spends three months rebuilding schema after the fact instead of shipping it as part of the migration.

4. Rushing to cutover to meet a launch date

The board wants a launch by end of quarter. The QA is compressed. The staging environment did not get full traffic validation. The migration ships with 40 known issues and 200 unknown ones. Post-launch is a scramble. Missing a launch date is cheaper than the six months of recovery from a compressed migration.

5. Tracking gaps on cutover

Analytics was reimplemented on the new platform. Half the events do not fire because they were tied to the old platform's DOM structure. Post-launch attribution is broken for six weeks while the team debugs. Ship the new tracking on staging with confirmed event firing before cutover.

6. No rollback authority

Something breaks post-launch. The team assembles a meeting to decide what to do. Three days later a decision gets made. Meanwhile Google reprocesses the broken state and rankings drop further. Somebody needs the authority to roll back a specific change immediately, no meeting required.

KPIs that matter

Organic traffic delta. The primary migration metric. Target within 10 percent of pre-migration baseline in the first two weeks, full recovery within 60 days. Larger drops trigger diagnostic protocols.

Indexation coverage. Percentage of submitted URLs indexed in GSC. Target 90 percent or higher within 30 days. Persistent gaps mean URLs are being deprioritized or blocked.

Redirect success rate. Percentage of old URLs that 301 to a valid new URL. Target 100 percent. Automated weekly crawl for the first 90 days catches gaps introduced by content changes.

Ranking retention on top keywords. Percentage of top 100 keywords holding or improving position. Target 85 percent or higher retained in the first 30 days.

Core Web Vitals scores. LCP, INP, CLS on top templates. Migration should improve these or hold them flat. Regression is a warning sign.

Conversion rate consistency. Ecommerce conversion rate or lead gen conversion rate held or improved against pre-migration baseline. Larger drops mean a checkout or form issue is silently costing revenue.

Backlink profile retention. Top 200 referring domains still linking and still pointing to valid URLs. This is where individual outreach on the highest value links pays back.

FAQ

How much traffic should we expect to lose during a replatform?

A well run migration loses 0 to 10 percent of organic traffic in the first two weeks, recovering fully within 30 to 60 days. A poorly run migration can lose 30 to 60 percent and take 6 to 12 months to recover. The variance is entirely process. Redirect maps and schema carry-over are the load bearing items.

When should we replatform versus stay put?

Replatform when the current stack is genuinely blocking a business capability (headless commerce needs, international rollout, checkout flexibility, CMS content team autonomy). Do not replatform because a new platform looks nicer or a vendor pitched you. Migration risk is real and the upside of replatforming needs to outweigh it.

Which platforms do you recommend?

Shopify Plus for ecommerce under $100M with straightforward requirements. Magento or Adobe Commerce for complex B2B commerce or heavy customization needs. WordPress for content sites and marketing sites. Webflow for marketing sites with visual editing needs and no heavy commerce.

How long does a replatform take?

A marketing site replatform runs 3 to 5 months from kickoff to cutover. An ecommerce replatform runs 6 to 12 months. Enterprise migrations run 12 to 24 months. Anything faster is compressing testing, and compressed testing is where post-launch disasters come from.

What is the single biggest cause of traffic loss during migration?

Broken 301 redirects. Either missing redirects, wrong destination URLs, or chained redirects that lose PageRank at each hop. A complete URL inventory and a validated redirect map before cutover prevents most of the loss. Fixing after the fact is possible but slower and more expensive.

Should we launch on the new platform in stealth first?

Yes. Staged rollout by section or by percent of traffic catches problems that pre-launch testing missed. Content sites can migrate section by section over weeks. Ecommerce sites often need one cutover, but staging on a subdomain and running QA against real users before switching DNS is standard practice.

Do we need to keep the old URL structure?

Not necessarily, but every changed URL needs a 301 redirect and every changed URL is a small SEO risk. If the current structure is functional, keep it. If it is broken (bad hierarchy, parameter chaos, non-semantic), migration is a fair time to fix it, with a documented redirect plan.

Related reading

• The full writing archive
• UX and UI methodology playbook
• Content marketing operations playbook
• Conversion rate optimization playbook
• All case studies and playbooks