Website Migration Checklist: What to Check Before and After Launch

A website migration is not complete when the new homepage loads. Existing links must lead somewhere appropriate, important journeys must still work, and the people responsible for the service must know how to respond if something breaks. Treat migration as a controlled operational change with evidence, approval, and follow-up.

This checklist covers moves involving hosting, content management systems, domains, or URL structures. Adapt it to the changes actually planned: a hosting-only move with unchanged addresses does not require the same redirect work as a domain change. Record non-applicable checks with a reason rather than silently deleting them.

Define the move and launch authority

Write down what changes and what stays the same: domains, hosting, page addresses, content, application data, integrations, and analytics. Assign a release owner, a final approver, and technical contacts who can act during the launch window. Confirm access to the relevant accounts before that window begins.

Where possible, avoid bundling a domain change, redesign, and platform replacement into one event. Google's site-move guidance recommends changing one thing at a time and warns that rankings can fluctuate while pages are recrawled and reindexed.5 A migration plan can reduce avoidable errors; it does not ensure unchanged search traffic.

Agree which failures block launch and which can be addressed afterward. A broken enquiry journey or missing access control should not be treated like a cosmetic alignment issue.

Capture the current site and recovery plan

Build an inventory from the current site, content system, sitemaps, and available traffic or server records. Include important downloads, images, and addresses that are no longer linked from navigation. Identify business-critical journeys and record their current behaviour.

Save baseline evidence for the comparisons you intend to make: important landing pages, enquiry delivery, search performance, existing errors, and representative page performance. Note the measurement period and configuration. Without that context, a change in reported traffic may be confused with a change in tracking.

Back up the relevant files, data, and configuration, and rehearse restoration in an isolated environment. Document recovery steps, decision authority, and dependencies. For sites accepting orders or submissions, decide how new records will be preserved or reconciled if the old system is restored. Rollback must protect new data, not just restore old pages.

Map URLs and prepare discovery signals

For every existing address, choose an explicit outcome: retain it, redirect it to a relevant replacement, or remove it deliberately. Record the intended destination and response. Review high-value pages first, but do not stop there.

Google recommends permanent server-side redirects, such as 301 or 308, for moved pages and direct destinations rather than unnecessary redirect chains.5 Test the mapping, including query strings where they affect functionality. Do not send unrelated retired pages to the homepage merely to avoid an error count.

Update internal links, canonical references, and the sitemap to reflect the intended production addresses. Google also advises returning an appropriate 404 or 410 response for removed content that is not being moved.5 Give visitors a useful error page without disguising missing content as a successful response.

Rehearse on the release candidate

Test the exact version proposed for launch, not an earlier preview. Keep previews protected appropriately and separate from production measurement. Record the temporary access and indexing restrictions that must change on production, while preserving protection for private areas and previews.

• Follow navigation, contact, search, login, and transaction journeys where applicable.
• Verify forms through to the receiving system, including failure and validation states.
• Check downloads, images, mobile layouts, keyboard operation, and representative browser combinations.
• Exercise analytics consent choices, saved preferences, and settings changes against the approved requirements.
• Test redirects, missing-page responses, production-domain configuration, and secure connections.
• Review launch instructions, recovery evidence, content freeze arrangements, and unresolved defects with the approver.

Assign each failure an owner and severity. A checklist entry should link to evidence, not merely say someone looked at the page.

Verify immediately after launch

Confirm the intended version is serving on the public domain and check important routes directly. If DNS changes are involved, verify the relevant records and avoid accidentally altering unrelated mail records. Check certificates, redirect destinations, and references to preview hosts.

Repeat critical journeys in a real browser and confirm receipt of authorised test submissions. Inspect production indexing settings, canonical addresses, and sitemap contents. Use Search Console's inspection and reporting capabilities as appropriate; a successful page request from your own machine alone does not establish Google indexing or crawler access.

Keep the recovery decision-maker available until the agreed release checks are complete. Record the actual outcome of each check and communicate remaining issues clearly.

Copy this migration control worksheet

Use one entry per check, with status set to not started, passed, failed, or not applicable. Include a reason for any exception.

• Scope: Changed systems and addresses; unchanged dependencies; release identifier.
• Ownership: Release operator, approver, escalation contact, and recovery authority.
• Before launch: Inventory, baseline, URL mapping, backup, restoration rehearsal, and preview tests.
• Go or no-go: Blocking defects, evidence, approved exceptions, and decision.
• After launch: Public-domain checks, key journeys, redirects, consent, sitemap, and indexing settings.
• Evidence record: Check name, tester, environment, observed result, evidence location, and issue owner.
• Follow-up: Review schedule, metrics, alert triggers, open problems, and next decision.

Continue monitoring errors, enquiries, search reports, and traffic against the baseline after launch day. Investigate discrepancies before declaring success or failure, and retain the redirect and recovery arrangements according to the agreed plan. Bring the completed worksheet to a migration discussion to identify unresolved dependencies before scheduling the move.

References

• 5: Google Search Central guidance for site moves with URL changes