Website Migration Checklist: The Hour-by-Hour Launch-Day Order

Most of a website migration checklist is preparation, but the traffic is won or lost in the four hours after DNS changes. That's when redirects go live, the old server starts handing visitors over, and every small mistake (a staging noindex, a temporary redirect, a forgotten www variant) becomes something Google sees.

So this checklist is built around that window. It covers the two weeks before, launch day in hour-by-hour order, and the year after, with the exact cPanel, Plesk and Cloudflare settings that trip people up. It also includes Google's June 2026 update to its site-move guidance, which most checklists haven't caught up with.

It's free and it's all on this page. Print it, copy it into your project tool, or just work down the boxes.

Who this website migration checklist is for

Use it if you're doing any of these:

• Moving hosts with the same domain and URLs (the simplest case, and the shortest list)
• Changing domains, including merging two sites into one
• Changing platforms, like Wix or Squarespace to WordPress
• Restructuring URLs during a redesign

Items marked (domain moves) apply only when the domain or subdomain changes. Items marked (URL changes) apply when any URL changes. Everything else applies to every migration.

If you'd rather hand the whole thing off, describe your move in my migration questionnaire and I'll reply with a plan and a fixed quote within one business day.

Phase 1: Two weeks before launch

This phase is about knowing exactly what you have, so nothing gets lost in the move.

Build the URL inventory (URL changes)

• Export Search Console's Performance report, Pages tab, for the full 16 months it keeps.
• Export the Links report in Search Console (the "Top linked pages" list).
• Export your current XML sitemap and any old ones you can find.
• Pull URLs from server access logs, especially the ones Googlebot still requests.
• Pull long-dead URLs from the Wayback Machine's CDX API.
• Merge, de-duplicate, and give every URL a destination: its closest new page, a 410 (gone) if it was junk, or "unchanged."

Google's site-move guide lists most of these sources and is blunt about why: map your old site's URLs to the URLs for the new site. It also warns against sending many old URLs to the homepage, which Google may treat as a soft 404 (a redirect it counts as a missing page).

## Read-only: list every unique URL the Wayback Machine archived for your domain with a 200 status.
curl -s "https://web.archive.org/cdx/search/cdx?url=example.com/*&fl=original&collapse=urlkey&filter=statuscode:200" > wayback-urls.txt

Set up Search Console properly (domain moves)

• Verify the new domain in Search Console.
• Verify every variant of the old domain: www and non-www, plus any other subdomains that got traffic. Do it now, even for variants you never use.

This is the June 2026 change. Google updated its site-move guidance on June 17, 2026 to say the Change of Address tool should be used for all subdomain variants, including www and non-www. Its help page adds that you should verify all of them, even if you don't actively use them. Verification can take a day if DNS records are involved, so don't leave it for launch day.

Take your baseline

• Note weekly Search Console clicks and the top 20 pages by clicks.
• Note conversions per week (forms, calls, sales) from analytics.
• Save a crawl of the old site (Screaming Frog, free up to 500 URLs, or a similar crawler) so you can compare titles and headings later.

List everything that points at the old site

• Google Business Profile website link
• Google Ads and Microsoft Ads final URLs
• Payment webhooks, CRM forms, no-code automations
• Email (MX) records and any mail the old host sends for you
• Cron jobs (scheduled tasks) on the old server

Email is the classic casualty. If the old host also handled your mail and you change nameservers, mail can stop the same minute.

Phase 2: One week before launch

• Lower the DNS TTL (how long the internet caches your DNS records). Google suggests lowering it to a few hours at least a week in advance. I usually go down to 300 seconds a day or two before launch.
• Build the new site on a password-protected staging copy. A robots.txt block is not a password.
• Install SSL on the new server before launch, not after. On cPanel that's usually AutoSSL. On Plesk, the SSL It! extension handles Let's Encrypt.
• Write the redirect rules from your map and test them on staging.
• Check robots.txt on the new site blocks only what you intend.
• Install and test tracking on staging: analytics, Tag Manager, call tracking, ad conversions.

Check a DNS record's current TTL from any terminal:

## Read-only: the number after the domain name is the TTL in seconds.
dig +noall +answer example.com A

For the redirect rules themselves, my .htaccess 301 redirect guide covers every common pattern, and my free redirect rule generator turns a two-column spreadsheet into Apache, Nginx or Cloudflare rules.

Phase 3: The 48 hours before launch

• Freeze content. No new posts, pages or plugin updates on the old site from now on.
• Take a full backup of the old hosting account: files, databases and email.
• Pick a launch window early in a working week, in the morning, when you and your developer are both around for the next two days. Not a Friday.
• WordPress with Wordfence: if the firewall runs in Extended Protection mode, Wordfence's support team says to remove extended protection before moving to a new server, then optimize it again after. Skip this and the copied site can fail to load because a file path changed.

Launch day, hour by hour

Hour 0 is the moment you change DNS. Everything before it happens on the new server without visitors. Everything after it happens with visitors arriving.

Hour -2: final copy

