Define the Migration and Its Risks
A migration may change the CMS, framework, hosting, domain, URL structure, design, content, analytics, or several of these at once. Each change introduces a different failure mode. A replatform with stable URLs is not the same project as a redesign with thousands of redirects and a domain move. Name the changes explicitly so the team can isolate risk.
Set success criteria for organic visibility, qualified conversions, speed, accessibility, and operational publishing. Establish owners for SEO, engineering, content, analytics, legal, and business operations. Agree on what would pause launch or trigger rollback; rankings fluctuate naturally, so criteria should focus on material errors and sustained business impact rather than one day of movement.
- Classify the project: platform, URL, domain, content, design, or mixed migration.
- Protect a staging environment from indexation while allowing realistic crawl and QA.
- Create a decision log for scope changes and deferred cleanup.
- 1
Discover
- 2
Map
- 3
Build
- 4
Validate
- 5
Launch
- 6
Monitor
Capture a Baseline Before Touching Production
Crawl the current public site and export indexable URLs, status codes, titles, canonicals, directives, headings, internal links, structured data, images, and language or pagination signals where used. Join that inventory with Search Console pages and queries, analytics landing pages and conversions, backlink data, sitemap URLs, and server logs when available. The goal is to know what matters before deciding what can be removed.
Save representative screenshots and manual recordings of critical journeys, including forms, calls, booking flows, navigation, and confirmation pages. Record current performance and accessibility observations by template and device. Preserve the baseline in a versioned location so post-launch comparisons are reproducible rather than based on memory.
- Identify high-value URLs by clicks, conversions, links, rankings, and strategic importance.
- Export redirect history and known legacy URLs, not only currently linked pages.
- Document third-party scripts, consent behavior, integrations, and operational dependencies.
Crawl
Search demand
Conversions
Links
UX and performance
Map URLs, Content, and Intent
Build a source-to-destination map for every changed or removed URL. Prefer a one-to-one redirect to the closest equivalent page; do not send unrelated URLs to the homepage simply to eliminate 404s. If content is intentionally retired with no substitute, return an appropriate status and remove internal links rather than creating a misleading destination.
Review content changes independently from template changes. Preserve passages that earn visibility or answer real customer questions, while correcting outdated, duplicate, or unsupported claims. Keep titles, headings, internal links, structured data, media alternatives, and visible service or location facts aligned. A new design is not permission to discard the evidence that made a page useful.
- Include old sitemap URLs, analytics landings, backlinks, and known campaign URLs in the mapping.
- Flag chains, loops, protocol changes, trailing-slash differences, and case changes for testing.
- Give each destination an owner who can verify intent and business accuracy.
Equivalent page → 301/308
Consolidated intent → best canonical destination
Retired with no substitute → deliberate 404/410
Unknown legacy URL → investigate before deciding
Build Technical Parity Before Improvements
The new platform should render the primary content and links in a way users and crawlers can access. Check server responses, canonical tags, robots directives, XML sitemaps, hreflang where applicable, breadcrumbs, structured data, image handling, pagination, and internal links. Client-side rendering can be appropriate, but do not assume that a browser screenshot proves a crawler receives the same content.
Preserve or intentionally improve page templates, metadata, redirects, headings, accessibility, performance, and measurement. Test authentication boundaries and preview tools so staging content cannot leak into production. Keep deployment configuration—environment variables, cache rules, headers, compression, and error pages—in version control and review it like application code.
- Use absolute, canonical production URLs in production metadata and sitemaps.
- Ensure 404 and 500 responses have correct status codes and useful recovery links.
- Verify forms, calls, consent, analytics, CRM delivery, and spam controls on the new stack.
- 1
Rendered content
- 2
Crawl directives
- 3
URLs and links
- 4
Schema and metadata
- 5
Conversion systems
Run Prelaunch QA on the Rendered Site
Automated crawls catch breadth; manual tasks catch meaning. Crawl the staging site with the same templates and edge cases found in the baseline, then compare URLs, status codes, titles, canonicals, headings, links, media, schema, and word-level content. Test redirect destinations from a sampled and high-value list. Validate that staging remains blocked without accidentally preventing the production release.
Walk critical journeys on real devices and keyboard-only. Submit valid and invalid forms, tap phone links, test consent choices, refresh during a submission, and verify confirmation and CRM delivery. Check responsive breakpoints, focus behavior, error recovery, slow loading, and third-party failure states. Have content owners review factual claims and operations owners verify routing and availability.
- Test top pages plus random samples from every page template and redirect class.
- Validate JSON-LD against visible facts and inspect the final HTML, not only source components.
- Keep signed QA evidence with browser, device, date, URL, result, and defect owner.
Control the Launch Window
Choose a launch window with engineering, support, analytics, and business owners available. Take a final baseline and content backup, lower operational uncertainty, and prepare the redirect file, sitemap, robots rules, DNS or hosting changes, cache plan, and rollback artifact. Do not combine unrelated campaigns or large content pruning unless the project explicitly accounts for the additional risk.
At launch, verify the canonical domain, protocol, indexability, representative redirects, home and priority pages, forms, calls, analytics, and server error rates immediately. Submit the current sitemap and use inspection tools for priority URLs. Keep a short change freeze while monitoring so a defect can be attributed to the migration rather than hidden in simultaneous edits.
- Deploy redirects atomically with the new URL set where the platform allows.
- Remove staging noindex and test that production is not accidentally blocked by robots rules.
- Record the exact release version, time, owners, and rollback decision path.
- 1
Deploy
- 2
Smoke test
- 3
Crawl sample
- 4
Verify conversions
- 5
Monitor and decide
Monitor Recovery and Learn From Exceptions
For the first days and weeks, monitor server errors, redirect hits, crawl stats, index coverage, canonical selection, sitemap processing, query visibility, organic landing pages, qualified conversions, call routing, and performance. Segment by directory, template, device, and market. A site-wide average can hide a broken service directory or an entire class of city pages.
Investigate exceptions by comparing the old and new URL, rendered content, internal links, response headers, and external references. Fix broken paths promptly, update links that still point through redirects, and communicate meaningful changes to stakeholders. Rankings may settle over time, but missing pages, blocked resources, lost events, and incorrect canonical signals should not be explained away as normal volatility.
- Create alerts for spikes in 4xx/5xx responses, form failures, and missing conversion events.
- Compare qualified leads and revenue, not only sessions and positions.
- Keep redirect rules and migration notes as maintained operational assets.
Crawl health
Indexation
Visibility
Qualified demand
UX and performance