Website Migration Checklist: Plan, Move, Verify, and Monitor

Website migration checklist: define what is changing

A website migration checklist should begin with one precise description of the move. A domain change, a www or subdomain change, an HTTP-to-HTTPS move, a URL restructure, a CMS replacement, and a host or CDN change do not share the same risks. Record which of those is happening and name the things that will stay unchanged.

Google recommends changing one major thing at a time. Combining a redesign, platform replacement, and domain move makes a later traffic change difficult to diagnose. When several changes are unavoidable, sequence them and establish a stable baseline between releases.

• Domain or hostname
• Protocol or URL structure
• CMS or website builder
• Host, CDN, or DNS provider
• Templates, content, navigation, and tracking that are explicitly out of scope

Inventory the current site before building the replacement

Create the evidence you will use to prove the move worked. Crawl the current URLs and record status codes, titles, canonicals, robots directives, structured data, internal links, and existing redirects. Export the current sitemap, important organic landing pages, conversions, and backlinks. Store these records outside the environment being replaced.

Inventory the operational system too: DNS records, certificates, forms, email routing, analytics, consent tooling, payments, bookings, webhooks, and scheduled jobs. Preserve a verified files-and-database backup when the platform uses both. A migration is not complete when pages load but enquiries, email, or checkout no longer work.

Build a one-to-one URL and redirect map

For every old URL, record one deliberate destination. A direct equivalent should move to its matching page. Merged pages can share a relevant survivor. Content with no useful replacement should return an honest 404 or 410 instead of being sent indiscriminately to the homepage.

Test the map for missing URLs, loops, duplicate rules, and chains. Internal links and canonicals on the new site should point directly to the final URLs rather than depending on redirects. Keep the redirect layer auditable and reversible, whether it lives at the edge, web server, or application.

• Use a permanent redirect for a permanent page move
• Use 301 for conventional GET page moves
• Consider 308 when preserving a non-GET request method and body matters
• Reserve 302 or 307 for genuinely temporary behavior

Test the new environment without letting it get indexed

Protect staging with authentication, an allowlist, or a private network. A robots rule is not access control. If staging also uses noindex or a robots disallow, assign removal of those directives as an owned launch task so they cannot follow the site into production.

Check production canonicals, direct internal links, metadata, structured data, redirects, responsive layouts, accessibility, and representative performance. Submit every form and confirm that its notification actually arrives. Test payment, booking, CRM, analytics, consent, and other integrations from end to end.

Prepare DNS, certificates, cache, and rollback

Lower relevant DNS TTLs ahead of the cutover, issue the new certificate before traffic moves, and document every cache layer and purge step. Keep the previous environment available long enough to reverse the cutover or serve redirects while crawlers and visitors discover the new URLs.

Write measurable rollback triggers and the exact reversal order. A statement such as 'roll back if traffic looks wrong' is not actionable. A failed primary form, sustained server errors, or a broken checkout can be measured, assigned, and tested.

Run the launch-day website migration checklist

Verify blocking directives first, then confirm the priority redirects are single-hop and correct. Check that new pages return 200, removed pages return their intended status, canonicals reference production, internal links use final URLs, and the updated sitemap contains only canonical destinations.

Next verify assets over HTTPS, forms and email delivery, analytics and conversions, and the journeys that produce a lead, booking, or sale on both mobile and desktop. Record who checked each item and when. A written result is more useful than a box ticked from memory.

• robots.txt, meta robots, and canonicals
• Priority and sampled redirects
• Sitemap and representative indexable pages
• Images, scripts, fonts, and downloads
• Forms, email, payments, bookings, and integrations
• Analytics, consent, and conversion events
• Mobile and desktop business journeys

Use Search Console for the type of move you made

Submit the new sitemap and retain access to the old Search Console property so both sides of a URL-changing move can be monitored. Google's Change of Address tool is for an eligible domain or subdomain move after redirects are working. It is not the mechanism for HTTP-to-HTTPS, www-only changes, path changes on one domain, or infrastructure changes that leave public URLs unchanged.

Some ranking fluctuation is normal while Google recrawls and reprocesses a move. Avoid stacking unrelated releases into the first monitoring period. That discipline preserves your ability to connect an observed problem to a specific change.

Monitor by hour, day, week, and month

In the first hours, watch errors, redirect behavior, certificates, forms, email, checkout or booking, and real-time analytics. In the first days, review crawl errors, 404 logs, redirect chains, and page-level traffic against the pre-move export. Missing rules often appear first through old links that were absent from the crawl.

Over the following weeks, monitor indexing, priority queries, important backlinks, conversions, and the old URLs leaving search. Keep the redirects in place and ask high-value referring sites to update their links directly. Once the new environment is stable, verify that its backup and restore process works before retiring the old system.

Copyable website migration record

Keep one record for each move. Complete it before launch, update it during the cutover, and retain it with the crawl, URL map, DNS export, and verification results.

WEBSITE MIGRATION RECORD

Site:
Migration type:
What is changing:
Explicitly not changing:

OWNERS
Migration owner:
Technical owner:
Rollback decision maker:

DATES
Inventory completed:
URL map reviewed:
Planned cutover (include timezone):
Actual cutover:
Old environment retained until:

ARTIFACTS
Current crawl:
Traffic and top-pages export:
Backlink export:
DNS export:
Verified backup and restore-test date:
URL map:
Redirect implementation:

ROLLBACK
Measurable triggers:
Procedure:
Estimated time:

LAUNCH RESULT / OWNER / TIME
Blocking directives removed:
Priority redirects verified:
Canonicals and internal links verified:
Sitemap submitted:
Forms and email verified:
Analytics and conversions verified:
Mobile journey completed:
Desktop journey completed:

POST-LAUNCH
Hour-one check:
Day-one check:
Week-one check:
Month-one check: