How to Migrate a WordPress Website to a New Host

Moving a WordPress site to a new host means transferring its files and database, then repointing your domain without losing content, users or search visibility. You can migrate a WordPress website by backing up its files and database, importing them to the new host with a plugin or a manual SFTP and database transfer, then updating your DNS settings once the new site checks out. The right method depends on your site’s size, your comfort with SFTP and database tools, and whether your new host offers a free migration service.

This guide covers moving a self-hosted WordPress website to a new host while keeping its domain. A domain change or redesign adds separate redirect and search-migration work. The transfer time depends on data size, hosting limits and the chosen method; allow time for testing and DNS caches too.

Getting the sequence right matters more than speed. Skipping a backup or rushing the DNS change can cost you content or keep your site offline longer than necessary.

Key Takeaways

• Back up your WordPress files and database before making any changes, and confirm your new host meets WordPress’s requirements first.
• A migration plugin or your host’s built-in migration service suits most sites, while manual SFTP and database transfers give you more control over complex or oversized sites.
• Use the host’s supported preview or a local hosts-file mapping for the real hostname before changing DNS. Check HTTPS, redirects and business functions again after cutover.

What Should You Check Before Moving Your Site?

Prepare a destination that can run the current site before changing anything on the source. Avoid combining a host move with a redesign, plugin replacement or major version upgrade; it makes failures harder to diagnose.

Choose the Method and Prepare Access

• Confirm the destination meets WordPress’s current requirements and supports your theme, plugins, scheduled jobs and storage needs.
• Choose assisted migration, a compatible migration plugin, or a manual file-and-database transfer. Check multisite and large-database support separately.
• Confirm access to both hosting accounts, WordPress, the domain’s DNS provider and the backup storage. Use a temporary account or migration token where supported, then revoke it after the move.
• Record DNS records and TTLs, including A, AAAA, CNAME, MX, SPF, DKIM and DMARC. Identify whether email, CDN, media storage or scheduled jobs live outside WordPress.
• Confirm HTTPS can work on the destination during testing. Ask the host how to test the real hostname before public DNS changes.

Back Up and Plan for New Orders

Take a full, recoverable copy of the database and all required files. Check what your backup includes: configuration files, custom directories and non-standard database tables may need separate handling. Store the backup away from the source server and verify that the archive and database can be restored. My WordPress backup plugin comparison explains the main options.

For shops, bookings and membership sites, agree a final data-sync window. An initial copy becomes stale as soon as the old site accepts another order, registration or comment. Pause writes for the final sync or use a specialist process that safely transfers those changes. Do not allow two independent copies to accept orders without a reconciliation plan.

Keep authentication and the firewall enabled by default. If a verified migration tool requires an exception, restrict it to the necessary account, address or period and restore protection immediately afterwards. Do not disable security controls across the whole site as a routine preparation step.

How to Move Your Site with a Plugin or Hosting Service

An assisted migration is usually my first choice for a business owner who does not administer servers. Ask the destination host what is covered, whether the source will stay online, how changing data is handled, and who checks the result. “Free migration” does not necessarily include email, every custom application or unlimited sites.

Use the Instructions for Your Chosen Plugin

Migration plugins use different workflows. Duplicator can use an archive plus installer; All-in-One WP Migration imports its own export through WordPress. Do not combine the installer steps from one product with another product’s backup file.

1. Install a current compatible version of the chosen plugin on the source and check its requirements, available disk space and transfer limits.
2. Create and download the full migration package using that plugin’s documented export process. Retain an independent recoverable backup.
3. Prepare an empty destination or a backed-up destination you are authorised to replace. Use the same plugin’s documented import or installer workflow.
4. Supply the destination database details if the method requires them. Confirm the domain and path settings before the tool replaces data.
5. Run the tool’s validation and remove installer or archive files from public directories when its instructions require cleanup.

Check Upload Limits and Destination Restrictions

The current ServMask explanation says All-in-One WP Migration’s displayed upload limit can come from the server’s PHP configuration. Do not assume a universal 256 MB plugin cap. Ask the host which limit is blocking the import, and check the current edition’s capabilities before paying for an extension.

