A useful website migration checklist covers preparation, staging verification, cutover, and post-launch monitoring. Every critical task needs a named owner, an expected result, and evidence that it passed. A working homepage is not enough: important URLs, inquiries, bookings, account access, and measurement must survive the move too.
Start by identifying what will actually change. A hosting-only move with unchanged URLs needs different search checks from a move to a new domain.
Identify what is changing
All migrations require content, customer-journey, measurement, access, and recovery checks. Add the technical checks that match your move:
| Migration type | Additional focus |
|---|---|
| Hosting only; protocol, hostname, and paths stay identical | Test infrastructure and traffic transition. No new migration redirects or Change of Address are needed. |
| CMS changes; public URLs stay the same | Compare templates, content, integrations, and generated URLs against the existing site. |
| URL paths change | Map old URLs to intentional outcomes and implement permanent redirects where relevant replacements exist. |
| Domain or subdomain changes | Add domain-level mapping, redirects, ownership checks, and Change of Address where eligible. |
A domain change does not necessarily involve a hosting change. Conversely, Google’s hosting-move guidance specifically covers infrastructure changes without user-visible URL changes.
Where practical, separate major changes so problems are easier to isolate.
Before the move: assign owners, inventory assets, and verify backups
Use one shared worksheet throughout the migration:
Task | Named owner | Expected result | Evidence link and timestamp | Status | Escalation contact
Assign people—not just departments—to these responsibilities. One person may hold multiple roles:
- Business owner: approves critical customer paths and acceptable risk.
- Project manager: coordinates cutover and collects sign-offs.
- Developer: handles deployment, infrastructure, and restoration.
- SEO lead: validates URLs and search-related checks.
- Marketing or analytics lead: validates measurement.
- Sales or operations: confirms that inquiries reach the right destination.
Build the inventory from a crawl, CMS exports, sitemaps, analytics, Search Console, and available logs or backlink records. Include important PDFs, images, campaign pages, forms, booking tools, integrations, metadata, and existing redirects—not just navigation pages.
Save representative baselines for traffic, search clicks, landing-page performance, and inquiries. Note seasonality and campaigns that could distort comparisons.
Back up files, databases, uploads, configuration, redirect rules, and relevant tag settings. Protect secrets separately. Require an isolated restore test: a backup-success notification does not establish that the site can be recovered.
Confirm company-controlled access through actual sign-ins, appropriate permissions, and recovery access for the registrar, DNS, hosting, CMS, Search Console, analytics, tag manager, booking tools, and integrations. Record who controls each account; never put passwords in the worksheet.
Before the move: map every important old URL
Preserve existing URLs where feasible rather than changing them for cosmetic reasons. For changed or removed addresses, website redirect mapping should give every in-scope URL a deliberate outcome.
The following is a hypothetical map for example.com:
| Old URL | Decision | Destination | Expected response | Approver / test evidence |
|---|---|---|---|---|
/contact | Retain | /contact | 200 | Content owner / response check |
/services/old-name | Replace | /services/new-name | 301 → 200 | Marketing / redirect report |
/guide-a and /guide-b | Consolidate | /complete-guide | Each 301 → 200 | Content owner / relevance review and response checks |
/expired-offer | Remove; no relevant replacement | None | 404 or 410 | Content owner / response check |
Consolidation is appropriate only when the destination substantively covers the old content. Do not redirect every removed page to the homepage. Include downloads whose addresses change.
Marketing or content owners approve relevance; the developer implements the rules; the SEO lead validates them. Google supports permanent server-side 301 and 308 redirects; the example above uses 301.
Request or crawl the entire mapped list, comparing actual responses and final destinations against the worksheet. Manually review priority destinations for equivalent content. Test relevant hostname and protocol variants and meaningful query-string behavior, such as campaign or filtering parameters. Resolve loops, incorrect destinations, and avoidable redirect chains.
Staging verification: test search access and complete customer journeys
Keep staging access-restricted. If an accessible test hostname uses noindex, remember that Google must crawl a page to read that directive; blocking it in robots.txt can prevent that. Neither robots.txt nor noindex replaces private access controls.
Have the developer and SEO lead compare staging against the inventory:
- Important content, images, and downloads are present.
- Titles and navigation match the approved requirements.
- Internal links are configured for final URLs. Use an environment-appropriate test setup to ensure you are testing the new build rather than following links back to the old live site.
- Canonical tags identify intended production URLs, and sitemap URLs agree with those destinations.
- Redirect rules pass through an environment-appropriate test mechanism.
- HTML robots directives,
X-Robots-Tagheaders, and robots.txt have been reviewed.
Record exactly which restrictions must be removed from production while staging remains protected. Consistent canonical signals help communicate preferred URLs; they do not guarantee Google’s selection.
Test the business action, not just the confirmation screen
On mobile and desktop, submit every important form with identifiable test data. Check validation, confirmation, actual inbox or CRM receipt, and the intended follow-up. Complete a test booking through calendar creation and confirmation, then clean it up. Test call links and downloads where applicable.
For each measured action, record the expected event name, analytics property or stream, parameters, and intended count. Confirm that successful actions do not create duplicate success events and failed submissions do not fire success events.
GA4 DebugView can help inspect collected events and parameters with debug mode enabled. Test under the relevant consent state; privacy controls may affect visibility. An analytics event does not prove that an inquiry reached the business. Keep test traffic identifiable and separate or appropriately filtered in reporting.
Cutover: use a signed launch acceptance checklist
The project manager should collect pre-cutover sign-offs based on staging tests, account access, and recovery readiness. These authorize deployment; they do not require evidence from a release that has not happened yet. Immediately after release, repeat the critical checks on the public production site and record fresh evidence:
| Check | Responsible role | Passing production evidence |
|---|---|---|
| Search access | Developer + SEO lead | Important public URLs return expected 200 responses, allow crawling, lack unintended noindex, and reference intended production canonicals. |
| Redirects | Developer + SEO lead | Mapped changed URLs reach approved final pages. |
| Forms | Sales/operations | An identifiable production test reaches the responsible inbox or CRM. |
| Booking, if applicable | Operations | Test appears in the correct calendar and confirmation arrives. |
| Analytics | Analytics lead | Expected event reaches the intended destination without duplication under the tested consent state. |
| Ownership | Business representative | Successful access to critical accounts is recorded. |
| Recovery | Developer + decision-maker | Tested restore procedure and recovery runbook are available; decision-maker is reachable. |
Passing the search-access row supports eligibility for crawling and indexing, not guaranteed indexing.
Schedule a lower-traffic window with the necessary support available. Agree on a content freeze or final synchronization, declare which data store is authoritative, and take a timestamped final backup.
Change DNS only if the environment requires it. Inventory dependencies and obtain provider-specific instructions; a website migration does not automatically mean moving email hosting.
Release redirects and the intended production access settings together. Retain Search Console verification. If URLs changed, submit the updated sitemap; otherwise, confirm that the existing sitemap remains correct and accessible. Sitemap submission is a hint, not an indexing guarantee.
Use Change of Address only for eligible domain or subdomain moves after redirects work. The same Google account must own both Search Console properties. Follow the tool’s requirements for applicable hostname variants. The tool is not for hosting-only moves, same-domain path changes, HTTP-to-HTTPS changes, or www/non-www changes.
Update controlled advertising, profile, and campaign links. Do not create a new analytics property merely because the site moved; document any intentional measurement changes so later comparisons remain meaningful.
Delay launch or roll back against agreed failure conditions
We recommend delaying launch for missing recovery or account access, failed critical forms or bookings, widespread unintended search blocking, or incorrect priority redirects.
Before cutover, define site-specific severity thresholds, observation windows, and decision deadlines. Name the business owner or incident lead who can authorize recovery, and the developer responsible for execution.
After launch, sustained unavailability, lost critical submissions, serious data corruption, or security exposure requires immediate incident escalation. Decide whether fixing the live system or performing a safe rollback better protects customers and data.
Restoring a pre-launch database can discard inquiries, bookings, orders, and edits received afterward. Old software may also be unable to read a changed schema or data format—a risk explained in AWS’s rollback-safety guidance.
Rehearse how records from both environments will be preserved, reconciled, and deduplicated, or agree on a write pause or fallback. Avoid blind database restoration or automatic DNS reversal.
Reversing a domain move also requires coordinated redirect and Search Console handling to avoid loops. Ordinary ranking fluctuations alone are not a rollback trigger: Google notes that temporary fluctuations can occur during URL migrations, without promising a fixed recovery date.
After launch: monitor, assign fixes, and close the migration
Use this adaptable monitoring cadence—not as a search-recovery forecast:
| When | Owner | Review |
|---|---|---|
| Cutover and first hours | Developer | Availability, errors, traffic routing, and submission delivery |
| Daily during the first week | SEO and marketing | Priority redirects, unintended 404/5xx errors, indexing and canonical issues, landing-page traffic, and inquiries |
| Weekly afterward until stability criteria pass | Project manager | Trends, unresolved tickets, retest evidence, and handover readiness |
Compare like-for-like periods using Search Console, server logs, analytics, and backend inquiry records. A tracking break can look like lost demand; operational records help distinguish them. Every issue needs a severity, owner, due date, and retest evidence.
Google recommends keeping permanent migration redirects generally for at least one year, and longer where useful. Retain old-domain control and a working arrangement to serve those redirects. This differs from retiring old hosting after an unchanged-URL move, once traffic has fully shifted and correct delivery is established.
Close the migration only when the URL map is approved, customer actions and measurement have production evidence, new submissions are reconciled, recovery accounts for post-launch data, and no critical defects remain. Then assign a recurring website maintenance owner so monitoring and fixes continue beyond launch.
If your already-approved migration includes a redesign, explore Kohl Digital’s Website Redesign service for business-focused structure, customer journeys, and SEO preservation planning.