To migrate WordPress without visible downtime, build and test the site on the destination server before changing DNS, reduce DNS cache time in advance, synchronize recent data during a short controlled cutover, and keep the old server online while the change propagates. The key is separating preparation from the final switch.

Plan the Migration

Inventory the current site: WordPress and PHP versions, database size, uploads, custom server rules, cron jobs, email delivery, SSL, redirects, CDN, DNS, third-party integrations, and traffic patterns. Confirm that the new host supports every requirement and has enough storage and memory.

For a brochure site, the database may barely change. For WooCommerce, membership, LMS, forum, or booking sites, orders and user activity can occur every minute. Those sites need a defined content freeze, maintenance window, or real-time database replication strategy.

Lower DNS TTL Before the Move

Reduce the time-to-live on records that will change, ideally 24–48 hours before cutover. A shorter TTL encourages resolvers to refresh sooner, although it cannot guarantee instant propagation. Record the original values so they can be restored once the migration is stable.

Copy the Site to the New Server

1. Create a complete backup of the source files and database.
2. Provision WordPress’s destination environment, PHP extensions, database, TLS, caching, and server rules.
3. Transfer files with a tool that can resume and compare data.
4. Export and import the database without changing serialized values manually.
5. Update database credentials and environment-specific configuration.
6. Run a safe search-replace only if the domain or protocol changes.

A host migration that keeps the same public domain usually does not require changing WordPress URLs. Avoid global SQL replacements because serialized plugin data can be corrupted.

Test Before DNS Cutover

Preview the destination using a temporary URL only when it will not rewrite stored URLs. A local hosts-file entry is often safer because your browser requests the real domain from the new IP. Ensure the new server presents a valid certificate for the domain.

• Compare important pages, media, menus, redirects, and status codes.
• Log in and edit content.
• Submit forms and confirm outgoing mail.
• Test search, scheduled tasks, API calls, and webhooks.
• Complete a sandbox purchase and verify account pages on stores.
• Check logs, responsive layouts, and performance.
• Prevent the preview copy from sending duplicate emails or being indexed.

Synchronize Changes and Switch Traffic

At cutover, pause content edits or enable a brief read-only/maintenance state for transactional sites. Perform a final database export and synchronize changed uploads. Import the final data, clear destination caches, run a short smoke test, then update the authoritative DNS record or load balancer.

Keep both servers available. Requests may reach either location during propagation, so avoid accepting new transactions on two independent databases. If necessary, make the old site read-only or proxy its traffic to the destination.

Post-Migration Checks

• Verify DNS from multiple networks and regions.
• Confirm HTTPS, canonical URLs, robots rules, and XML sitemaps.
• Check forms, email authentication, payments, webhooks, and scheduled actions.
• Watch 404, PHP, firewall, and application logs.
• Compare analytics and performance with the old host.
• Restore normal DNS TTL after the migration is stable.

Do not cancel the old hosting account immediately. Retain it for an agreed rollback window, then take a final archive before decommissioning it.

Migration FAQ

Will changing hosts hurt SEO?

A clean migration that preserves URLs, content, status codes, canonical tags, and availability should not inherently harm SEO. Problems usually come from downtime, blocked crawling, lost redirects, slow performance, or accidental URL changes.

How long does DNS propagation take?

Many visitors switch quickly after a low-TTL change, but cached resolvers can take longer. Plan for overlap rather than assuming one universal propagation time.