A domain migration touches far more than the website. Email delivery, identity providers, APIs, certificates, mobile apps, documentation, analytics, advertising, customer bookmarks, vendor allowlists, software updates, and security monitoring may all depend on the old domain. The safest migration is a staged program with inventory, owners, validation, and rollback—not a late-night DNS edit.
The runbook below assumes the organization is moving from an old primary domain to a new one. Some steps also apply to registrar transfers or DNS-provider changes, but those events should be separated when possible. Changing registrar, authoritative DNS, web hosting, email, and public URLs in one window creates too many failure paths to diagnose quickly.
Define scope and success criteria
State exactly what is changing: public website URLs, corporate email, employee identities, customer login domains, API hosts, or only brand-facing pages. A website move can occur while email remains on the old domain. An organizational rebrand may require both. Splitting phases reduces risk when business constraints allow it.
Define measurable success: old URLs redirect to matching new URLs, critical pages return expected status codes, mail is accepted and authenticated, applications complete sign-in, certificates are valid, analytics preserve attribution, and customer support can identify migration issues. Establish acceptable error rates and rollback triggers.
Name an incident commander, technical owners, communications lead, and approvers. Publish a change calendar that avoids product launches, major campaigns, billing deadlines, and periods with limited staffing.
Build a complete dependency inventory
Crawl the current site and export all indexable URLs, redirects, canonicals, sitemaps, structured data, hreflang, media, scripts, and forms. List subdomains, DNS records, mail exchangers, TXT records, certificates, CDN hostnames, APIs, webhooks, authentication callbacks, storage endpoints, status pages, and vendor integrations.
Search source code, infrastructure configuration, secrets stores, documentation, mobile apps, desktop software, analytics tags, advertising accounts, and support macros for the old domain. Ask vendors and business teams where they have allowlisted it. Hidden dependencies often live outside the web team.
Record an owner and migration action for every dependency: change, duplicate, redirect, preserve, deprecate, or investigate. No item should remain “someone probably handles this.” Use the inventory as the change checklist and final evidence record.
Prepare the new domain securely
Place the new domain in the correct organizational registrar account. Enable strong multifactor authentication, renewal controls, locks, role-based contacts, and monitoring. Configure authoritative DNS and validate it before public cutover. If DNSSEC will be used, plan the chain carefully and avoid combining an unfamiliar signing change with the main launch.
Issue certificates for every new hostname and test renewal automation. Configure web application security policies, monitoring, rate limits, logging, and backups. A migration should not lower the baseline because the new environment was assembled quickly.
Establish a temporary test method that does not expose an unfinished site to indexing or customers. Use controlled hosts files, authenticated preview environments, or provider-supported staging. Test with production-like data and integrations where safe.
Design one-to-one URL mappings
Map every valuable old URL to the most relevant new URL. Preserve paths when the information architecture is unchanged. When content is consolidated, redirect to the closest equivalent—not the homepage by default. Remove or return an appropriate gone response for content that truly has no replacement.
Update internal links, canonical tags, structured data, hreflang, Open Graph metadata, feeds, XML sitemaps, and navigation to use the new URLs directly. Redirect chains waste time and complicate diagnosis, so old URLs should reach the final destination in one hop whenever possible.
Google’s site-move documentation recommends changing one major element at a time when practical, preparing URL mappings, using server-side permanent redirects, and monitoring the move. Treat search migration as a technical communication of continuity, not a request to preserve every ranking automatically.
Prepare DNS and web cutover
Review TTL values well before the change. Lowering TTL can shorten cache persistence for selected records, but it is not a substitute for correct configuration and should not be left unnecessarily low forever. Confirm the old and new authoritative zones contain every required record.
Deploy the new site before changing public traffic. Run automated checks for status codes, content, headers, canonicals, robots directives, structured data, images, and performance. Test from multiple networks and device types. Confirm the new site does not accidentally block crawling or expose staging directives.
At cutover, apply redirects at the earliest reliable layer, update DNS if hosting changes, and monitor authoritative answers. Keep the old hosting available to serve redirects. Do not cancel the old platform immediately after the first successful test.
Migrate email as a separate critical system
Decide whether addresses will change and whether both domains will receive mail during transition. Configure the new domain in the mail platform, verify ownership, create users and aliases, and test inbound and outbound delivery before announcing the change. Preserve old addresses as aliases long enough for customers and vendors to update.
Publish and validate SPF, DKIM, and DMARC for the new domain. Start with a policy appropriate to observed traffic and the organization’s authentication maturity. Update third-party senders deliberately; an unknown marketing or ticketing platform can cause authentication failures after cutover.
Test replies, forwarding, mailing lists, calendar invitations, automated notifications, support systems, and bounce handling. Monitor authentication reports and delivery logs. Protect the old domain from abuse after employees stop sending from it; retirement without email policy creates an impersonation opportunity.
Update identity and application integrations
Inventory OAuth redirect URIs, SAML entity identifiers, single-sign-on domains, SCIM endpoints, cookie scopes, CORS policies, API allowlists, webhook targets, mobile deep links, package registries, and customer integrations. Some identity values cannot be changed without vendor support or a staged coexistence period.
Test account recovery and email verification on the new domain. A user may be unable to sign in if the application changes the visible domain but an identity provider still expects the old callback. Preserve logs that let teams distinguish DNS, TLS, identity, and application errors.
Coordinate with customers who embed endpoints or allowlist domains. Give clear dates, exact values, test environments, and a contact route. Avoid asking every customer to make an emergency change on launch day.
Communicate without creating phishing opportunities
Announce the migration through existing trusted channels before the switch. Show the old and new domains in plain text, explain what changes and what does not, and tell users how to verify messages. Avoid surprise emails that ask recipients to sign in through a brand-new address.
Publish an official migration notice on the old domain and keep it available. Train support teams with screenshots, known issues, and escalation paths. Update invoices, contracts, signatures, social profiles, app-store listings, documentation, and partner directories in a coordinated sequence.
Monitor lookalike registrations and phishing that exploit the change. Attackers benefit when users expect unfamiliar domains. Strong authentication, consistent links, and rapid public clarification reduce the window.
Launch with active validation and rollback criteria
Use a command center with a single issue log. Monitor DNS answers, TLS, web availability, redirect coverage, crawl errors, server logs, email delivery, authentication, transaction completion, support volume, and security alerts. Compare against pre-launch baselines.
Run synthetic journeys from landing page to sign-in, purchase, support, and email confirmation. Test old URLs and addresses. Sample important pages rather than relying only on the homepage. Verify that redirects preserve query parameters where required and do not create loops.
Rollback should be specific. Know which DNS records, routing rules, or feature flags can restore the previous path and which changes are irreversible. A rollback is safer when the old systems remain operational and data writes have been planned for coexistence.
Support search discovery after the move
Submit updated sitemaps through relevant search tools and keep the old sitemaps accessible if useful for discovery of redirects. Update important external links you control, including profiles, documentation, and partner pages. Do not attempt to change every backlink before launch.
Monitor indexing, crawl activity, canonical selection, redirect errors, and traffic by page group. Expect fluctuation and investigate patterns rather than reacting to one day of data. A sudden loss isolated to one directory may indicate a mapping or robots problem.
Keep permanent redirects for as long as the old URLs remain in use and ideally indefinitely for durable content. Domain ownership must be maintained as long as users, links, email, or software may depend on it. Letting the old domain expire can convert a migration into a security incident.
Perform post-launch cleanup deliberately
After stability, raise TTL values to normal operating levels, remove temporary access, rotate migration credentials, confirm renewal and lock states, and archive configuration snapshots. Update disaster-recovery documentation and monitoring inventories.
Review redirect logs to find unmapped URLs and unexpected clients. Update internal links that still depend on redirects. Continue email alias and old-domain monitoring according to the transition plan, not an arbitrary short deadline.
Hold a retrospective covering outages, support themes, overlooked dependencies, search changes, phishing attempts, and vendor coordination. Convert findings into reusable checklists for future acquisitions, product domains, or infrastructure moves.
Treat migration as continuity engineering
A successful domain move preserves user intent across technical systems. It requires accurate mapping, secure ownership, tested DNS, authenticated email, compatible identity integrations, clear communication, and patient monitoring. Search visibility is one part of a larger trust transition.
Use the domain security baseline before preparing the new name, the DNSSEC guide for signed-zone changes, and the acquisition checklist when the destination domain is purchased. The migration is complete when old pathways reliably reach the new identity and the organization can operate both the transition and the eventual retirement safely.