How to Migrate a WordPress Website to a New Host Without Downtime

Moving a WordPress website is more than copying files and importing a database. A safe migration must preserve availability, HTTPS, email delivery, search visibility and application data while traffic shifts from the old server to the new one. In practice, “without downtime” means preparing both environments so visitors can reach a working website throughout DNS propagation.

This checklist is suitable for business websites, WooCommerce stores, multilingual platforms and content-heavy WordPress installations. For a demanding project, begin by confirming that the target server has adequate storage, memory, PHP support and backup capabilities. Compare these requirements when reviewing WordPress hosting packages.

1. Audit the existing WordPress environment

Document the current setup before changing anything. Record the WordPress and PHP versions, active theme, plugins, scheduled tasks, database size, storage use, DNS zone, SSL configuration and email services. Identify integrations such as payment gateways, analytics, CDNs, webhooks, external APIs and SMTP providers.

• Check for outdated or incompatible plugins.
• List custom server rules from .htaccess, Nginx or the hosting panel.
• Note PHP limits, extensions and background jobs.
• Export the current DNS zone and take screenshots of important settings.
• Identify dynamic data that may change during migration, including orders, form submissions and user accounts.

Choose a low-traffic migration window, but do not assume low traffic means no traffic. WooCommerce and membership websites may require a brief maintenance or read-only period for the final database synchronization.

2. Prepare backups and a rollback plan

Create independent backups of the WordPress files and database. Do not rely solely on a migration plugin or a backup stored on the source server. Download or copy the backups to separate storage, verify their size and test that the database archive can be opened.

Keep the old hosting account active throughout the DNS transition. Your rollback plan should specify who can restore the previous DNS records, where the verified backup is stored and how new transactions will be reconciled if the cutover must be reversed.

3. Lower the DNS TTL before migration

DNS Time to Live determines how long resolvers may cache a record. Lower the TTL for the website’s A and AAAA records—typically well before the planned switch—so that later changes can be detected sooner. The exact timing depends on the existing TTL because cached records remain valid until they expire.

Do not alter MX, SPF, DKIM or DMARC records merely because the website is moving. Website hosting and email hosting are often separate services. Preserve every required mail record unless email is being migrated as a distinct project.

4. Build and test the website on the new host

Copy WordPress core files, uploads, themes and plugins to the destination. Export the database from the source, import it on the new server and update wp-config.php with the new database credentials. Keep the production domain unchanged inside WordPress unless the domain itself is changing.

Test the destination before public DNS is switched. The most reliable method is a local hosts-file override that maps the domain to the new server’s IP address. This allows the browser to request the real domain while only your device reaches the destination server.

What to test

• Home page, key landing pages, posts, archives and search.
• Administrator login, media uploads and plugin operations.
• Forms, transactional email and SMTP authentication.
• Checkout, customer accounts, taxes and payment callbacks.
• Redirects, canonical URLs, robots directives and XML sitemaps.
• Responsive layouts, caching, security headers and server logs.

If the move includes containers, managed infrastructure or a broader architecture change, a planned cloud migration can coordinate application, database, storage and network dependencies.

5. Install and validate SSL before the cutover

The destination must serve a valid certificate for every public hostname, including the root domain and www variant where used. Depending on the provider, you can issue the certificate through DNS validation, temporarily proxy validation traffic or install an existing certificate if its terms permit transfer.

Confirm that HTTPS loads correctly through the hosts-file test. Check the certificate chain, expiry, hostname coverage and HTTP-to-HTTPS redirect. Search for mixed-content requests caused by hard-coded HTTP asset URLs. Avoid enabling HSTS for the first time during migration; a configuration error becomes harder to recover from once browsers cache that policy.

6. Synchronize dynamic data and switch DNS

Immediately before cutover, place highly dynamic sites into a controlled maintenance or read-only state. Perform a final database export and import, synchronize recently uploaded files, clear caches and confirm that background jobs are not running on both servers.

Update the relevant A and AAAA records to the new server. If the provider requires nameserver changes, compare the new DNS zone carefully before switching; missing records can disrupt email, verification services and subdomains. Changing only the required website records is generally easier to control.

During propagation, requests may reach either server. Keep both installations operational and avoid publishing content independently on each copy. Monitor access logs, application errors, uptime, forms, orders and resource use.

7. Protect email delivery

A website migration can affect email even when mailboxes stay with the same provider. DNS zones may be recreated incorrectly, and website forms may begin sending from a new IP address.

Email checklist

• Preserve all MX records and their priorities.
• Copy the complete SPF TXT record; do not publish multiple SPF records for one hostname.
• Retain DKIM selectors and public keys.
• Keep the DMARC policy and reporting addresses.
• Verify autodiscovery, webmail and mail-related CNAME records.
• Authorize the new sending service or configure authenticated SMTP.
• Test messages to and from external providers and inspect authentication results.

Do not use PHP mail as the only delivery strategy for important notifications. Authenticated SMTP or a transactional email provider usually offers clearer logs and more consistent identity alignment.

8. Complete post-migration checks

After traffic has moved, scan the website for broken links, missing images, redirect loops and server errors. Review Search Console or equivalent webmaster tools, analytics collection, caching, scheduled tasks, backup jobs and security monitoring. Confirm that the site URL, canonical tags and sitemap still use the preferred HTTPS hostname.

Keep the source hosting intact until DNS caches have expired and the destination has operated reliably through a normal business cycle. Then take a final archive, revoke obsolete credentials and securely close the old environment.

Practical conclusion

A low-risk WordPress migration depends on sequencing: audit, back up, lower DNS TTL, stage and test, prepare SSL, synchronize data, switch only the necessary DNS records, preserve email settings and monitor both servers. The checklist should be adapted for stores, memberships and websites with frequent updates. If you need an engineer to assess dependencies or manage the cutover, contact developer.ma before changing production DNS.