How to Migrate WordPress to a New Host Safely

How do you migrate WordPress to a new host safely?

To migrate WordPress safely, you copy the site to the new host while the old one keeps serving traffic, test the copy on a temporary URL, and only switch DNS once the new version works. The order matters: full backup first, then files and database, then verification, then the DNS cutover last. Done this way, visitors never hit a broken or half-moved site.

The single biggest mistake people make is treating migration as a one-button event. It is really a controlled hand-off. Your old host stays live and authoritative until you have proven the new host serves an identical, working site. Only then do you point the domain across. Everything below is built around that principle — keep the old site running, prove the new one, switch last.

Before you start: back up and check compatibility

A migration is only as safe as the backup you can roll back to. Take a complete backup, not just the database, and store a copy somewhere off both servers — your laptop or cloud storage.

You need three things from the old host:

• All WordPress files — the full public_html (or site root), including wp-content, themes, plugins, and uploads.
• The database — exported as a .sql dump via phpMyAdmin or WP-CLI.
• Your wp-config.php — you will need the table prefix and reference values, though you will create fresh database credentials on the new host.

Then confirm the destination can actually run your site. Check that the new host matches or exceeds your current PHP version, MySQL/MariaDB version, and any required PHP extensions. Compare PHP memory limit and max_execution_time too — a site that works on generous limits can choke on a stricter default. What most hosts won't tell you: a mismatch here is the quiet cause of the dreaded white screen right after a move.

If your site is mission-critical, put it into maintenance mode only for the final database sync, not for the whole migration. Long maintenance windows are almost always unnecessary if you stage the move properly.

Moving the files and the database

With backups in hand, recreate the site on the new host. You have two realistic paths.

The plugin route (easiest)

Tools like Duplicator, All-in-One WP Migration, or a host's own migrator package your site into a single archive and rebuild it on the destination. This is the right choice for most small-to-medium sites — it handles the database URL rewriting for you. Watch the archive size: very large sites can exceed a tool's free-tier import limit, which is where the manual route wins.

The manual route (most control)

1. Upload your files to the new host via SFTP or the file manager, into the correct web root.
2. Create a fresh database, database user, and password on the new host, and grant the user full rights to that database.
3. Import your .sql dump into the new database.
4. Edit wp-config.php with the new database name, user, password, and host.

If you are moving to a privacy-focused or offshore provider, a host that offers SSH and WP-CLI access — as LaunchPad Host does — makes the manual route far smoother, because you can run the database steps from the command line instead of fighting browser upload limits.

Updating URLs and the database safely

If your domain stays the same, you may only need to update the site URL and home URL. If anything in the path changes — even temporarily, while testing on a staging URL — you must rewrite URLs throughout the database. This is where sites get silently corrupted.

WordPress stores some settings as serialized data, which encodes the length of each string. A blind SQL find and replace changes the text but not the recorded length, breaking widgets, theme options, and page builders. The safe way:

• WP-CLI: wp search-replace 'oldurl.com' 'newurl.com' — it understands serialized data and fixes lengths automatically.
• A serialization-aware script such as the well-known Search Replace DB tool, if you cannot use WP-CLI.

After rewriting, regenerate permalinks (Settings → Permalinks → Save) so rewrite rules match the new environment. Never edit URLs with a raw UPDATE statement across the whole database — that is the most common way a migration looks fine on the homepage but breaks everywhere else.

Testing before you switch DNS

Do not point your domain at the new host yet. Test the copy first, while real visitors still land on the old, working site.

The cleanest way to preview is editing your computer's hosts file: map your domain to the new host's IP address locally, so only your machine sees the new server. This lets you browse the real domain on the new host without touching public DNS. Walk through a checklist:

• Homepage, key pages, and posts load with correct styling.
• Images and media resolve (no broken links).
• Forms submit and contact email arrives.
• Login, checkout, or any dynamic feature works end to end.
• No mixed-content or SSL warnings in the browser console.

Issue or confirm an SSL certificate on the new host before the switch — most providers offer free automated certificates, but they can take a few minutes to provision. A site that loads over HTTP but throws certificate errors on HTTPS is a migration that is not finished.

Switching DNS with zero downtime

The cutover is the moment traffic moves to the new host. Two preparations make it painless.

1. Lower your TTL first. A day before the switch, reduce your domain's DNS TTL (time to live) to 300 seconds. This tells resolvers to re-check records frequently, shrinking propagation from hours to minutes once you make the change.
2. Do a final database sync if your site takes orders or comments, so no data created during testing is lost. Briefly enable maintenance mode for this final sync only.

Then update the DNS records — usually the A record (to the new IP) and any AAAA, plus CNAME/MX as needed — at your DNS provider. Propagation now happens fast because of the lowered TTL, though it can still take up to a few hours globally. During this window, both old and new hosts may receive traffic, which is exactly why you keep both running.

Keep the old site live and untouched for at least 72 hours after the switch. Watch error logs and analytics on the new host. Only when traffic has fully shifted and the site has run clean should you cancel the old plan. If you registered or transferred the domain with the same provider as your hosting — LaunchPad Host handles both, including crypto payment — keeping DNS and hosting under one roof simplifies this final step.