Most website migration checklists are long lists of tasks. This one is organized differently: around the things that actually break when a site moves, because those are what you need to protect. Use this website migration checklist whether you are changing hosts, rebuilding on a new platform, consolidating domains or doing all three.

We built it from our own move of shiptronix.com to Cloudflare and from client migrations. In almost every case, the problems that surface after launch are predictable. Nobody planned for the contact form's mail function, the old campaign URLs, or the verification record a vendor added years ago. Each section below names a failure, explains why it happens, and lists the checks that prevent it.

If you want the step-by-step process for the move itself, read moving your website to new hosting without downtime first. This checklist is the companion you work through alongside it.

1. Old URLs stop working

What breaks: Pages move or get renamed, nobody builds redirects, and every bookmark, inbound link and search result pointing at the old address now returns a 404. Search rankings for those pages decline because the signals attached to them have nowhere to go.

Checklist:

  • Export every URL from the current site: the sitemap, analytics landing pages for the last 12 months, and the pages report in Google Search Console.
  • Add URLs from paid campaigns, email signatures, printed materials and QR codes. These rarely appear in a sitemap.
  • Map each old URL to its new URL in a spreadsheet. If a page is being retired, map it to the closest relevant page, not the home page.
  • Implement permanent redirects (301 or 308) directly from old to final URL, with no chains.
  • Test the full list after launch and confirm each returns either a 200 or a single redirect to the right destination.
  • Plan to keep redirects in place for a long time. Google's site move guidance says generally at least a year.

2. Redirect services and old domains get orphaned

What breaks: Secondary domains, old brand names and campaign domains often redirect to the main site through the old host, a plugin or a separate redirect service. When the old host is cancelled, those domains go dark.

Checklist:

  • List every domain the business owns and where each one currently points.
  • Find where each redirect is configured today: the host control panel, an .htaccess file, a CMS plugin or a third-party redirect service.
  • Rebuild the redirects on the new setup. In our own move we replaced a separate redirect service with redirect rules on Cloudflare so everything lives in one place.
  • Confirm both the root and www versions of each secondary domain redirect correctly over HTTPS.

3. Forms stop delivering

What breaks: The form looks fine and shows a thank-you message, but submissions never arrive. Older sites often send form mail through the host's built-in mail function, which does not exist on the new platform. This is the most expensive silent failure on a lead generation site.

Checklist:

  • Inventory every form: contact, quote request, newsletter signup, careers, support.
  • Document where each one sends data today: an email address, a CRM, a spreadsheet, a marketing platform.
  • Rebuild delivery on the new host. We store every submission in a database as well as emailing it, so nothing is lost if mail has a problem.
  • Send form mail from a dedicated subdomain with its own SPF and DKIM, so form traffic never affects your main domain's reputation.
  • Re-add spam protection. Our article on Cloudflare Turnstile for contact form spam covers the layered setup we use.
  • Submit every form on staging and again on the live site after launch, and confirm the message arrives where it should.

4. Email breaks during the DNS change

What breaks: If the migration includes moving DNS, mail records can be lost in the move. Inbound email bounces, or outbound mail starts failing authentication and landing in spam.

Checklist:

  • Export every DNS record before changing anything, including MX, SPF, DKIM, DMARC and verification TXT records.
  • Recreate every record at the new DNS provider before switching nameservers.
  • If DNSSEC is enabled, plan for it. Cloudflare's guidance is to disable it at the registrar before changing nameservers and re-enable it afterward.
  • After the switch, send test messages in both directions and check headers for SPF, DKIM and DMARC passes.

Our full guide to DNS migration to Cloudflare covers this in detail.

5. SSL certificate gaps

What breaks: Visitors see a browser security warning on launch day, or a secondary domain works on HTTP but shows an error on HTTPS.

Checklist:

  • Confirm how the new host issues certificates and whether it needs DNS to point at it first.
  • Make sure the certificate covers the root domain, www and any subdomains in use.
  • Check every secondary domain that redirects to the main site. Each needs a valid certificate on HTTPS before it can redirect.
  • Force HTTPS on the new site and confirm HTTP requests redirect cleanly.

