B2B website migration without disaster: a replatform playbook

A website migration done well is invisible. Traffic holds, rankings hold, leads keep coming and the only people who notice are the marketing team admiring the new design. A migration done badly is a multi-quarter recovery operation. Organic traffic drops 40 per cent overnight, key conversion pages return 404s, the sales team complains that web leads have dried up and the agency or in-house team that ran the project ends up explaining for six months what went wrong.

We have led migrations for SaaS firms, MSPs and IT consultancies. The mistakes are the same every time, and the playbook to avoid them is consistent. Here is what we run through, in the order we run it.

Decide what kind of migration you are actually doing

Migrations come in different shapes and the planning differs accordingly.

• Platform migration: same domain, same content, different CMS (e.g. WordPress to Astro with a headless backend, or HubSpot CMS to WordPress)
• Domain migration: different domain, often after rebrand or acquisition
• Structural migration: same domain, same platform, but URL structure changes
• Full rebuild: new platform, new content, new structure, new design

Most “rebuilds” are actually three or four of these at once, which is why they go wrong. Each layer of change adds risk. A migration that changes platform, structure, content and design simultaneously has four times the failure modes of one that changes only the design. Where possible, sequence the changes rather than ship them together.

Audit before you do anything else

Before any design or build work starts, audit the existing site. We use Screaming Frog for the technical crawl, GA4 and Search Console for traffic data, and Ahrefs or Semrush for backlink and ranking data. The output is a single inventory of every URL with:

• Current organic traffic
• Top three ranking keywords and their positions
• Inbound backlinks and the referring domains
• Conversions in the last 12 months
• Indexation status (indexed, noindexed, redirected, 404)
• A “decision” column: keep, merge, redirect, delete

This is the document the rest of the migration runs against. Without it, you are making redirect decisions blind.

Decide what to keep, merge or kill

A lot of B2B tech sites accumulate cruft. Old blog posts that nobody reads. Service pages that describe propositions you no longer sell. Author pages for people who left two years ago. PR pages from 2018. Migrations are an opportunity to clean this up, but only if you decide deliberately rather than by neglect.

Our rule of thumb:

• Keep any page driving meaningful organic traffic, conversions or backlinks
• Merge thin or duplicate pages into stronger ones (and 301 redirect the old URLs)
• Redirect discontinued products and old service pages to the closest equivalent
• Delete and 410 only pages with zero value and no inbound links

A 410 (gone) is a stronger signal to search engines than a 404 (not found) and is appropriate for genuinely retired content. Do not 410 anything with backlinks. Redirect those.

Build a complete redirect map

This is the single most critical document of the migration. Every old URL that has any reason to persist (organic traffic, backlinks, internal links, paid ad destinations, email links) needs a 301 redirect to its new home.

A good redirect map has:

• The full old URL (including any query parameters that matter)
• The new URL it should redirect to
• A redirect type (301 for permanent, which is almost always what you want)
• The reason for the mapping (so future you can review the logic)
• A test status

Avoid redirect chains (old URL → middle URL → new URL). Each hop loses link equity and adds latency. Always redirect direct to the final destination.

Avoid mass redirecting everything to the homepage. This is the single most common migration disaster. Search engines treat homepage redirects as soft 404s and drop the rankings of the source URLs anyway. Map each URL to the most relevant new page.

Preserve the SEO foundations

A migration is the easiest moment in your site’s life to break SEO and the hardest moment to recover from. Beyond redirects, several technical pieces matter.

URL structure

Where possible, keep the URL structure. If you are migrating from /services/managed-it/ to a new platform, do not change it to /our-services/managed-it/ just because the new CMS prefers a different pattern. Every URL change costs you something. Only change what you have to.

Title tags and meta descriptions

Carry these across exactly. Do not let a new template auto-generate fresh titles. If the title was working, keep it.

Heading structure

H1, H2, H3 hierarchy carries weight for search engines and for AI search citation. The new design should preserve the heading structure of high-performing pages, not redesign it from scratch.

Schema markup

If the old site had Organization, Product, Article or FAQ schema, the new site needs the same (or better). We covered the SaaS-specific case in schema markup every SaaS website should have, and the same logic applies to MSP and consultancy sites.

XML sitemap and robots.txt

Generate a fresh XML sitemap from the new site. Submit it to Search Console as soon as the new site goes live. Check robots.txt is not accidentally blocking the new site (we have seen launches where the staging robots.txt with Disallow: / shipped to production).

Internal linking

The new site needs equivalent or better internal linking than the old one. Internal links are how search engines discover and rank pages. A redesign that consolidates 80 pages into 30 prettier ones but loses two-thirds of the internal link graph will lose rankings. We discuss this in internal linking for tech sites.

Canonical tags

Make sure canonicals point to the right URL on the new site, not the old one. We have seen migrations where canonicals carried over from the staging environment and pointed to the staging domain.

We cover the broader picture in our SEO migration guide, which goes deeper on the search-side specifics.

Content migration is not copy-paste

Migrating content is the part that gets underestimated most. Treating it as a copy-paste from old CMS to new CMS misses everything that makes the new site better. We typically rewrite or refresh the top 20 to 30 per cent of pages by traffic and conversion, port the rest with structural cleanup and use the migration as the trigger for a content audit we should have done a year ago.

Test, test, test

A staging environment that mirrors production (same hosting, same CDN, same caching) is non-negotiable. Test:

• Every page renders correctly
• Every form submits and lands in the CRM with full data (UTM, source, page)
• Every redirect resolves correctly
• Page speed matches or beats the old site (use our page speed checklist)
• Schema validates
• The site passes WCAG 2.2 AA, as we covered in accessibility for tech companies
• Search Console verification works on the new property
• Analytics fires correctly on every page

Run a full Screaming Frog crawl of the staging site against the redirect map. Every old URL should resolve to its mapped new URL. Every new URL should be reachable and indexable.

Launch with a rollback plan

Pick a quiet day. Avoid Mondays (peak traffic) and avoid the day before a holiday (no recovery time if something breaks). We typically launch midweek, mid-morning, with the team available all afternoon.

The launch checklist:

• DNS update with low TTL set 24 hours in advance for fast rollback
• Redirects in place at the server or CDN level
• New sitemap submitted to Search Console
• Old sitemap unsubmitted or kept temporarily so search engines find redirects
• Analytics confirmed firing on production
• Forms tested on production
• A rollback plan documented (DNS revert, redirect rules removed, content available)

Monitor for 30 days

Launch is not the finish line. We monitor closely for 30 days and check at 60 and 90.

Watch for:

• Pages dropping out of the index (Search Console)
• Spike in 404s in Search Console
• Drop in keyword rankings for tracked terms
• Drop in organic traffic on key pages
• Drop in form submissions or call volume
• Crawl errors on the new site

Most migration issues surface within the first two weeks. Address them quickly, redirect any orphaned URLs, fix any soft 404s and submit updated sitemaps as needed.

Where this fits commercially

Migrations are expensive to get wrong. We see this all the time when prospective clients call us six months after a botched migration asking why their organic pipeline collapsed. The fix is much cheaper than the recovery. For PE-backed or M&A scenarios, we run a pre-acquisition website audit that catches these problems before the deal closes.

If you are scoping a replatform or migration and want to do it without disaster, tell us about it. Our web design and SEO teams run these projects as a single workstream rather than handing off between disciplines, which is where most migration failures originate.