Running the old and new sites in parallel

A brief period running the old and new sites in parallel — old infrastructure kept accessible as a fallback while the new site takes over — reduces migration risk in the first hours and days after launch, but left open too long it creates a different problem: two versions of the same content confusing both visitors and search engines about which is authoritative.

Why a short parallel run genuinely helps

Keeping the old hosting, old database, and old site accessible (even if only privately, to the team, rather than to the public) for a period after the new site goes live provides a genuine safety net: if a critical problem is discovered on the new site — a broken form, a missing page, a redirect error — the old version and its data still exist to reference or, in a genuine emergency, to revert to, rather than the old infrastructure having already been deleted the moment the new site went live.

Where it stops helping and starts causing problems

Duplicate content, if both versions remain publicly accessible and indexable. Search engines generally expect one authoritative version of a given piece of content. Two live, indexed versions of substantially the same content — the old site and the new site, both reachable — creates genuine ambiguity about which should rank, which is why Google’s own guidance on canonicalization exists specifically to resolve this kind of situation, and why the better practice during a parallel run is to keep the old site reachable to the team for verification (via a direct server address, not the public domain) rather than leaving it live at its old public URLs alongside the new site.

Mixed analytics signals, if both versions are still being tracked simultaneously without a clear way to distinguish which traffic belongs to which — muddying the comparison the migration is specifically trying to make (is the new site performing at least as well as the old one).

Confused visitors, if both versions are somehow both reachable through search or through old bookmarks and links, landing on inconsistent content or a stale version with outdated information.

How to actually keep the old site private during the overlap

Simply leaving the old site’s public URL live “but not linked from anywhere” does not keep it out of search results — an already-indexed page stays indexed and reachable through search regardless of whether current navigation links to it. Genuinely restricting the old site to internal access during a parallel run needs one of a small number of real mechanisms: password-protecting the old server at the hosting or server level so a login is required before any page loads, restricting access by IP address to the team’s own known locations, or, at minimum, adding a site-wide noindex directive and a robots.txt disallow rule to the old site specifically for the parallel-run period — accepting that this only discourages further crawling and does not immediately remove pages already indexed, which is why access restriction is the more reliable of the two where it is available.

What to actually check during the overlap window

The value of a parallel run comes from using it deliberately, not just from its existing: confirm the redirect map is resolving correctly for a sample of high-value old URLs, check Search Console for the new site is reporting sensible crawl and indexing activity rather than errors, and confirm analytics on the new site is capturing traffic and conversions correctly — covered in the setup discipline on setting up GA4: the first week checklist. A parallel run that exists but is not actively being checked against these specific items provides less safety than it appears to, because the fallback is only useful if a problem is actually noticed while it can still be reverted to.

The practical middle ground

Rather than both sites being publicly live simultaneously, the safer version of a parallel run keeps the previous site’s files and database intact and accessible internally — not deleted, not decommissioned — for a defined period after the new site’s public launch, giving the team a fallback to check against or revert to if something goes wrong, without both versions competing for the same public URLs and search visibility at the same time.

Setting the end date in advance, not deciding it after launch

The decision about how long the overlap runs is easiest to make calmly before launch, against a specific criterion — “the old infrastructure is decommissioned once redirects have been verified and one full week of stable analytics data exists on the new site” — rather than left as an open-ended “we’ll keep it around for a while just in case”. An overlap with no defined end date tends to drift, quietly turning a deliberate short-term safety net into the extended, risk-bearing dual-live state this page warns against, simply because nobody made the specific decision to end it.

A short decision guide

Approach	Risk profile
Old site fully decommissioned at the moment of launch	No duplicate-content risk, but no fallback if a critical issue appears
Old site kept privately accessible (internal only) for a defined period	Provides a safety net with minimal duplicate-content risk
Both old and new sites left publicly live simultaneously for an extended period	Genuine duplicate-content and mixed-signal risk; avoid beyond a very short, deliberate window

What to do next

Plan the fallback period as an internal safety net, not a public dual-live period, and set a specific end date for it rather than leaving the old infrastructure running indefinitely “just in case”. For the redirect discipline that makes a clean, single-version cutover possible in the first place, see redesigning without losing rankings. For where this kind of staged rollout fits into a project’s scope, web development services covers the broader delivery process.