A hosting migration can be nearly invisible to visitors when it is treated as a controlled deployment rather than a last-minute file copy. The difficult parts are usually dynamic data, email, DNS timing, SSL and rollback—not downloading a ZIP file.

This website migration checklist provides a low-risk sequence for WordPress, cPanel and many other common hosting setups. “Zero downtime” cannot be guaranteed in every architecture, but careful preparation can make disruption negligible.

1. Inventory the current website

Record the domain, subdomains, DNS records, document roots, database names, PHP and database versions, scheduled jobs, redirects, SSL certificates, mailboxes and third-party integrations. Note disk usage and peak traffic. Save current DNS records separately.

Check whether the new host supports every required PHP extension, runtime version and database feature. SiteChai offers web hosting and specialist WordPress hosting; for a complicated migration, discuss requirements before changing DNS.

2. Create a tested backup

Back up website files, databases and relevant configuration. If email is hosted on the same server, back up mailboxes too. WordPress’s official migration guidance specifically recommends backing up both files and the database before moving.

A backup is useful only if it can be restored. Verify archive integrity and, where feasible, test restoration in a separate environment. Follow the 3-2-1 backup strategy so the only recovery copy is not stored on the server being replaced.

3. Lower DNS TTL in advance

TTL tells DNS resolvers how long they may cache a record. Cloudflare recommends lowering critical DNS TTLs to about 300 seconds at least 24–48 hours before a migration. cPanel’s migration guide also recommends a 300-second TTL. Change it early enough for the previous, longer TTL to expire.

Do not change nameservers and all DNS records casually at the same time. Decide whether DNS will remain with the current provider or move separately. Review our guide to A, CNAME, MX and TXT records if the record types are unfamiliar.

4. Build and test the destination

  1. Create the hosting account, database, users and mailboxes.
  2. Transfer files while preserving permissions.
  3. Export and import the database using a method suitable for its size.
  4. Update configuration values and secrets securely.
  5. Install a valid SSL certificate.
  6. Recreate cron jobs, redirects and security rules.

Test without changing public DNS by using a temporary URL, staging hostname or local hosts-file entry. Verify pages, forms, login, search, checkout, uploads, API calls, scheduled jobs and admin functions. Check browser developer tools and server logs for errors.

5. Plan dynamic-data synchronization

Blogs with no comments may tolerate a simple final database copy. Stores, booking sites and communities cannot risk orders or user changes being written to the old server during cutover.

Choose one approach:

  • Schedule a short maintenance or read-only window for the final database sync.
  • Use replication or an application-specific migration tool.
  • Temporarily route writes to one authoritative database.
  • Use a platform transfer feature designed to proxy traffic during DNS change.

cPanel’s Transfer Tool documents a Live Transfer option that can reduce interruption by updating records and redirecting supported traffic while DNS changes propagate. Availability depends on server access and configuration.

6. Cut over in a quiet period

  1. Enable maintenance or read-only mode if needed.
  2. Take the final database and upload delta.
  3. Verify the destination again.
  4. Change only the required A/AAAA or nameserver records.
  5. Keep the old server online.
  6. Monitor traffic and errors on both systems.

7. Verify the migration

Area Checks
DNS Root, www, subdomains, MX, SPF, DKIM, DMARC and verification records
Website HTTP/HTTPS, redirects, canonical URLs, forms, logins, uploads and caching
Email Inbound, outbound, webmail, forwarding and spam controls
SEO Status codes, robots.txt, sitemap, analytics and Search Console verification
Performance Server errors, response time, database load and cache behaviour

If URLs remain unchanged, a hosting move should not require mass redirects. Avoid changing the domain, URL structure and host in one event unless necessary. Maintain the same canonicals and review the factors in our guide to website speed and SEO.

8. Keep a rollback window

Do not cancel the old host immediately. Keep it available for several days, or longer for a business-critical service, while traffic and logs confirm that the cutover is stable. Document the point at which a rollback is safe and the point after which new data makes rollback complicated.

9. Restore normal TTL and clean up

After DNS is stable, raise TTL to a sensible normal value. Revoke temporary credentials, remove staging files, update backup jobs, confirm off-site backups and only then decommission the old account.

Frequently asked questions

How long does DNS propagation take?

It depends on previous TTLs, resolver behaviour and whether nameservers changed. Lowering TTL early helps but does not control every cache.

Will changing hosts hurt SEO?

Not inherently. Problems usually come from downtime, slow responses, missing pages, changed URLs, robots directives or lost redirects.

Can I migrate WordPress with a plugin?

Often, yes. Check site and archive size, PHP limits, multisite support and whether the plugin handles serialized data and final synchronization.

When should I hire help?

Use experienced support for stores, large databases, custom applications, complex email, multisite networks or any move without a tested rollback. SiteChai offers appointment booking for discussing requirements.

Final checklist

Inventory, back up, lower TTL early, test the new environment, control writes, cut over, verify, monitor and retain a rollback path. That sequence is what turns a risky move into a manageable deployment.