UpdraftPlus also supports backup restoration and migration in its free version, as documented in its official plugin listing. Check whether your specific requirements need Premium, especially files outside the standard WordPress content or more advanced backup functions.

Moving to WordPress.com is a different destination workflow. Follow its whole-site import instructions and confirm the destination plan, supported customisations and what will be overwritten.

How to Transfer WordPress Files and the Database Manually

Use a manual transfer when you can manage files, database imports and configuration reliably. Prefer SFTP or another encrypted transfer method. A manual route still has server limits: large database imports can exceed browser, PHP or database limits and may need the host’s command-line tools or assistance.

Copy the Required Files and Database

1. Identify the correct document root and database from the hosting account and wp-config.php. Do not assume the database name begins with wp_; that commonly refers to table prefixes.
2. Export the complete WordPress database, including required custom tables, through the host’s database tool or an appropriate command-line process. Keep the source copy intact.
3. Download the required WordPress files, including uploads, themes, plugins, configuration and relevant hidden files. Record external media storage and jobs that are not included in that directory.
4. Create a new destination database and user with the required privileges. Record the host-provided database name, user, password and database hostname.
5. Upload the files to the intended destination root and import the database. Use an empty or safely backed-up destination, not an unrelated live installation.
6. Update wp-config.php to use the destination database credentials and review any host-specific paths or settings. Preserve the correct table prefix.

Keep passwords and database exports private. A backup in a publicly accessible web directory can expose the entire site; move it to protected storage and remove temporary transfer copies after verification.

Keep URLs Stable Where Possible

For a same-domain host move, the public WordPress addresses and page paths normally stay the same. Test with the real hostname mapped to the new server rather than rewriting the entire database to a temporary address just for previewing.

If a domain or path really changes, use a WordPress-aware replacement tool that handles serialised data and follow the official WordPress migration guidance. Back up first, preview the replacements and avoid a blind SQL string replacement. A permanent domain move also needs a redirect map and separate search-migration checks.

How to Go Live and Confirm the Migration Worked

Test the Destination Before Changing DNS

Use the host’s supported preview method or a local hosts-file mapping for the real domain. A raw IP address may show the wrong virtual host and cannot establish that HTTPS works for your domain. Keep the test copy inaccessible to visitors and search engines without blocking the eventual live site.

1. Check representative pages, images, menus and permalinks on the destination.
2. Test login, password resets, forms, outgoing email and the sending service’s domain authentication.
3. Test checkout, payment callbacks, bookings and memberships in an appropriate test mode. Prevent the test copy from sending real customer notifications or taking unintended payments.
4. Check scheduled tasks, background jobs, caching, redirects and any externally stored media.
5. Compare the important settings, content counts and recent order or user records with the source.

Complete the Final Sync and Switch DNS

1. Pause new writes or follow the agreed specialist sync process, then transfer changes made since the initial copy. Keep one authoritative order and user database.
2. Confirm the destination certificate and real-domain configuration are ready. Clear or rebuild the appropriate caches.
3. Change only the DNS records needed for the website. Review both A and AAAA records and any www record so IPv6 or subdomain traffic is not left pointing at the old host.
4. If changing nameservers, first recreate and verify the entire required DNS zone at the new provider, including MX and authentication records. Unchanged email settings in the old zone will not protect mail after that zone stops being authoritative.
5. Check resolution from more than one network. DNS caches expire according to TTLs and resolver behaviour, so visitors may reach both servers during the transition.
6. Resume writes on the verified destination and monitor requests reaching the old server. Keep the old site from independently accepting new orders once the destination becomes authoritative.

Check Search Visibility and Recovery

For a same-domain host move, retain URLs, canonicals, redirects and existing verification files. Remove any staging-only noindex setting or crawl restriction from the live copy. Keep the sitemap accessible and use Search Console to monitor crawling and indexing. Google’s hosting-move guidance covers this scenario; a Change of Address request is not needed when the domain stays the same.

