Keeping Old Sites Live During Redesigns

When launching a redesigned website, teams often need to keep the old site accessible — either as a live destination for existing traffic or as an internal reference during development. Handling this incorrectly is a common source of deployment disasters.

Real example: During the ^[1] redesign, the developer built the new site directly on the production environment and kept the old site on staging as a reference. When staging was pushed to production, the new site was overwritten. A backup restore and domain switch were required to recover.

The Core Problem

WordPress environments on platforms like WP Engine have a fixed relationship: staging pushes to production, and production is what the domain points to. You cannot run two distinct sites on the same environment simultaneously — one will always overwrite the other.

This creates a dilemma when you want to:
- Keep the old site live for users while building the new one, or
- Keep the old site accessible internally for reference during development

Each scenario has a different correct solution.

Scenario 1: Old Site Must Stay Live

If the old site needs to continue serving real traffic while the new site is being built, create a separate server for the old site.

Steps:
1. Spin up a new WP Engine instance (or equivalent hosting environment).
2. Copy the old site onto that new server.
3. Point the old domain to the new server — traffic continues uninterrupted.
4. Build the new site on the original server using the standard staging → production workflow.
5. When the new site is ready to launch, redirect the old domain to the new domain via ^[2].
6. Decommission the old server once the redirect is stable.

Why this works: Both sites run independently. There is no risk of one overwriting the other. The old site "purrs along" on its own server while development proceeds cleanly on the new one.

Scenario 2: Old Site Needed for Reference Only

If the old site just needs to be accessible internally — not live to the public — a dedicated development environment is an acceptable option.

Steps:
1. Copy the old site into the development environment (dev) on the same WP Engine instance.
2. Communicate clearly to all team members: this environment contains the old site — do not push it.
3. Use WP Engine's site notes feature to add a warning label (e.g., "DO NOT PUSH — historic reference site").
4. Build the new site on staging as normal, then push to production when ready.

Risks to manage:
- Anyone with access could accidentally push the dev environment to staging, overwriting work.
- There is no platform-level lock to prevent this — it relies entirely on team communication.
- This approach is not suitable if the old site needs to serve live traffic.

The Standard Deployment Workflow

Regardless of what happens with the old site, the correct build workflow is always:

Build on staging → Push to production → Switch domain

Never build directly on production. If a developer builds on production:
- The staging environment becomes out of sync or holds unrelated content.
- A routine staging-to-production push will overwrite the new work.
- It becomes unclear which environment contains the authoritative version of the site.

Domain Switching vs. Pushing

A common point of confusion: once a site is on the correct environment, you do not push it again to make it live. You switch the domain.

The site (files, database, content) lives on a server at a physical location.
The domain is just an address that points traffic to that location.
Switching the domain in ^[2] redirects all traffic to the correct server without touching the site itself.

In WP Engine, setting a domain as "primary" causes the platform to rewrite all internal URLs to match — this can be done before or after a push.

SEO note: If multiple domains resolve to the same content (e.g., the WP Engine default URL and the custom domain both serve the same site), Google may treat it as duplicate content and decline to index either. Always set up redirects so that non-primary domains redirect to the canonical domain.

Questions to Ask Before Starting a Redesign

Before any developer begins work, establish answers to these questions:

Where will the new site be built? (Should be: staging environment)
What happens to the old site? (Reference only, or stays live?)
If it stays live, where will it live? (Separate server required)
Who controls the domain? (Confirm DNS access via Cloudflare or registrar)
What is the launch sequence? (Staging push → set primary domain → redirect old domain → decommission old server)

Documenting this upfront — and communicating it explicitly to developers — prevents the class of incident where assumptions about environment usage lead to data loss.

^[3]
^[4]
^[5]
^[6]