A hosting change has a reputation as a risky weekend job: point the domain at a new server, wait, and hope the site comes back. Downtime during a migration almost always traces to two things, DNS records that other computers are still caching, and parts of the setup that never travel with a site backup, like mailboxes and cron jobs. Work through the steps below in order and visitors won’t see the switch happen.
Start the day before: lower the DNS TTL
Every DNS record carries a time to live (TTL), the number of seconds other computers may cache it before asking again. Registrars often default the A record to 3600 or 86400 seconds, so a switch can take up to a day to reach everyone while resolvers keep handing out the old IP. Resolvers in the Domain Name System honor that field strictly, so the fix is cheap: a day before migrating, edit the site’s A record and set its TTL to 300. A five-minute TTL means most of the internet catches up within five minutes of the switch.
Take a full backup before anything moves
Two piles again: the files (theme, plugins, uploads) and the database (posts, pages, users, settings). Grab both, a compressed copy of the web directory plus a fresh database dump, and download them somewhere off the server. This archive is the undo button for the entire job, and it’s what turns a bad migration into a boring one.
Copy the site to the new host
Upload the files with rsync, SFTP, or the new host’s file manager, then create a new database and database user in the new host’s control panel and import the dump. WordPress sites have one extra step: wp-config.php still holds the old database name, user, password, and host, so update those four lines or every visitor gets “Error establishing a database connection”. Match the PHP version the old host ran before testing, since a jump from 7.4 to 8.3 can break older plugins.
Test before the switch
The cleanest test keeps the real domain. On the machine you browse from, add a line to the hosts file mapping the domain to the new server’s IP (macOS and Linux: /etc/hosts, Windows: C:\Windows\System32\drivers\etc\hosts), flush the local DNS cache, and open the site. Your browser now asks the new server while everyone else still reaches the old one, and WordPress behaves normally because the domain it sees hasn’t changed.
Testing on a staging URL works too, with one wrinkle: WordPress stores absolute URLs in the database. A plain find-and-replace in SQL can corrupt serialized values in widgets and settings, so use All-in-One WP Migration, which rewrites URLs safely on import, or WP-CLI’s `wp search-replace`, which understands serialization. Either way, click through the home page, one post, one image upload, the contact form, and the login screen before going live.
Switch DNS and leave the old host running
Point the A record at the new server’s IP, and the AAAA record too if the site uses IPv6. With the TTL at 300, most resolvers hand out the new address within five minutes. Keep the old hosting account active for two or three days after the switch, so anyone holding a stale cache still lands on a working site while the old address drains away.
What usually breaks
Email is the classic one. If the domain’s MX records point at the old host’s mail server, cancelling that account takes every mailbox with it. Move the mailboxes first or repoint the MX records to the new provider (Google Workspace, Microsoft 365, the new host) before the old plan expires, and check whether contact forms send through the server’s own mail function, since that moves with the site.
Cron jobs don’t ride along with files and databases. Scheduled tasks configured on the old server, backup scripts or a real WP-Cron replacement among them, need recreating on the new one. A quick check after the switch: run `wp cron event run –due-now` and see what’s overdue.
SSL certificates are issued per server, and a Let’s Encrypt certificate from the old host won’t be waiting on the new one. Issue a fresh certificate there (certbot, or the panel’s one-click SSL) as soon as the domain points over. Miss this step and visitors meet a full-page browser warning until it’s fixed.
Raise the TTL again
After a quiet week on the new host, set the A record’s TTL back to 3600 or the registrar’s default, then cancel the old hosting. The whole migration takes an afternoon of work spread across two days, and it’s done before most of your visitors refresh the page.