Zero-Downtime Website Migration Checklist

In short: a zero-downtime website migration checklist has three phases — prepare and inventory, run both environments in parallel while you verify, then cut over DNS with a lowered TTL. The failures that hurt are almost never the file copy. They are missing MX records, forgotten redirects and a database that was still being written to when you copied it.

A website migration checklist earns its keep because migrations go wrong in predictable, documented ways, which means a checklist genuinely prevents most of the pain. The work is in the preparation; the cutover itself should be uneventful.

How we approached this

This is a procedural checklist. RankBoast has not tested migration tooling and names no product — see our review methodology. Where search behavior is involved, follow the search engine’s own documentation, linked at the end.

Phase one: inventory, 24 hours before

1. Export every DNS record and save it somewhere outside both providers. Every record, not the ones you think you use.
2. Lower TTL on the records you will change, to around 300 seconds. Do this early enough that the old TTL expires first.
3. List every hostname the site answers on, including www, staging subdomains and any legacy names still pointed at you.
4. Inventory redirects. Existing rules in server config, plugins or edge rules do not travel with the files.
5. Take a full verified backup, restore-tested, per our backup guide.
6. Record baseline metrics: current response time, top pages by traffic, and current search impressions. Without these you cannot tell whether the move hurt.

The first item on any website migration checklist is that DNS export, because it is the artefact that saves you if the cutover has to be reversed.

The mistake that breaks email

Changing nameservers moves all DNS authority, not just the website records. If mail records live at the old provider and you point nameservers elsewhere without recreating them, email stops — while the site works perfectly, so nobody connects the two for hours.

Copy MX records first, along with the TXT records carrying SPF, DKIM and DMARC. Verify mail delivery before you consider the migration complete.

Website migration checklist phase two: run in parallel

Do not cut over and then check. Bring the new environment up, reachable by a temporary hostname or a local hosts-file entry, and verify against it while the old site still serves real traffic.

• Confirm the database came across intact. Log in, view recent content, check a form submission writes.
• Put the source site in maintenance mode for the final database copy if it accepts writes. A database copied while being written produces subtle corruption.
• Test the top 20 pages by traffic, not the homepage alone.
• Verify certificates on every hostname, including www.
• Check redirects from old URLs, if any paths changed.
• Confirm scheduled jobs and cron exist on the new host. They are routinely forgotten.

Phase three: cutover

With TTL already low, update the records and watch. Keep the old environment running and untouched for at least a week — resolvers, corporate caches and stubborn devices will keep arriving there, and it is your rollback path.

Immediately after cutover: confirm the site resolves to the new host from several networks, send a test email, submit a form, and check server logs on the old host to see traffic tailing off. Once traffic to the old host has stopped and a week has passed, raise TTLs again.

Protecting search visibility

If URLs are unchanged, a hosting move should be close to invisible to search engines. If URLs change, this becomes a different and more delicate task: map every old URL to its closest new equivalent and serve permanent redirects, one hop each. Chained redirects and blanket redirects to the homepage both waste the equity you are trying to preserve.

Google publishes specific guidance for site moves with and without URL changes; follow it rather than improvising. Keep your baseline metrics and compare a fortnight later.

Common website migration checklist failures

Changing nameservers without copying MX. The classic silent email outage.

Not lowering TTL first. Turns a ten-minute cutover into a day of split traffic.

Copying a live database. Freeze writes for the final copy.

Decommissioning the old host immediately. It is your rollback. Keep it a week.

Testing only the homepage. Breakage hides in templates you did not visit.

Forgetting cron jobs and certificates. Both fail quietly, days later.

By situation

• Small site, same URLs: the full checklist takes an afternoon and removes nearly all risk.
• Site with email on the domain: MX and TXT records are your highest risk. Verify mail twice.
• Migration with URL changes: build the redirect map before anything else; it is the bulk of the work.
• Shop or transactional site: schedule a genuine write freeze and announce it.
• Agency moving many sites: script the checklist and record baseline metrics per site.

Verdict

Work through a website migration checklist in three phases and the cutover becomes the least eventful part. Export DNS, lower TTL, copy MX records, freeze writes for the final database copy, verify in parallel, then switch — and keep the old environment for a week. Nearly every migration horror story is one of those steps skipped.

What we would need to test to say more

Comparing migration tools would require repeated migrations of comparable sites with time, data integrity and search impact measured for each. We have not done that and name no tool.

Sources and methodology

Guidance references published documentation from the organizations linked below, retrieved August 2026. RankBoast is independent and took no payment from any provider named. Research and drafting were AI-assisted. Errors are handled under our corrections policy.

Source links

• Google Search Central: site moves with URL changes
• Google Search Central: site moves without URL changes