How to move a WordPress site to a new host safely

A reliable migration is a controlled copy, test and cutover—not a race to cancel the old account. This checklist keeps the website recoverable at every stage.

Updated 26 October 2026

1. Inventory the current website

Record the WordPress and PHP versions, active theme, plugins, database size, disk usage, scheduled tasks, redirects, SSL setup and any server-specific rules. List integrations such as forms, SMTP, payment gateways, analytics, caching, CDN and external storage. Note whether the same account also hosts email.

This inventory tells you what the new host must support and gives you a test list after the move.

2. Create a complete, independent backup

Download the website files and export the database. Do not rely only on a backup that remains inside the account you are about to leave. Check that the archive opens and that the database export contains WordPress tables. For a busy store or membership site, plan how orders or account changes made during the final copy will be handled.

The Australian Signals Directorate recommends regular website backups and notes that a backup is what allows recovery after data loss or a cyber incident. A migration is an ideal time to test whether your backup is actually usable.

3. Prepare the new hosting account

Create the destination site without changing public DNS. Match the required PHP version and extensions, create the database, install an SSL certificate where the platform allows it, and configure caching carefully. Copy the files and import the database. Update credentials and paths only where required.

Plugin migration or manual migration?

A migration plugin can be efficient for a standard site. A manual file-and-database migration provides more visibility and may be necessary for large or unusual sites. Whichever method you use, keep the original site untouched until the new copy passes testing.

4. Test before changing DNS

• Homepage, key landing pages, posts and media load over HTTPS.
• WordPress admin login and password reset work.
• Forms arrive at the correct mailbox and show a useful confirmation.
• Search, checkout, account and other interactive features work.
• Permalinks, redirects, robots.txt and sitemap are correct.
• There are no mixed-content, PHP, database or browser console errors.
• Backups are enabled at the destination and a restore process is documented.

Use a temporary URL, preview domain or local hosts-file entry to test the destination. Avoid publishing a crawlable duplicate of the site.

5. Plan the DNS cutover

Identify whether you are changing an A/AAAA record, CNAME or nameservers. If email stays where it is, preserve all MX and mail-related TXT/CNAME records. Lowering TTL ahead of time can shorten caching, but it does not create an instant global switch.

For a site that changes frequently, schedule a short content freeze or run a final database sync immediately before cutover. Record the old DNS values so they can be restored.

6. Switch, monitor and verify

After the DNS change, test from more than one network or DNS resolver. Confirm HTTPS, forms, login, checkout, scheduled jobs and outbound mail. Watch server error logs and uptime monitoring. Clear application and CDN caches only when you understand which copy they reference.

7. Keep a rollback window

Do not cancel the old host immediately. Keep it available until DNS caches have expired, the new site has handled real traffic, forms and transactions are confirmed, and a destination backup has completed. Store a final offline archive with the migration date.

Common migration failures

Primary reference: Australian Signals Directorate: Secure your website.