Jump to a section +
Changing hosting can mean moving server files, a database, a managed platform project, a CDN origin, a serverless deployment, or several of those. The domain may stay with the same registrar and the user-visible URLs may remain identical. That is fundamentally different from changing the domain, protocol, subdomain, or path structure, even when both projects happen at once.
Google maintains separate guidance for changing hosting without visible URL changes and for site moves that change URLs. Keep the projects separate when possible. Preserving URLs removes the need for a redirect map between old and new addresses, but it does not eliminate risks from different content, status codes, rendering, robots rules, canonicals, performance, or availability.
Define the migration boundary
Name what changes and what must remain stable before selecting a procedure.
| Layer | May change | Should be explicitly decided |
|---|---|---|
| Registrar and domain registration | Often stays unchanged | Registrant account, renewal, locks, recovery contacts, and whether any transfer is truly required |
| Authoritative DNS | May stay or move to another DNS provider | Nameservers, full zone, DNSSEC if used, API dependencies, TTLs, and rollback |
| Website destination | A, AAAA, CNAME, ALIAS or provider-specific routing changes | Apex and www behavior, IPv4 and IPv6, CDN or proxy, origin, health, and certificate |
| Hosting runtime | Operating system, language, database, build, storage, jobs, and limits | Version parity, supported differences, secrets, writable storage, scheduled work, and scaling |
| Public URLs | Preferably unchanged for a host-only move | Protocol, hostname, paths, query behavior, trailing slash, case, redirects, canonicals, and sitemap |
| Email and verification | Should usually remain unchanged | MX, SPF, DKIM, DMARC, mail hostnames, provider verification, and recovery email |
| Business integrations | Endpoints or allowlists may need updates | Forms, CRM, payments, booking, webhooks, APIs, analytics, ads, consent, and monitoring |
| Content operations | Editing or transactions may continue during the copy | Freeze, incremental sync, queue, reconciliation, and authoritative data source |
The website migration planning guide covers broader redesign and platform moves. This guide focuses on infrastructure where visitors should request the same URL and receive equivalent content and function from a new environment.
Inventory the current production system
Create the source-of-truth migration record
Crawl and sample public URLs
Record status codes, redirects, canonical tags, robots directives, structured data, metadata, content, media, language annotations, sitemaps, and representative performance before the move. Include valuable and obscure templates.
Document runtime and configuration
Capture software versions, packages, server modules, environment variables, secrets references, file permissions, database settings, build and deploy commands, cache, CDN, compression, headers, logs, and scheduled jobs.
Map writable and changing data
Identify CMS edits, uploads, form data, users, sessions, orders, bookings, inventory, queues, generated files, and third-party systems. Decide which system is authoritative during cutover.
Export DNS and account context
Record registrar, authoritative nameservers, full zone, TTLs, DNSSEC state if applicable, certificate process, owner accounts, support contacts, and billing. A screenshot can supplement but should not replace a usable zone record.
Verify backup and restore
Create a relevant recovery point and verify that code, database, media, configuration, and dependencies can restore. The old host is not the only backup and a downloaded zip is not automatically complete.
Set monitoring and acceptance
Define availability, response, error, certificate, content, transaction, and search checks; name who decides go, hold, rollback, and retirement.
Build and test the new environment privately
Prepare DNS, TLS, and email
DNS resolvers cache answers according to TTL and their behavior. Lowering the relevant record TTL ahead of cutover can reduce how long compliant caches retain the old answer after a later change, but it does not force every client to refresh instantly or fix local, application, proxy, or CDN caches. Record the original TTL and restore an appropriate value after the migration is stable.
Prepare the routing change
Identify authoritative control
Confirm the registrar, nameservers, DNS provider, business owner, MFA, support path, DNSSEC state, API users, and complete zone before changing a record.
Lower only relevant TTLs in advance
Follow the DNS provider’s guidance and allow the previous TTL period to pass before cutover when practical. Do not change nameservers merely to edit an A or CNAME record.
Provision secure hostnames
Prepare valid HTTPS for the apex, www, and required subdomains through the supported host or certificate process. Test hostname coverage, redirects, chain, renewal, and proxy behavior.
Preserve the email zone
Do not omit MX, SPF, DKIM, DMARC, verification, and mail-related hostnames from a DNS migration. Have the email administrator validate current records and delivery.
Prepare exact new answers and rollback
Record the old and new record values, proxy state, health expectations, operator, timestamp, approval, and the condition for reverting. Validate both IPv4 and IPv6 paths if published.
The domain and DNS redesign guide explains the account and record boundaries in more detail. A host move usually needs only website-routing changes; a nameserver change replaces authority for the whole zone and carries a broader error surface.
Changing content, templates, URLs, platform, analytics, and hosting at once creates more ways to fail and makes diagnosis harder. If combining work is necessary, document each change set, dependency, validation, and rollback boundary separately.
Plan the final data synchronization
Choose a cutover strategy from how the site changes, not from a promise of zero downtime.
| Site behavior | Possible strategy | Risk to reconcile |
|---|---|---|
| Static generated site | Build and deploy the same release to the new host, then switch routing | Environment variables, forms, cache, headers, redirects, and deploy source can still differ |
| CMS with infrequent edits | Announce a short content freeze, take a final export, restore, validate, and switch | An editor publishing during the freeze can create divergence |
| Database-driven site | Initial copy followed by a supported incremental or final synchronization during a controlled write window | Sequences, uploads, sessions, jobs, and writes to both systems require a consistent authority |
| Commerce, membership, or booking | Use platform-supported migration, maintenance, replication, or reconciliation designed for transactional state | Orders, inventory, payment, users, appointments, messages, and webhooks cannot be merged casually |
| External system of record | Move the presentation and reconnect to the same approved API or SaaS where supported | Credentials, IP allowlists, callback URLs, rate limits, consent, and vendor environments may change |
Rollback is simple only when the old and new systems are read-only and equivalent. After customers write to the new database, pointing traffic back can hide or lose new records. Define whether rollback includes reverse synchronization, temporary read-only operation, manual reconciliation, or a forward fix. Give one coordinator authority to choose.
Switch traffic in a controlled window
Cutover runbook
Confirm go or hold
Review backup, new-host health, final sync, TLS, DNS access, email preservation, acceptance tests, monitoring, support availability, rollback, and stakeholder readiness.
Freeze or synchronize changes
Apply the documented content and transaction plan, capture timestamps and counts, stop duplicate jobs where needed, and establish which environment accepts new writes.
Change the minimum routing
Update the approved website DNS or provider route. Avoid unrelated cleanup during cutover and record exact before-and-after values.
Observe both destinations
Because caches expire over time, traffic may reach old and new hosts during overlap. Keep compatible content and operations or use an architecture that accounts for mixed arrival.
Run live validation
Check DNS from multiple resolvers, TLS, representative URLs, status and redirects, forms, integrations, jobs, logs, performance, mobile, accessibility, analytics, and business receipt.
Communicate facts
Report current status, known limits, customer impact, next checkpoint, and owner. Do not declare propagation complete from one laptop or promise no user encountered an old cache.
- The apex, www, active subdomains, HTTP and HTTPS, IPv4 and IPv6 where published, and legacy routes reach the intended behavior.
- Important pages return the expected status, content, canonical, robots directive, structured data, metadata, internal links, and language annotations.
- Forms, authentication, booking, payment test route, email, CRM, webhooks, APIs, uploads, downloads, and staff notifications function once and accurately.
- Server, application, database, CDN, and browser errors are monitored, with resource use, latency, and failed jobs visible to an owner.
- XML sitemaps and robots.txt are accessible and correct; Google Search Console ownership and reporting remain available.
- The old environment remains protected, patched, monitored, and recoverable during the agreed overlap rather than abandoned while still receiving traffic.
Protect search signals after the host move
For a host-only move, serve substantially the same content at the same URLs and keep crawl access stable. Compare pre- and post-migration crawls for status codes, redirects, canonicals, robots, sitemaps, rendered content, structured data, internal links, and response. Google recommends lowering DNS TTL, copying and testing the site, updating DNS, monitoring traffic, and shutting down old hosting only after traffic has moved. Follow its current guidance for the site’s situation.
Monitor before retiring the old host
Retirement is an evidence-based checkpoint, not the moment the new homepage first loads.
| Monitor | Look for | Retirement decision |
|---|---|---|
| Old-host traffic | Requests from caches, bots, hard-coded integrations, or unswitched records | Identify legitimate remaining traffic and update dependencies before shutdown |
| New-host errors | 5xx, 4xx changes, application exceptions, database errors, job failures, timeouts, and resource pressure | Stabilize and establish normal baselines with alert ownership |
| Customer paths | Lead, booking, payment, login, upload, download, email, and support failures | Confirm accepted transactions and staff handling, not only click events |
| Search | Crawl errors, robots changes, canonical differences, sitemap processing, rendered content, and traffic anomalies | Investigate material differences before treating the move as complete |
| Security and access | Unexpected accounts, exposed staging, secret use, certificate renewal, missing logs, and backup failures | Remove temporary access and verify operational controls |
| Data consistency | Record counts, media, late writes, queues, orders, bookings, and reconciliations | Resolve or document every known divergence and retain required evidence |
Close the project responsibly
Return DNS TTLs deliberately
After stability, set values appropriate to ongoing operations and document the change. Do not leave unusually low TTLs indefinitely without a reason.
Take a new recovery point
Back up the stable new environment, test the recovery path, and update the disaster-recovery inventory, support contacts, and runbook.
Remove temporary exposure
Revoke migration credentials, tokens, allowlists, test users, staging access, old integrations, and provider accounts that are no longer required.
Archive before canceling
Retain approved exports, logs, invoices, configurations, and evidence according to policy. Understand provider deletion timing and license terms.
Cancel the old host in writing
Only after the overlap and acceptance criteria are satisfied, end billing and services through the official process and save confirmation. Keep domain and email services that were never meant to move.
Web Respawn’s website care plans can help define monitoring, update, backup, and support ownership around a hosting move. The platforms, hosting, and ownership library covers hosting decisions, domain control, security, continuity, and provider handoff.
Before comparing replacement providers, use the small-business hosting guide to separate a host’s infrastructure responsibilities from website maintenance, application support, email, DNS, and business continuity.
Can I change website hosts with zero downtime?
Careful preparation, overlap, low relevant TTLs, compatible old and new environments, health checks, and controlled routing can reduce interruption, but zero downtime cannot be guaranteed across providers, caches, networks, applications, certificates, DNS, integrations, and human actions. Define acceptable impact and rollback.
Will changing hosts hurt my Google rankings?
A host-only move that preserves URLs, content, crawlability, rendering, status codes, canonicals, performance, and availability is designed to minimize search disruption, but rankings cannot be guaranteed. Monitor Google Search Console, crawls, logs, and traffic for differences and correct them promptly.
How long does DNS propagation take after a host change?
There is no single global completion time. Recursive resolvers and clients cache answers according to TTL and their behavior, while local, application, proxy, and CDN caches may differ. Lower relevant TTLs in advance when appropriate, keep both hosts ready during overlap, and observe multiple paths.
Should I transfer my domain when I change hosting?
Usually a hosting move does not require a registrar transfer. Keeping registration stable can reduce simultaneous risk. Change only the website routing records or provider connection needed for the new host, unless there is a separate, planned reason to move the domain or DNS service.
Evidence behind the guide
Sources and further reading
- Changing Your Web Hosting and SEOGoogle Search Central
- Site Moves and MigrationsGoogle Search Central
- Redirects and Google SearchGoogle Search Central
- DNS record time to liveCloudflare Developers
Continue on Web Respawn
Pages that actually connect to this decision.
These links are selected for the subject of this guide. They are not a generic service dump.
