Website migrations fail in the gaps between teams. Marketing thinks the agency copied every useful page. The developer expects marketing to supply redirects. IT changes DNS but does not know the contact form depends on a record being preserved. The analytics tag appears on the new site, yet no one confirms that a test lead becomes a recorded conversion. A migration plan closes those gaps by naming the asset, the intended destination, the responsible person, the proof that it works, and the fallback if it does not.

Define the move before creating a schedule

Different changes create different migration work.

ChangeWhat stays stableAdded planning burden
New design on the same platformHosting and often the CMSTemplates, content, accessibility, analytics, and release control
New platform, same domain and URLsPublic addressesContent models, functions, hosting, permissions, and operational training
New URLs on the same domainDomain ownershipA complete redirect map, updated internal links, canonicals, and sitemap
New domainBusiness and selected contentDomain verification, cross-domain redirects, Search Console work, DNS, email protection, and extended monitoring
Commerce replatformProducts and customer promiseOrders, payments, tax, shipping, accounts, feeds, inventory, privacy, and checkout continuity

Write one sentence that states the move in plain language: “We are rebuilding the service website in a new CMS, keeping the primary domain, preserving valuable URLs where possible, and replacing the form provider.” That sentence is a scope control. If someone later proposes a new domain, member portal, or CRM, the team can see that the risk and test plan must change. Google separates hosting moves without visible URL changes from moves that change URLs because the required search work differs.

Create the current-state inventory

Inventory the site in six passes

01

Pages and files

Export or crawl every indexable URL, plus PDFs, images, videos, landing pages, campaign pages, thank-you pages, error pages, and subdomains. Add page title, canonical, status code, traffic or lead role, owner, and proposed action.

02

Content structures

Record posts, authors, categories, case studies, services, locations, products, reusable sections, taxonomies, and relationships. A spreadsheet of pages does not reveal the data model needed in the new CMS.

03

Functions and integrations

Submit every form and trace the result. List scheduling, chat, search, CRM, email marketing, payments, reviews, maps, consent, translation, feeds, calculators, member access, and webhooks.

04

Measurement

List analytics properties, tag containers, advertising pixels, consent rules, important events, call tracking, dashboards, Search Console properties, and the person who can validate each account.

05

Infrastructure and access

Identify registrar, DNS host, website host, CDN, SSL, email provider, repositories, deployment tools, billing owner, administrators, service accounts, and recovery methods. Never store shared passwords in the plan.

06

Policies and obligations

Capture privacy notices, cookie choices, terms, regulated disclosures, retention rules, accessibility commitments, licenses, and contractual uptime or security requirements. Route legal decisions to qualified counsel.

Do not use traffic alone to decide what survives. A low-traffic compliance page may be required. A thank-you page may fire a valuable conversion. A frequently visited article may be outdated and should be consolidated into a stronger guide. Record keep, improve, combine, redirect, archive, or delete for every asset, along with the reason. The website redesign and migration library connects this inventory to audits, redirect mapping, launch checks, and monitoring.

Build one accountable destination map

Every public asset needs a dispositionThe old inventory feeds a reviewed destination map before build and redirect work begin.
01Old assetURL, file, record, function, or tracking event
02DecisionKeep, improve, combine, replace, archive, or retire
03DestinationNew URL, CMS field, system, or documented removal
04AcceptanceOwner, test, evidence, and approval

The destination map should contain old URL, proposed new URL, page purpose, primary audience, content owner, template, canonical target, redirect type, redirect destination, internal-link updates, structured-data type, launch status, and test result. Preserve the same URL when the page purpose remains valid. When a page moves permanently, Google recommends permanent server-side redirects such as 301 or 308. Redirect an old page to its closest useful replacement—not automatically to the home page—and avoid chains through multiple intermediate URLs.

A website design engagement should make the destination map a shared approval record, not a private developer file. Content, SEO, design, engineering, and business owners all rely on it for different reasons. If a platform cannot reproduce a needed function or content relationship, that constraint belongs in the map before the team approves templates.

VISUAL CHECKPOINT · RedesignEvery public asset needs a disposition

The old inventory feeds a reviewed destination map before build and redirect work begin.

Turn requirements into acceptance tests