6. Staging gets indexed, or production gets blocked

What breaks: Either the staging copy shows up in Google as a duplicate of your real site, or the noindex rule used to hide staging ships to production and the live site drops out of search.

Checklist:

  • Protect staging with a noindex header or password. We send an X-Robots-Tag: noindex header from our staging environment.
  • Make the noindex setting environment-specific so it cannot follow the code to production.
  • After launch, check the live site's response headers, meta robots tags and robots.txt.
  • Use the URL inspection tool in Search Console on a few key pages to confirm Google sees them as indexable.

7. Tracking and marketing tags go missing

What breaks: Analytics shows a traffic drop that is not real, ad platforms stop recording conversions, and remarketing audiences stop growing.

Checklist:

  • List every script on the current site: analytics, tag manager, ad pixels, chat, heatmaps, consent banner.
  • Confirm each one is installed on the new site and fires on the right pages.
  • Recreate conversion events, especially form submissions and thank-you pages, and test them.
  • Annotate the launch date in analytics so later reports make sense.

8. SEO details get lost in the rebuild

What breaks: Rankings slip not because of the move itself but because page titles, descriptions, headings, structured data or internal links were simplified in the new design.

Checklist:

  • Carry over page titles and meta descriptions for every page that ranks.
  • Preserve canonical tags and structured data where they exist.
  • Check that internal links point at new URLs directly, not through redirects.
  • Submit a new sitemap in Search Console and remove the old one once the new one is in use.
  • If the domain itself is changing, use the Change of Address tool in Search Console.

9. Verification and integrations fail later

What breaks: Weeks after launch, a service reports that your domain is unverified or an integration stops syncing. A verification file or DNS record did not come across.

Checklist:

  • Look for verification files in the site root (often HTML files with long random names) and copy them to the new site.
  • Look for verification TXT records in DNS and keep them.
  • List integrations that call your site: payment webhooks, booking systems, CRM tracking, embedded widgets.
  • Test each one after launch.

10. Nobody can roll back

What breaks: Something serious goes wrong after cutover and the old host has already been cancelled, or the DNS TTL is so long that a fix takes a day to reach visitors.

Checklist:

  • Lower TTLs on records you will change at least a full TTL period before cutover.
  • Keep the old host running unchanged for at least a couple of weeks after launch.
  • Write down the exact old record values so you can revert in minutes.
  • Raise TTLs again and retire the old host only after traffic, forms and email are confirmed.

Launch day summary

When Check
A week before URL map complete, redirects built, forms tested on staging, DNS exported
Two days before TTLs lowered on records you will change
Cutover DNS updated, SSL valid on all names, forms submitted live, email tested
First week 404s reviewed, Search Console monitored, analytics and conversions confirmed
After two weeks TTLs raised, old host retired, documentation updated

If this list feels like more than your team has time for, this is exactly what our website hosting and migration service handles, including the follow-up week where most issues surface.

Frequently asked questions

What is the most common thing that breaks in a website migration?

In our experience, broken redirects and forms that stop delivering are the most common. Both are easy to miss because the site still looks fine. Building a full URL map and testing every form on the live site after launch catches most of them.

How long should I keep redirects after a migration?

Google recommends keeping redirects for as long as possible, generally at least a year. We usually leave them in place indefinitely, since they cost almost nothing and old links keep appearing for years.

Do I need to tell Google when I migrate my website?

If the domain stays the same, submit a new sitemap in Search Console and monitor indexing. If you are moving to a new domain, also use the Change of Address tool so Google connects the old and new sites.

Should I migrate hosting and redesign the site at the same time?

It is possible, but it makes problems harder to diagnose. If rankings or conversions drop, you will not know whether the cause was the move or the design. Where the schedule allows, move first with the same pages, then redesign.

How do I know my email still works after a migration?

Send messages to and from the domain using outside accounts, and check the message headers for SPF, DKIM and DMARC passes. Repeat for each service that sends as your domain, such as your marketing platform and website forms.