• For stores and booking sites, switch on maintenance mode so no orders land on the old server mid-copy.
• Copy the final database and the uploads folder to the new server.
• On WordPress domain moves, replace old URLs in the database with WP-CLI. A plain text find-and-replace breaks serialized data (settings stored with each value's length), and WP-CLI's search-replace handles it properly.

## Dry run first: shows how many replacements it would make, changes nothing.
## Then run again without --dry-run. --skip-columns=guid leaves post IDs alone, as WordPress expects.
wp search-replace 'https://old-example.com' 'https://www.new-example.com' --skip-columns=guid --dry-run

Hour -1: test the new server before anyone sees it

• Remove the staging password and any noindex header.
• In WordPress, untick Settings > Reading > "Discourage search engines from indexing this site." This is the single most common launch-day mistake.
• Test the new server directly, before DNS points at it:

## Read-only: asks the NEW server (203.0.113.10 here) for your site, ignoring public DNS.
## Look for "200" and your real page title. Replace the IP with your new server's.
curl -s --resolve www.example.com:443:203.0.113.10 https://www.example.com/ | grep -i "<title>"

Hour 0: switch DNS

• Update the A record (or nameservers) to the new server.
• cPanel: edit the record in the Zone Editor if your DNS lives on the old host.
• Cloudflare: change the origin IP on the proxied A record. Proxied records use a fixed TTL of 300 seconds, so the switch is quick. Set SSL/TLS mode to Full (strict). On Flexible mode, Cloudflare talks to your server over plain HTTP, and if the server redirects HTTP to HTTPS, you get a redirect loop.

Hour 0 to 1: redirects and the basics

• Turn on redirects on the old domain (domain moves) or the new site (URL changes).
• Run your full URL inventory through a redirect check. Every old URL should land on the right page in one 301 hop. A 302 is a mistake to fix today (my explainer on permanent versus temporary redirects covers why).
• Test the homepage, top five pages, every form, checkout, and outgoing email.

## Read-only: for each old URL print status code, number of hops, final URL, original URL.
while read -r url; do
  curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} %{url_effective} $url\n" "$url"
done < old-urls.txt > launch-redirect-report.txt

Hour 1 to 2: Search Console

• Submit the new XML sitemap in the new property.
• (Domain moves) File the Change of Address request from each verified variant of the old domain. Google needs a 301 from the old homepage to the new one before it accepts.
• Use URL Inspection on your top ten pages to confirm Google sees them as indexable.

Hour 2 to 3: tracking and ads

• Watch real-time analytics for live visits and fire one test conversion of each type.
• Update Google Ads and Microsoft Ads final URLs to the new addresses. If any ad still points at a redirected URL, check the click ID survives. Google says the GCLID must be passed to the final landing page for conversions to track.
• Update the website link in your Google Business Profile.

Hour 3 to 4: clean-up on the new server

• Re-optimize the Wordfence firewall if you removed Extended Protection.
• Clear and warm the page cache.
• Check the server error log for PHP errors and 500s.
• Crawl the new site for internal links still pointing at old URLs, and fix them at the source so visitors skip the redirect.

End of day

• Keep the old host running. Google's guide for host moves suggests waiting until traffic to the old provider reaches zero before shutting it down.
• Write down what changed today, in one place, with times.

cPanel, Plesk and Cloudflare gotchas

These are the panel settings that cause most of the launch-day surprises I get asked to fix.

After launch: day 1 to year 1

• Days 1 to 3: check server logs and Search Console for 404s on old URLs. Add any missing redirects.
• Weeks 1 to 4: watch indexing in Search Console on both the old and new properties. Old-site traffic should fall as new-site traffic rises. Google's site-move guide says a medium-sized site can take a few weeks or more for the new URLs to show, so temporary fluctuation is normal.
• Day 30: compare clicks, top pages and conversions against your baseline. If a page lost most of its traffic, check its redirect and its content first.
• Day 180: the Change of Address tool's effect lasts 180 days. Leave redirects in place well beyond this.
• Year 1 and beyond: Google asks for redirects to stay "generally at least 1 year" and for the old domain to stay registered for at least a year. My advice is to keep both indefinitely. Old links don't expire.

How to use this checklist

Copy the boxes into whatever you track work in. Put a name next to each one, because "someone will do it" is how the Search Console variants never get verified. Then schedule Phase 1 for real dates, counting back from a launch day that isn't a Friday.

If you're redesigning rather than moving, the SEO freeze addendum for your designer covers the extra rules for a redesign: keeping ranking copy, staging and tracking.

When to call a pro

Some moves are fine to run yourself with this list: a host-to-host move with the same domain and URLs, on a small site, with a host that does the copy for you. Get help when:

• The domain is changing and the site has years of links pointing at it
• The platform is changing and URLs will look different
• The site sells online, or leads arrive through forms and calls you can't afford to lose
• A previous migration already lost traffic and nobody knows why

That's the work I do: done-for-you site moves with launch-day testing and 30 days of monitoring. Host-to-host moves start at $300, and domain changes or replatforms start at $2,500.

Next step

Work through the list, and if any box makes you hesitate, send me the details through the migration questionnaire. You'll get a plan and a fixed quote, and I'm happy to tell you if the move is simple enough to do yourself.