Weak requirementTestable acceptance statement
FormsContact form worksA mobile submission with all valid field types reaches the CRM, records consent and source, triggers the correct confirmation, and alerts the assigned team
SearchKeep our SEOApproved URLs return 200, retired URLs reach mapped destinations in one permanent redirect, canonicals are self-referential, and the XML sitemap lists only intended canonical URLs
AnalyticsInstall GA4Production traffic reaches the correct property and each agreed event fires once with the required parameters after consent behavior is verified
AccessibilityMake it ADA compliantNamed templates and tasks pass automated checks plus keyboard, focus, zoom, label, error, contrast, and screen-reader review against the agreed standard
OwnershipClient owns the siteThe business controls registrar, DNS, platform, billing, analytics, repository or exports, and named administrator accounts with recovery methods
  • Test global navigation, footer, search, breadcrumbs, filters, pagination, buttons, downloads, and external links.
  • Test representative content records, then test edge cases: longest title, missing image, unusual character, archived item, and empty state.
  • Check page titles, descriptions, headings, canonicals, robots directives, hreflang where used, structured data, status codes, and sitemap membership.
  • Submit every form using valid, invalid, duplicate, and spam-like input; verify storage, routing, notifications, consent, and error recovery.
  • Check phone, tablet, wide screen, keyboard-only use, zoom, focus order, visible labels, reduced-motion preference, and common assistive technology paths.
  • Validate payments, tax, shipping, inventory, account, CRM, scheduling, email, feed, API, and webhook behavior with safe test data.
  • Record who accepts each test and where evidence lives. “Looked good in staging” is not an acceptance record.

Plan DNS, launch, and rollback as one operation

A launch runbook uses exact actions, owners, evidence, and stop conditions.

WindowPrimary actionsEvidence before proceeding
Several days beforeFreeze structural changes, back up systems, lower DNS TTL only if appropriate, approve redirects, verify account accessRestorable backup, exported records, tested build, final map, and owner attendance
Launch windowPublish production build, apply redirects, change only approved DNS records, enable production integrationsCorrect host response, valid certificate, home and critical pages available, forms and transactions working
First hourRun smoke tests from outside team accounts and devicesNo critical errors, one-hop redirects, correct robots and canonicals, live measurement, working lead or order path
First daysCrawl production, review server/platform logs, Search Console, analytics, lead flow, orders, and support reportsIssues triaged by severity with accountable owners
After stabilityRetain required records, remove temporary access, document operations, schedule old-system retirementBusiness owner accepts handoff and recovery process

DNS is not just the website address. Inventory the current zone and preserve records for email and verification, including MX, TXT, SPF, DKIM, DMARC, and service-specific entries as applicable. Determine whether the launch changes a record, nameservers, or registrar; those are different operations. Keep domain ownership and billing under the business. If the site is moving hosts without visible URL changes, Google's hosting-change guidance recommends preparing and testing the new infrastructure, starting the move through DNS, and monitoring both old and new hosting.

Monitor the move until the business is stable

Watch the signals that match the migration: crawl errors and indexing for URL changes; response time and error rate for hosting; form delivery and lead quality for a marketing site; checkout, payment, feed, inventory, and customer-service contacts for commerce. Compare like-for-like periods but account for campaigns, seasonality, consent changes, and tracking changes. A short-term search fluctuation is not proof that a migration failed, and a flat traffic chart is not proof that forms or operations work. The companion guide on redesigning without losing SEO explains how to protect search signals without promising unchanged rankings.

  1. Review critical paths immediately after launch and again after caches, DNS, and integrations have settled.
  2. Crawl the public site and compare it with the approved destination map; investigate unplanned 404s, redirect chains, blocked pages, duplicate canonicals, and missing assets.
  3. Check lead or transaction records in the destination system, not only the browser confirmation screen.
  4. Review Search Console indexing, sitemap processing, and performance over time; use URL Inspection for representative critical pages rather than submitting every URL manually.
  5. Keep a decision log for defects, deferred work, and intentional differences so later teams do not “fix” approved behavior.
  6. Retire the old platform only after the business owner, technical owner, and measurement owner accept stability and required records are retained.
How long should a website migration plan take?

It depends on the number of URLs, content types, integrations, stakeholders, and regulated processes—not just page count. A small brochure site may need weeks; a multilingual, integrated, or commerce site may need months. Estimate inventory, decisions, production, testing, launch, and monitoring separately.

Should every old URL redirect during a migration?

Every old URL needs a recorded decision, but not every URL deserves a redirect. Permanently moved content should reach its closest useful replacement. Content with no replacement may return 404 or 410. Avoid sending unrelated retired pages to the home page.

Can we launch before all content is ready?

Only if the incomplete content is deliberately excluded and the live site still meets business, legal, accessibility, search, and user requirements. Placeholder pages, broken journeys, and unreviewed migrations create avoidable risk. Define the minimum launch set and the later release plan.

Who should own the migration plan?

One accountable migration lead should maintain the plan, but specialists must accept their areas. The business owner approves scope and launch; content, design, technical, IT, analytics, legal, and operational owners approve named requirements and tests.