How to Run a Full Site Migration Test Before You Commit

To test website migration before switching hosts, you run the whole move twice: once against a temporary destination that the public cannot reach, and once for real. The first run is the rehearsal, and its job is to surface every broken path, missing extension, stale DNS record and form that silently posts into the void while the live site is still serving traffic.

The single most useful trick is to make the temporary host answer for the real domain name without touching the real domain name. You do that locally, in your own resolver, so that only your machine sees the new server. Everything else on the internet still sees the old one, which means you can click through the entire site as a normal visitor while the migration is still hypothetical.

Point your machine at the staging copy first

Add an entry to /etc/hosts (or the Windows equivalent) that maps the production hostname to the temporary server's IP address. If the site uses both the bare domain and www, map both. If it uses a CDN in front, you have to decide whether you are testing the origin or the edge; test the origin first, because that is where the content actually lives.

# /etc/hosts
203.0.113.10    example.com
203.0.113.10    www.example.com

# verify which server you are actually hitting
curl -sI https://example.com | grep -i server

That curl line is the whole test in miniature. You are asking the new server to identify itself, and if it answers, your resolver change worked. If it hangs or returns a certificate error, stop and fix that before going further, because every later step depends on the staging copy being reachable under the real name.

The certificate matters here. The staging server needs a valid certificate for the real hostname, or your browser will refuse to load the site and you will learn nothing. Many setups let you issue one for the temporary host during the rehearsal, then reissue on cutover day. Confirm that the certificate chain is complete, not just the leaf, because a missing intermediate is one of the classic things that works in one browser and fails in another.

Make the CMS believe it is at home

Most content management systems store the site URL in the database and use it to build every link, every asset path and every redirect. If you restore a database dump onto the staging server and leave those values pointing at the old host, you get a site that loads but whose links all bounce you back to production, which defeats the entire exercise. So the rehearsal has two phases: restore, then rewrite the stored URLs to the staging address, then flip them back when you go live.

Do the rewrite with a search and replace over the dump, or with the tool your platform provides. Do not hand-edit rows. Then confirm the result by asking the database directly rather than trusting the admin panel.

# confirm the stored site URL after the rewrite
mysql -h 127.0.0.1 -u siteuser -p sitedb \
  -e "SELECT option_name, option_value FROM wp_options \
      WHERE option_name IN ('siteurl','home');"

If your platform keeps URLs in a config file instead, the same principle applies: there is exactly one source of truth for the base address, and you should be able to point at the line that holds it. If you cannot find that line, you do not yet understand the application well enough to move it safely.

Rewrite rules and the server config

Migration failures cluster around the web server configuration, not the content. The rewrite rules that turn pretty URLs into query strings are usually generated for one server and pasted into another, and the differences bite. Apache directives do not run under a server that ignores .htaccess, and a proxy layer in front of the application can strip the header your framework uses to detect HTTPS, producing redirect loops that only appear once you are behind the temporary host.

Check the header the application sees. If it reads X-Forwarded-Proto to decide whether the request is secure, and the temporary server does not set it, the application will think every request is plain HTTP and redirect forever. You can inspect exactly what arrives with:

curl -sI https://example.com/ | grep -iE '^(location|strict-transport|x-forwarded)'

A single Location header pointing back at the same URL is the signature of that loop. Fix it at the server or proxy layer, not in the application, and re-test.

Walk the paths that break quietly

Static pages are easy. The things that break quietly are forms, search, feeds, sitemaps, email and anything that writes to disk. Test each one deliberately on the staging copy and watch the server's error log while you do it, because a form that returns a friendly success page while the mail transport rejects the message is the worst possible outcome: nobody finds out until a customer complains weeks later.

For email, do not assume the old host's sending configuration travels with the files. It usually does not. The application may be configured to relay through a local mail agent that does not exist on the new machine, or to authenticate with credentials that are scoped to the old server's IP address. Point the staging copy at a mailbox you control, submit every form on the site, and confirm the messages actually arrive and that the headers show the expected sending domain.

For uploads and generated files, check the directory the application writes to and confirm the web server user owns it and can write to it. This is a permissions problem, not a code problem, and it will not show up until someone tries to upload an image. Do that upload during the rehearsal.

Finally, crawl your own staging copy and compare the response codes against a crawl of production. Any URL that returns a different status code between the two is a finding. That comparison, run as a script, is the closest thing to a guarantee you will get before cutover.

Rehearse the cutover itself

The rehearsal is not finished when the site renders. It is finished when you have practiced the sequence you will run on the day: freeze writes on the old host, take a final database dump, import it, rewrite the stored URLs, clear caches, verify the certificate, and remove your local /etc/hosts override so your machine resolves normally again. Time each step. The duration of that sequence is your real maintenance window, and it is usually longer than people guess.

Write the sequence down as commands, not as prose, and run it end to end at least once on the staging copy. If a step cannot be expressed as a command, it is a step you will fumble under pressure.

What to do next: pick one low-traffic site you own, run this full rehearsal against a throwaway destination, and keep the resulting command list. Once the list is stable and you have watched every form deliver mail and every crawl match, you have something you can reuse on the sites that actually matter. The point of the rehearsal is not confidence, it is evidence.