Migrating a WordPress site sounds scary, but it's really just moving two things - your files and your database - and then pointing your domain at the new server. Done in the right order, visitors never see a second of downtime. Here is exactly how to migrate a WordPress site the safe way.
Quick answer
To migrate a WordPress site, copy all files and export the database, import both on the new host, update wp-config.php with the new database details, and replace the old domain in the database if it changes. Test using your hosts file, then point the DNS to the new server. Migration plugins automate most of these steps.
The two things you're actually moving
A WordPress site is just two parts: the files (WordPress core, your theme, plugins and uploads, all under one folder) and the database (your posts, pages, settings and users). Migrating means copying both to the new host, reconnecting them, testing, and only then switching your domain over.
Option A: let a plugin do it
For most sites, a migration plugin is the easiest route. Tools like Duplicator, All-in-One WP Migration or Migrate Guru package your files and database into one archive that you restore on the new host. This is the recommended path if you're not comfortable with FTP and databases.
Option B: migrate manually (more control)
If you prefer to do it by hand - or the site is too big for a plugin - the steps are:
- Back up everything first. Download all files over SFTP and export the database from phpMyAdmin. Don't skip this.
- Copy the files to the new host over SFTP, into the web root. If your FTP login fails part way through, see FTP 530 login authentication failed.
- Import the database - create a fresh database on the new host and import your SQL export.
- Update wp-config.php with the new database name, user and password.
- Test before switching DNS (see below).
Test on the new server before you switch
This is the trick that gives you zero downtime: test the site on the new host while your domain still points at the old one. Most hosts give you a temporary URL, or you can edit your computer's hosts file to preview the real domain on the new server's IP. Click through the site, log into wp-admin, check images and forms. Fix anything broken now - before real visitors are involved. If the database won't connect, see error establishing a database connection; if you get a blank page instead, see the WordPress white screen of death.
Migrating email, subdomains and cron jobs too
A WordPress migration is rarely just the site. If you run mailboxes on the same domain, plan their move separately so mail keeps flowing - a broken SPF/DKIM record after a move is a common cause of mail going to spam. Also check for subdomains (staging, an API, a blog on its own subdomain) and any scheduled WP-Cron tasks or real server cron jobs that need to exist on the new host too, not just the main files and database.
Switch DNS last
Once the new copy works, change your domain's A record to the new server's IP (or update the nameservers). See how to point a domain to your server for the exact steps. DNS changes take time to propagate - up to a few hours - during which some visitors reach the old server and some the new one. Because both run the same site, nobody notices. Tip: lower your domain's TTL to 300 seconds a day before the move so the switch propagates faster. If a visitor reports DNS probe finished NXDOMAIN after the move, it usually means propagation simply hasn't reached them yet.
After the move
- Update the site URL if the domain changed (Settings → General, or a search-and-replace in the database).
- Install an SSL certificate on the new host so the site stays on HTTPS - if you see a warning, see fixing "Not Secure" / expired SSL.
- Watch for a too many redirects loop, a common symptom of an SSL or site-URL mismatch right after a migration.
- Leave the old host running for a week in case you need to roll back, then cancel it.
If something goes wrong: rolling back
Because you switch DNS last and keep the old host running, rolling back is simple: point the A record back at the old server. This is exactly why the "test first, switch DNS last" order matters so much - it keeps a working fallback alive the entire time, so a migration mistake is an inconvenience, not an outage.
The golden rule of migration: test everything on the new server before you touch DNS. Switch the domain last, and downtime is zero.