How to Migrate a WordPress Website Safely

Moving a WordPress site to a new host is one of the most common operations in web hosting — and one of the most feared. The fear is justified: a migration touches your files, your database, your URLs, and your DNS, and a mistake in any one of them can take the site offline or corrupt it silently.

The good news is that a safe migration is a procedure, not a gamble. Follow the sequence in this guide — backup, prepare, copy, test, switch, verify — and the move becomes boring, which is exactly what you want.

What a WordPress site actually consists of

Before you move anything, know what you are moving. A WordPress site has three parts:

1. The files. Everything in the WordPress installation: core files, themes, plugins, and the uploads folder (your images and media). The uploads folder is usually the largest part.
2. The database. Posts, pages, comments, settings, users, and most plugin data live in MySQL or MariaDB. The database is the part people most often forget or corrupt.
3. The configuration. The wp-config.php file holds the database credentials, the site URLs, and security keys. It is small, but the site will not run without a correct one.

A complete migration moves all three, and verifies all three at the destination before anything is switched off at the source.

Step 1: back up everything, and verify the backup

Before you touch anything, take a full backup of the live site: files plus database. Then verify it:

• Check the backup file sizes are plausible — a database backup of a few kilobytes for a site with hundreds of posts means something is missing.
• Download the backup to your own computer, not just to the server you are leaving. A backup stored on the server you are migrating away from is not a backup.
• If your backup tool offers a verification or test-restore option, use it.

This backup is your rollback plan. If anything goes wrong later, you can restore it and try again. Never start a migration without it.

Step 2: prepare the destination

Set up the new hosting account and check the environment before you copy anything:

• PHP version. The destination should run PHP 8.3 or newer (WordPress.org’s current recommendation). If the old host ran an older PHP version, check that your theme and plugins are compatible with the newer one — a plugin that worked on PHP 7.4 can break on PHP 8.3. Test this on staging, not on the live site.
• Database version. MySQL 8.0 or MariaDB 10.6 or newer.
• PHP limits. Check upload_max_filesize, post_max_size, max_execution_time, and memory_limit. A large site may need higher limits than the defaults to import its database.
• SSL certificate. Install the certificate at the destination before the switch, so the site works over HTTPS from the first moment DNS points at it.
• Create the empty database and user at the destination, and note the credentials.

Step 3: choose a migration method

There are three common approaches. All three work; choose the one that matches your comfort level.

A migration plugin. Plugins such as Duplicator, All-in-One WP Migration, or UpdraftPlus (with its migrator) package the site into an archive, which you then import at the destination. This is the easiest method for most people, and the plugin handles the URL search-and-replace for you. Watch the size limits: free versions often cap the archive size, and very large sites may need the paid version or a manual move.

WP-CLI (command line). If you have SSH access at both ends, WP-CLI is the fastest and most reliable method: export the database with wp db export, copy the files with rsync, import with wp db import, and fix the URLs with wp search-replace. This is the professional’s choice, but it requires comfort with the command line.

Manual (phpMyAdmin + FTP/SFTP). Export the database from phpMyAdmin, download the files by FTP or SFTP, upload them at the destination, import the database, and update wp-config.php. It works, but the URL replacement must be done carefully — a naive find-and-replace on the raw SQL can corrupt serialised data (WordPress stores some settings as serialised PHP arrays, where the string length is part of the data). Use a tool that understands serialisation, such as WP-CLI’s search-replace or a dedicated search-and-replace plugin, rather than editing the SQL file in a text editor.

Step 4: copy the site and test it before switching DNS

This is the step that separates a safe migration from a gamble: test the site at the destination before you change DNS.

How to test without changing DNS:

• Use a temporary URL provided by the host, if one is available.
• Or edit your computer’s hosts file to point the domain at the new server’s IP address. This lets your computer — and only your computer — see the new site while the rest of the world still sees the old one.

Then test thoroughly:

• The homepage and several inner pages load, with images.
• The admin area (/wp-admin) works, and you can log in.
• Forms submit correctly.
• The store checkout works, if it is a store — place a test order.
• Search works, and a few posts open correctly.
• The site loads over HTTPS without mixed-content warnings.

Also check the PHP error log at the destination for warnings your old host may have hidden. A plugin that throws deprecation warnings on PHP 8.3 will tell you now, while the old site is still live.

Step 5: lower the TTL, then switch DNS

A day or two before the switch, lower the TTL on the domain’s A record (and AAAA record, if you have one) to 300 seconds. This means that when you change the record, resolvers around the world pick up the new address within minutes rather than hours.

Then update the DNS records to point at the new server’s IP address. Do not cancel the old hosting yet.

Warning: do not change the nameservers and the hosting at the same time unless you have to. If your DNS is hosted by a third party, keep it there and only change the A record. If your DNS is hosted by the old host, move DNS first or make sure the new host has a complete copy of the zone. Changing two things at once makes failures much harder to diagnose.

Step 6: verify after the switch

After the DNS change, verify from the outside, not just from your own computer (which may still have the old address cached):

• Use a public DNS lookup tool to confirm the domain resolves to the new IP.
• Load the site from a different network or a mobile connection.
• Test the admin login, a form submission, and (for a store) a test checkout.
• Check that email still works — especially if mail was hosted with the old provider. If your MX records pointed at the old host, you may need to update them, or move mail separately. See How to Transfer a Domain Without Disrupting Email.
• Check the SSL certificate is valid and auto-renewing.
• Re-check scheduled tasks: WordPress cron jobs, and any server cron jobs that ran on the old host, need to exist on the new one.
• Update any hardcoded references to the old server: external services, APIs, webhooks, and CDN settings that pointed at the old IP.

Then watch the site for 24–48 hours. Keep the old hosting active for at least a week as a fallback — if something breaks, you can point DNS back in minutes.

Step 7: clean up

Once the site has run correctly on the new host for a week, cancel the old hosting plan, remove any temporary test URLs or hosts-file entries, raise the DNS TTL back to a normal value (for example, 3600 or 86400 seconds), and take a fresh backup on the new host.

Common mistakes

• Migrating without a verified backup. The one time you skip it is the time you need it.
• Editing the database SQL by hand. Serialised data breaks silently, and the damage shows up weeks later as missing settings.
• Switching DNS before testing. If the destination has a problem, the whole world sees it at once.
• Forgetting email. A site migration that breaks mail is a migration that failed, even if the website looks fine.
• Ignoring the PHP version change. Moving from PHP 7.4 to 8.3 can break old plugins. Test before you switch, and have a plan to replace or update anything that fails.

The bottom line

A safe WordPress migration is a sequence: back up and verify, prepare the destination, copy the site, test it privately, lower the TTL, switch DNS, verify from the outside, and only then cancel the old host. Skip the testing step and you are gambling; skip the backup and you are gambling without a safety net. Done in order, the whole move is uneventful — and uneventful is the goal.

Related reading: How to Choose WordPress Hosting in 2026, WordPress Caching Explained, and How to Transfer a Domain Without Disrupting Email. See our WordPress hosting plans.

---

Reviewed 25 October 2026. Prices, plan contents, and availability for Offshore Hosting plans are [TO BE CONFIRMED] — this article does not state them.

Sources

• WordPress.org — Requirements: https://wordpress.org/about/requirements/
• WordPress.org — Hosting Handbook, server environment: https://make.wordpress.org/hosting/handbook/handbook/server-environment/
• PHP.net — Supported Versions: https://www.php.net/supported-versions.php
• Cloudflare — Onboard a domain (DNS setup): https://developers.cloudflare.com/fundamentals/manage-domains/add-site/

← All guides · Knowledge Base