WordPress hosting migration: a step-by-step transfer guide

For most small and medium WordPress sites, a well-tested migration plugin gets the job done safely, while sites running WooCommerce or complex integrations are better handled with host-assisted migration. Downtime should be close to zero if you manage your DNS TTL properly. The one non-negotiable step is a full, verified backup before you touch anything. Start with the checklist below.

TL;DR:

• Using DNS TTLs of 300 seconds or less at least 24 hours before switching minimizes potential downtime during migration.
• Verification of backups, including test restores and compatibility checks of PHP, MySQL, and plugin support, reduces migration errors significantly.
• Manual migration requires careful handling of serialized data during URL replacements to prevent site-breaking corruption.
• For large or complex sites, such as WooCommerce or multisite networks, host-assisted or professional support offers safer, more reliable transitions.
• Keeping the old hosting environment active for several days post-migration ensures fallback options are available in case of unforeseen issues.

WordPress hosting migration checklist: the steps in order

Before opening a single file, work through these steps in sequence. Skipping the DNS preparation step is the most common reason small business owners see hours of unexpected downtime.

1. Lower your DNS TTL to a low value, around 300 seconds, at least one to two days before you plan to switch hosts.
2. Take full backups of your files and database, then store copies offsite, away from either host.
3. Set up the destination environment and confirm PHP and MySQL versions match or exceed your current setup.
4. Choose your migration method, plugin, manual, or host-assisted, and carry out the transfer.
5. Preview the site using a hosts file override or the host’s staging URL, then update DNS and monitor traffic.

This sequence mirrors the approach laid out in the WordPress developer documentation on migrating WordPress, which treats backup, database import, and permalink checks as the backbone of any safe transfer. Everything from here is detail on how to execute each step properly.

How do I prepare my site before migrating?

Compatibility mismatches cause more failed migrations than anything else. Before you move a single file, check what PHP and MySQL (or MariaDB) versions your current site runs on, and confirm your new host supports the same or newer. A site built on PHP 8.1 dropped onto a host still running 7.4 will throw fatal errors the moment you switch over, and required PHP extensions (GD, cURL, mbstring) are just as easy to overlook.

Next, take stock of everything that needs to travel with the site:

• All active and inactive plugins, plus their licence keys if applicable
• Your theme and any child theme customisations
• Custom code snippets, whether in a plugin or a functions.php file
• Scheduled cron jobs, particularly ones tied to WooCommerce or membership plugins
• Server-level configuration files such as .htaccess

Backups need proper verification, not just creation. Run a test restore of your database and files somewhere separate from production. A backup you have never restored is a hope, not a plan, and the Fasthosts migration guide makes preparing the destination environment and previewing before DNS changes central to a smooth transfer.

Don’t forget the records that live outside WordPress itself: DNS entries, MX and TXT records for email, and any CDN configuration. These get missed constantly because they don’t live in your WordPress database.

Pro Tip: Hold off on major WordPress core, theme, or plugin updates until after the migration is verified working on the new host. Updating mid-move adds a second variable to troubleshoot if something breaks.

Which migration method suits your site: plugin, manual, or host-assisted?

The right method depends on your site’s size, your technical comfort, and how much downtime you can tolerate.

• Plugin-based migration (tools like Duplicator or All-in-One WP Migration) suits straightforward brochure sites and blogs with modest media libraries. It’s the fastest route for non-technical owners, though upload limits and archive extraction failures are common once a site’s file size climbs into several gigabytes.
• Manual migration using SFTP or rsync alongside SQL exports, or scripted through WP-CLI, gives you full control and scales to larger sites. It requires SSH access and comfort with the command line, but avoids the compression and upload ceilings that trip up plugins.
• Host-assisted migration puts the transfer in your new host’s hands, or an agency’s. It suits business-critical sites, multisite networks, and anything with WooCommerce or third-party integrations where a mistake costs real money. Confirm exactly what your host checks before, during, and after the move, since quality varies significantly between providers.

As a decision rule: small brochure site with FTP-only access, go plugin. Large site, SSH access, and a need for precision, go manual. Multisite, WooCommerce, or low tolerance for anything going wrong, get help. The Pantheon learning centre notes plugin-based transfers are usually fastest for simple sites, but larger or restricted hosting setups often need manual or host-assisted routes instead.

How do I manually migrate my WordPress site?

Manual migration gives you the clearest view of what’s actually happening to your site, and it’s the method serious developers reach for when precision matters more than speed.

