Migrating off a legacy enterprise CMS without losing SEO or uptime.

Nobody replaces a fifteen-year-old CMS because the technology is interesting. They replace it because every new feature now takes months, the developers who understood the original architecture have moved on, and the vendor has quietly stopped supporting the version it runs on. What makes this migration different from a normal website rebuild is scale and blast radius: the domain carries a decade and a half of accumulated search authority, dozens of internal systems read from or write to it, and a single missed redirect rule or a staging robots.txt tag that slips into production can undo years of ranking in days. None of that is a reason not to migrate. It is a reason to treat the migration itself as the deliverable, not an afterthought bolted onto a redesign.

Three ways to cut over, compared

None of these is the "correct" choice in the abstract — the decision is about the organisation's tolerance for a long transition period versus its tolerance for a single high-stakes cutover day, not about which one Google prefers.

Why the redirect map is the whole migration

Every URL the old CMS has ever had indexed needs an explicit, individual redirect to its nearest equivalent on the new system — not a blanket rule sending everything to the homepage. Google's own guidance on site moves is direct about this: redirecting a page to an unrelated or overly general destination is treated as a soft 404, and the page loses whatever ranking history it had earned. On a system this old, that redirect map is rarely a clean 1:1 job — pages get merged, discontinued, or restructured over fifteen years, and each of those needs a deliberate decision, not an automated best-guess.

Redirect chains are the second-most common failure, and they are almost always self-inflicted: a page redirected during a rebrand three years ago, then redirected again during a platform update last year, now gets a third redirect during this migration — three hops before a visitor or a crawler reaches the real page. Google follows chains, but each hop adds latency and risk, and a loop anywhere in that chain (a genuine, not-uncommon copy-paste mistake) simply breaks the page. The fix is mechanical but non-negotiable: resolve every redirect to its final destination before the migration, not through the old chain.

The staging-leak disaster: how one noindex tag takes down a launch

The single most common way a well-planned migration still goes wrong has nothing to do with content or redirects. A staging or development environment almost always carries a blanket `Disallow: /` in robots.txt, or a site-wide noindex tag, specifically so search engines never crawl the unfinished copy. When that exact codebase gets promoted to production on cutover day — because the deploy pipeline copies the staging config along with everything else — the block goes live with it. Google can act on a newly discovered noindex signal within days, and by the time anyone notices organic traffic has fallen off a cliff, a meaningful share of the site is already out of the index.

The safeguard is boring and that is exactly why it works: the production deploy checklist needs an explicit, separate step that verifies robots.txt and meta robots tags on the live domain, post-launch, before anyone declares the migration finished — not a step that assumes the deploy pipeline handled it correctly. Treat it the same way a pilot treats a pre-flight checklist: not because the plane usually has a problem, but because the one time it does, catching it on the ground costs nothing and catching it in the air costs everything.

Zero-downtime cutover in practice

The Strangler Fig and blue-green approaches from the table above are how large migrations actually avoid downtime, and both rely on the same underlying trick: the old and new systems run simultaneously, and traffic moves between them without a visitor ever seeing a maintenance page. A blue-green cutover keeps the new system fully live in shadow, verifies it against real traffic patterns, then flips a DNS or load-balancer setting once confidence is high — with the old system left running and instantly reachable if anything needs a rollback. Strangler Fig does the same thing at a smaller grain: individual sections or subdomains move over one at a time, behind a reverse proxy that routes each request to whichever system currently owns that path.

The detail that gets missed most often is DNS TTL — the cache duration on the domain's DNS records needs lowering days before the cutover, not on the day itself, because a TTL still set to 24 hours means some fraction of visitors keep hitting the old system for a full day after the switch, regardless of how clean the cutover itself was. It is a five-minute change made a week early, and skipping it is one of the more common reasons a technically successful migration still has a rough launch day.

What will legitimately fluctuate, and for how long

Some ranking movement during and immediately after a migration is normal and expected — Google's own documentation on site moves says as much directly: the system needs to re-crawl and re-evaluate the new URLs, and that takes time even when every redirect is correct. For a migration executed well — clean 1:1 redirects, no accidental noindex, sitemap updated and resubmitted — that fluctuation typically settles within a few weeks, not months. A migration that is still visibly down in organic traffic two months later almost always has one of the two failures above, not a mysterious algorithmic penalty; treat a plateau at that point as a debugging problem, not something to wait out.

It is worth setting this expectation with stakeholders before the migration, not after: a temporary dip in the first two to three weeks is not evidence something went wrong, and reacting to day-three numbers by second-guessing the redirect strategy usually causes more damage than the dip itself.

How we scope this in practice

A migration this size starts with a Technical Audit of the existing system — every indexed URL, every integration reading from the CMS, every piece of undocumented behaviour someone will otherwise discover the hard way mid-migration. That audit becomes the actual redirect map and cutover plan, not a generic checklist.

The rebuild itself is typically scoped as a Website Upgrade or, where the brand and information architecture are changing alongside the platform, a full Redesign & Relaunch. Either way, Monthly Maintenance in the weeks immediately after cutover is where the robots.txt check, redirect monitoring and ranking-fluctuation tracking above actually happen — this is not a "launch it and walk away" project.

Sources

The redirect, robots.txt and ranking-fluctuation guidance above comes from these, checked August 2026.

• Google Search Central — Site moves with URL changes ↗

  Redirecting to an unrelated or overly general page (e.g. the homepage) is treated as a soft 404 and loses ranking history; some temporary ranking fluctuation during a move is expected while Google re-crawls and re-evaluates the new URLs.

• Google Search Central — 301 redirects and Google Search ↗

  Guidance on redirect chains and loops, and on resolving a redirect to its final destination rather than leaving multiple hops in place.

• Google Search Central — Introduction to robots.txt ↗

  How a Disallow rule or noindex directive controls crawling and indexing — the mechanism behind a staging-environment block accidentally reaching production.

• McKinsey Digital — Tech debt: Reclaiming tech equity ↗

  Executives surveyed estimate technical debt at roughly 20 to 40 percent of the value of their entire technology estate before depreciation — the underlying cost pressure that makes replatforming a legacy system unavoidable eventually.