Why migrations go wrong
Most replatforms do not fail because the new platform is bad. They fail because the team underestimated the transition itself. Organic traffic drops 40% in the first week. A quarter of product URLs return 404s. The new analytics stack is not configured, so nobody can measure the damage for a fortnight. By the time the dust settles, the business has lost three months of revenue and the relaunch is remembered as a disaster rather than an upgrade.
Zero-downtime migration is not a single clever trick. It is a sequence of small, boring disciplines run in the right order. This is the playbook we use when we move clients from ageing WordPress instances, legacy Sitecore estates or bespoke CMSs onto modern stacks.
Step 1: Audit the existing site
You cannot migrate what you have not documented. Before anyone writes code, produce four inventories.
URL inventory
Pull every URL that has received a session in the last 12 months from Google Analytics, every URL with an impression in the last 16 months from Search Console, and every URL with at least one external backlink from Ahrefs or Semrush. Merge, deduplicate, and you have your protected list. For most business sites this lands between 300 and 5,000 URLs. For older sites with active blogs it can run to tens of thousands.
Analytics baseline
Snapshot organic sessions, conversion rate, revenue per session, and top landing pages across the last 90 days. You want a before-and-after that does not rely on memory. If traffic drops 8% post-launch, is that seasonal, a migration artefact, or an algorithm update? Without a baseline you are guessing.
Content debt audit
Mark each page as keep, merge, rewrite or retire. Most sites carry 30-40% dead weight: out-of-date case studies, duplicate service pages, blog posts that targeted keywords the business no longer cares about. A migration is the right moment to prune, provided the retired URLs still get 301s to a sensible parent.
Integration and redirect inventory
List every integration (CRM, email, payments, live chat, personalisation) and every existing redirect rule. Old redirect chains have a way of silently dying during a replatform. Document them, then migrate them.
Step 2: Build in parallel, with real staging
Build the new site on a password-protected staging domain while the existing site keeps trading. Staging must be crawlable by your team, blocked from search engines (robots.txt plus basic auth plus noindex) and configured with production-equivalent data so performance testing is meaningful.
Give stakeholders access early and often. Weekly staging reviews catch content gaps, missing metadata and broken forms weeks before launch, when they are cheap to fix. The worst migrations we see are the ones where the client first sees the new site the day before DNS cutover.
Step 3: Design the redirect map at scale
For a small site you can write the redirect map by hand. For anything above a few hundred URLs you need a pattern-based approach. Group old URLs by template (blog post, product, service page, legacy landing page) and write regex rules that map the pattern forward. Then reconcile with the full URL inventory and handle exceptions manually.
Every rule is tested twice. Once in staging using the production URL list, and once on launch day using a crawler to hit every protected URL and confirm it resolves to a 200 at the intended destination. Redirect chains longer than one hop are flagged and flattened. Redirect loops are treated as P0 bugs.
Step 4: Preserve SEO signals
Moving platforms is the moment Google re-evaluates your site from scratch. Give it every signal that nothing important has changed.
- Title tags, meta descriptions, H1s and canonicals ported faithfully unless there is a deliberate reason to change them.
- Structured data (Organisation, Article, Product, Breadcrumb, LocalBusiness) audited and reimplemented on the new stack.
- Internal linking graph rebuilt so your top-ranking pages retain their inbound internal links.
- XML sitemap regenerated and submitted to Search Console the hour after launch.
hreflangtags, if you run multi-region, mapped across the cutover.
Step 5: Plan the cutover
The two cleanest cutover patterns both work. Pick the one your infrastructure supports.
DNS-based cutover
Lower the TTL on your A and CNAME records to 300 seconds a week before launch. On launch day, flip DNS to point at the new infrastructure. Propagation completes in minutes rather than the usual 24-48 hours. The old site stays live as a fallback you can revert to.
Edge-based canary
If you run Cloudflare, Fastly or a similar edge layer in front of both environments, you can route a percentage of traffic to the new site (5%, then 25%, then 100%) over a few hours. Errors surface while the blast radius is small. This is our preferred pattern for ecommerce and high-traffic sites.
Step 6: The launch-day runbook
Launch day should be choreography, not improvisation. The runbook we use looks something like this.
- T-7 days: TTL lowered, staging frozen, final content review signed off.
- T-24 hours: Full staging crawl, redirect map verified, analytics and tag manager containers pointed at production.
- T-2 hours: Comms to internal stakeholders, maintenance banner staged (not enabled).
- T-0: Cutover executed. First smoke test by the on-call engineer.
- T+30 minutes: Sitemap submitted, forms tested end-to-end, payment flow tested with a real transaction.
- T+4 hours: Full site crawl, 404 sweep, Core Web Vitals check in the field, error-log review.
One person owns the runbook. Everyone else takes direction from them. This is not the moment for parallel decision-making.
Step 7: Monitor for 30 days
The window between launch and stabilisation is four weeks, not four hours. Watch Search Console daily for coverage changes and new 404s. Watch organic sessions by landing page for any URL that drops more than 30% week on week. Watch conversion rate at the funnel level, not just the site level. Keep a rollback path open for the first week, even if you never use it.
Migrations done properly are invisible
The best migration result is that nobody outside your team notices. Traffic holds. Conversion holds. Rankings wobble for a week and recover. If you are considering a replatform and want a partner who treats the transition itself as the project, let us have a conversation.