1. Download your files. Use SFTP for smaller sites. For larger ones, create a server-side archive over SSH first, then download that single compressed file. Don’t forget hidden files like .htaccess, which SFTP clients sometimes hide by default.
2. Export your database safely. Run mysqldump --single-transaction to avoid locking tables mid-export, or use wp db export if you have WP-CLI installed. Avoid exporting through phpMyAdmin on larger databases; it frequently times out or truncates large tables.
3. Create a new database and user on the destination server, then update wp-config.php with the new database name, username, password, and host.
4. Import the database on the new server, then run a safe search-replace for your URLs. This is where most manual migrations go wrong. A plain SQL REPLACE command corrupts serialized data stored by widgets, page builders, and theme options. Use wp search-replace --precise, which is built specifically to preserve serialized data structures during URL changes.
5. Upload your wp-content folder, set correct file and folder permissions (typically 755 for directories, 644 for files), flush permalinks, and regenerate thumbnails if your media library didn’t transfer image sizes correctly.
6. Preview before you touch DNS. Edit your local hosts file to point your domain at the new server’s IP, or use the host’s temporary staging URL, so you can test everything while the live site still serves current visitors.

For migrations you expect to repeat, such as syncing a staging environment or moving multiple client sites, pairing WP-CLI with rsync creates a scriptable, repeatable workflow that’s far less error-prone than doing each step by hand every time.

Pro Tip: Always include --dry-run when testing a WP-CLI search-replace command for the first time. It shows you exactly what would change without touching a single row, which is invaluable when you’re not entirely sure your replacement pattern is correct.

How do I switch DNS with minimal downtime?

DNS cutover is where careful preparation pays off, or where an unprepared migration turns into a stressful afternoon.

• Lower your DNS TTL to around 300 seconds at least 24 to 48 hours before cutover. Some registrars enforce minimum TTLs, so check yours in advance.
• Update the A record (and AAAA if you use IPv6) to point at your new server’s IP address, or update the CNAME if you’re on a platform that uses one.
• Monitor propagation using a DNS checker tool rather than assuming it’s instant everywhere.
• Provision your SSL certificate on the destination server before or immediately after cutover, and check for mixed content warnings once HTTPS is live.
• Keep both servers live during the switch, and run a final file and database sync just before decommissioning the old one, so nothing submitted during the transition window gets lost.

Even with a low TTL, some ISPs cache DNS longer than they should, so a handful of visitors may still see the old site for several hours after cutover. That’s normal, not a sign something has gone wrong.

What should I test after migrating my WordPress site?

Run through a proper QA pass before you consider the migration finished, not just a glance at the homepage, using this website audit checklist: actionable steps to boost SEO to ensure thorough post-migration checks.

• Load the homepage, key landing pages, and admin login to confirm the basics work.
• Test contact forms, search functionality, and permalinks (a stray 404 on every blog post usually means permalinks need flushing).
• If you run WooCommerce, walk through checkout and a test payment end to end.
• Crawl the site for broken images and hardcoded old-domain URLs, and check Google Search Console for crawl errors if you have it connected.

Testing after migration should specifically cover checkout flows, redirects, and a full crawl comparison against the old site, with the old host kept active for several days as a safety net rather than cancelled immediately. If something breaks badly, rollback is simple: repoint DNS back to the old server, restore your verified backup if needed, and contact your host’s support team while you diagnose the fault.

Why trust this migration guide, and when should you hire help?

This guide draws on the same sequence the official WordPress documentation recommends: backup, compatibility check, careful database handling, and verification before cutover. MB Web has spent 50 years’ combined experience delivering web design, development, hosting, and maintenance for businesses across Sussex, Surrey, Kent, and the wider South East.

Some migrations genuinely benefit from a professional hand, particularly multisite networks, large databases, WooCommerce stores, or sites with complex third-party integrations where a mistake has a direct cost. During a managed migration, MB Web handles the environment audit, server-to-server transfer, SSL setup, and post-launch QA, with a rollback plan in place before anything is switched over. This guide is written from that same practical experience, with James Golding overseeing the editorial perspective below.

Handling email during a hosting migration

Email is the part of a migration owners forget until it stops working, usually mid-move, at the worst possible moment.

If your email runs through your hosting provider (common with cPanel-style setups), it will need recreating on the new server: same mailboxes, same forwarding rules, same autoresponders if you use them. This is separate from your website files and database entirely, so a plugin-based site migration will not touch it.

Check your MX records before you start. If email is hosted separately from your website, through Google Workspace or Microsoft 365, for example, those MX records typically don’t need to change at all when you move web hosting. Confirm this before cutover so you don’t accidentally break working email while fixing your website.

If email does live on the same host as your site, plan the switch carefully:

• Set up mailboxes on the new server before cutover, matching existing addresses exactly.
• Export any existing mail you need to keep, since most hosts don’t migrate mailbox contents automatically.
• Lower MX record TTL alongside your A record TTL, so the switch propagates on a similar timeline.
• Warn anyone using email-to-form plugins or transactional email services that a brief window of missed messages is possible.

Getting this wrong doesn’t just cause inconvenience. Missed customer enquiries during a migration window can cost a small business real revenue, so treat email with the same care as the database.