Check HTTPS, mixed content, response codes, forms and transactional email again after the switch. Compare performance under similar conditions rather than assuming the new host is faster. Remove temporary migration accounts and public installers, and confirm scheduled backups and security controls are active.

A rollback must preserve data created after cutover. Repointing DNS at the old host can discard new orders or accounts if you have not copied or reconciled them. Pause writes, preserve both databases and agree the authoritative copy before rolling back a transactional site. Keep the old hosting available until checks, DNS transition and reconciliation are complete.

A Cutover and Rollback Runbook for a Business Site

Before the move, identify the person authorised to change DNS, the person checking the application and the point at which the destination becomes the live source of new data. Keep one agreed record of these decisions, rather than several people assuming someone else has checked checkout.

Checkpoint	Evidence to retain	If it fails
Before final sync	Recoverable files/database; destination preview; saved DNS zone	Keep the source live and fix the destination.
Before opening writes	Final sync complete; recent users/orders reconciled; certificates/callbacks checked	Keep writes paused while the operator investigates.
After cutover	Real requests reach destination; mail, forms, checkout and jobs work	Preserve both data sets; choose repair or controlled rollback.
Before cancelling source	DNS transition monitored; all new data accounted for; offsite backup	Retain the source until each failed check is resolved.

Check Email and DNS Separately

If the existing DNS provider remains authoritative, a host move may need only the website records changed. Avoid replacing nameservers unnecessarily. When nameservers do change, recreate and verify the complete zone first, including mail routing, sender authentication, verification records and non-website subdomains.

DNSSEC needs its own migration sequence because the registrar’s delegation records must match the DNS provider’s signing setup. A stale DS record can make a correctly copied zone fail validation. Follow the providers’ supported process or have the responsible operator manage it. Cloudflare’s DNSSEC migration guide explains one provider-specific route.

Test incoming mail, outgoing application mail and password resets separately. A form displaying a success message does not establish that a recipient received it. If email stays with the old provider, confirm whether cancelling hosting also cancels mailboxes, forwarding or DNS.

Handle New Orders Before Rolling Back

Before the destination accepts writes, you can often leave the original authoritative copy in place while fixing the transfer. After the destination accepts an order, registration, booking or form entry, the old database is no longer necessarily complete. Changing DNS back can strand those new records.

Pause relevant writes, preserve both databases and logs, identify changes since cutover and agree the authoritative copy. Use application-aware reconciliation for orders, payment callbacks and user records. Restoring an old database over the destination can erase new business data; involve the developer or migration provider when the records cannot be merged safely.

Close the Move Completely

• Confirm scheduled jobs are not running twice and only the intended copy sends customer notifications.
• Check important entry pages, redirects, canonical URLs, robots rules and sitemap access.
• Revoke migration-only accounts and tokens; remove public installers and archives after verification.
• Confirm the destination backup schedule and restoration route. Transferred settings do not prove a backup has run.
• Record which services moved, what remains elsewhere and who now owns recovery.

For a same-URL move, follow Google’s hosting-infrastructure guidance. Keep a domain change as a separate project with its own redirects and search checks. Completing a transfer does not guarantee unchanged rankings or a faster site.

Choose the Move Your Site Can Safely Support

Match your migration method to your site’s size, complexity and your technical confidence. The right choice depends on your circumstances rather than a single best approach. A small brochure site with a handful of pages can migrate safely with almost any method, including a free plugin or your new host’s built-in service.

A large ecommerce store, membership site or heavily customised site needs more caution. Use a migration process with explicit support for large databases, custom configuration and data outside standard WordPress directories. A specialist managed transfer is often more appropriate than improvising a manual move. These are the areas most likely to cause problems with automated tools.

Whichever method you choose, back up thoroughly, test before you go live, and keep your old hosting account available until you’ve confirmed the new site works end to end. A WordPress website migration doesn’t need to be technically difficult if you follow that order. Skipping steps to save time is where most avoidable problems start.

Frequently Asked Questions

Share this article

LinkedInWhatsAppFacebookXEmail