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. Google puts a rough figure on it: as a general rule a small to medium-sized site takes a few weeks for most pages to move, and larger sites take longer. A fifteen-year-old enterprise CMS with six figures of indexed URLs is firmly in the second category, so set the expectation in months of gradual settling rather than weeks. What should not happen is a plateau — a migration that has stopped recovering, rather than one still recovering slowly, almost always has one of the two failures above behind it, not a mysterious algorithmic penalty.

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.

Decide what does not move, before mapping what does

Fifteen years of publishing leaves a site carrying a large tail of pages nobody has looked at in years: superseded product lines, event pages for conferences that stopped running, three versions of the same policy document, press releases from an acquisition two owners ago. Migrating that tail wholesale is how a replatform doubles in cost — every one of those pages needs a template, a content review and a redirect rule, and most of them will never be read again. Run the inventory first: every indexed URL against its last twelve months of organic traffic, conversions and internal links, sorted into keep, merge and retire before a single redirect gets written.

Retiring a page is a decision, not an omission, and the two options behave differently. A page with genuine accumulated authority or inbound links should be merged into its nearest live equivalent and redirected there — never to the homepage, which Google treats as a soft 404 and which forfeits exactly the history you were trying to preserve. A page with no traffic, no links and no successor is better returned as a clean 410 Gone than redirected somewhere approximate, because an approximate redirect is a soft 404 in slower motion and it pollutes the redirect map that the rest of the migration depends on being trustworthy.

What to watch in the first 72 hours, and for the year after

The launch-day checks are narrow and non-negotiable: robots.txt and meta robots on the live domain, a crawl of a sample of the redirect map verifying single-hop 301s to live 200s, the new XML sitemap submitted, and server logs confirming Googlebot is receiving the new URLs rather than errors. Search Console gives the clearest read over the following weeks — the Sitemaps report should show indexed counts falling on the old URL set and rising on the new one, and the performance report should show impressions transferring rather than disappearing. If one of those two curves moves and the other does not, that is the signal to stop and debug.

Two details are commonly got wrong at the edges. The Change of Address tool applies to moves between domains — if the URLs are changing on the same domain, it is not the mechanism, and waiting for it to "process" is waiting for nothing. And the redirects are not a temporary scaffold: Google’s guidance is to keep them for as long as possible, generally at least a year, so that signals fully transfer. Deleting the redirect layer during the next infrastructure tidy-up, eight months after a successful migration, is a genuinely common way to lose the rankings the migration had already saved.

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 Conversion Redesign. 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. Also: "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer"; keep redirects "for as long as possible, generally at least 1 year"; the Change of Address tool applies to domain-to-domain moves; and the Sitemaps, Index Coverage and performance reports are the recommended way to monitor a move.

• 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.