Optimising performance after migration

A migration is the perfect moment to fix performance issues you’d been putting up with on the old host, rather than simply recreating them on the new one.

Start with caching. If your previous host had server-level caching (many managed WordPress hosts do), your new environment might not, and page load times can quietly get worse without an obvious error to alert you. Install a caching plugin if your new host doesn’t handle this at server level, and clear any cached versions of pages left over from testing before you consider the site fully live.

CDN configuration needs the same attention. If you ran a CDN like Cloudflare in front of your old site, you’ll need to update its origin server settings to point at the new host, not the old one, plus reissue or reconfirm SSL through the CDN so certificates match correctly. Skipping this step is a common cause of sites that look “half migrated,” loading some assets from the new server and some cached ones from the old.

Once the dust settles, run a fresh speed test rather than assuming the new host performs identically to the old one. Server specifications, PHP versions, and default configurations all vary between providers, and a host with faster raw specs can still perform worse if caching isn’t configured correctly out of the box. This is also a sensible point to review broader maintenance practices that keep a site fast well beyond launch day.

Security considerations before and after the move

Migration is a moment of genuine vulnerability for a WordPress site, not just administrative hassle.

During the transfer itself, temporarily disable any aggressive firewall or security plugin that blocks unfamiliar IP addresses; otherwise you risk locking yourself out of the new server while you’re trying to configure it. Re-enable it, with rules updated for the new environment, only once you’ve confirmed everything works.

SSL certificates need explicit attention rather than assumption. Provision a fresh certificate on the destination server, don’t assume the old one transfers automatically, and check for mixed content warnings once HTTPS is live, since these often stem from hardcoded HTTP links left in the database from before the move.

Database credentials deserve fresh values, not a copy-paste of the old ones. When you update wp-config.php on the new server, generate new database passwords and, while you’re in there, refresh the WordPress security keys too. It costs nothing and closes off any credentials that might have leaked during the transfer process.

Finally, check file permissions on the new server match WordPress’s recommended settings rather than whatever the migration tool defaulted to. Overly permissive folders (777, for instance) are a common and entirely avoidable security gap that migrations sometimes introduce without anyone noticing.

Common migration pitfalls and how to fix them

Most migration failures trace back to a handful of repeat offenders, and knowing them in advance saves hours of troubleshooting.

Serialized data corruption tops the list. It happens when someone runs a plain SQL find-and-replace on the database instead of a tool built to handle PHP’s serialized arrays. The result: broken widgets, missing theme settings, or a page builder that silently stops rendering content correctly. The fix is prevention, not cure, use WP-CLI’s search-replace or a migration plugin that explicitly supports serialization, never a raw SQL query.

Upload and archive limits catch out plugin-based migrations on larger sites. If a plugin’s export archive exceeds your host’s upload limit, the transfer fails partway through, sometimes silently. Checking your destination host’s upload limits before you start saves a wasted afternoon.

Interrupted transfers on shared hosting, where resource limits kill long-running processes, corrupt files or leave databases half-imported. Running transfers via SSH where possible, rather than through a browser-based tool with a timeout, avoids this.

Permalink 404s after migration are almost always fixed by simply resaving your permalink structure in WordPress settings, which forces a fresh .htaccess rewrite. And if images look broken sitewide, check for a wp-content upload path mismatch between old and new server structures before assuming files failed to transfer.

Get your migration handled by MB Web

MB Web is the practical alternative to muddling through a migration alone at 11pm with a half-restored database, especially if your site takes payments, runs a booking system, or simply can’t afford unplanned downtime. Rather than piecing together plugins and hoping the search-replace worked, you get an environment audit, a proper server-to-server transfer, SSL configured correctly from the start, and post-launch QA before anyone calls the job done.

This kind of managed migration suits estate agents, SMEs, and any business running WooCommerce or third-party integrations where getting it wrong costs more than the migration itself. Before requesting a quote, have your current hosting login details, a rough sense of your database size, and a list of any custom integrations ready, that’s usually enough for us to scope the work accurately. Engagements are quoted per project rather than locked into a long contract, so you know the cost upfront.

If you’d like a web design team based in Sussex to take the migration off your hands, or you’re weighing up development work alongside the move, get in touch through our contact page and tell us what you’re working with. We’ll give you an honest answer on scope and cost before anything is agreed.

Sources

• WordPress developer documentation — migrating WordPress
• How to migrate WordPress without downtime — Pantheon learning centre
• How to migrate WordPress with WP-CLI — Fix I.T. Phill
• How to migrate a WordPress site — Fasthosts

FAQ

Recommended

• What is website hosting? A guide for Sussex businesses
• Step by step web development: a beginner’s guide
• Website Hosting | Website Design Lewes | MB Web
• Step by step website launch: your complete guide