Migrating WordPress means moving three things: the files, the database, and the database credentials in wp-config.php. That’s the whole job when you’re keeping the same domain — and most people are. If the domain isn’t changing, you don’t need to touch a single URL in the database, which removes the riskiest part of the process entirely.
If the domain is changing, there’s one extra step, and one specific trap: never find-and-replace URLs directly in the SQL file. WordPress stores some data in a format where doing that silently corrupts it. This guide covers both cases, the three ways to do the move, and what to check afterwards.
1. Back up files and database. 2. Copy the files to the new host’s public_html. 3. Create a database there and import the SQL dump. 4. Edit wp-config.php with the new database name, user, password and host. 5. Test the site on the new server before touching DNS. 6. Switch the nameservers. 7. Re-save your permalinks.
Same domain? You’re done — no URL changes needed. Changing domain? Add one step: wp search-replace, never a find-and-replace in the SQL.
First: is the domain changing?
Everything about the difficulty of this migration hinges on that one question.
| Scenario | What’s involved |
|---|---|
| New host, same domain the common case | Files + database + wp-config.php. No URL changes at all. No SEO risk |
| New host, new domain | All of the above, plus a proper search-replace across the database and 301 redirects |
Most migration guides walk you through URL replacement as though it were mandatory. It isn’t. If your domain stays the same, every URL in the database is already correct — WordPress will keep serving yourdomain.com from the new server exactly as it did from the old one. Skipping that step removes the single most error-prone part of a WordPress migration.
And if you are changing domain as well as host, do them as two separate moves, a couple of weeks apart. Combining them means that when something breaks you won’t know which change caused it — a point our website migration checklist makes about migrations generally.
The three ways to do it
1. Let your host migrate it
Free at most providers, and the right answer for most people. They move files, database and configuration, and they can fix problems on the destination server directly rather than describing them to you.
2. A migration plugin
The popular route: a plugin exports your site as a package, you install fresh WordPress on the new host, and the plugin imports everything. It works well for small and medium sites, and it handles URL replacement for you if the domain changes.
The limitation is size. Plugin imports run through PHP, so they hit the server’s upload and execution limits — a large site produces a package bigger than upload_max_filesize allows, or the import times out before finishing. Our guides on PHP upload max filesize and increasing max execution time cover raising those, but past a certain size the manual method is simply more reliable.
Worth knowing: if your host offers Softaculous (in DirectAdmin or cPanel), it can import an existing WordPress installation directly, which sidesteps the plugin’s PHP limits.
3. Manually
More steps, but nothing can time out and you see exactly what happened. This is the method worth understanding even if you never use it, because it’s what the other two are doing on your behalf.
The manual migration, step by step
Back up first. Files and database, stored somewhere that isn’t either server.
1. Export the database. In phpMyAdmin on the old host, select your WordPress database and use Export → Quick → SQL. You’ll get a .sql file.
2. Download the files. Everything in public_html (or wherever WordPress lives), including wp-config.php, .htaccess and the whole wp-content folder. Use FTP, the panel’s file manager, or — much faster for large sites — compress the folder over SSH and transfer the single archive. Our guide on SCP for directories covers the transfer commands.
3. Upload to the new host. Into public_html on the new server. If you moved a compressed archive, extract it there.
4. Create the database on the new host and note three things: the database name, the username and the password. Also check what the new host uses as the database host — usually localhost, but not always.
5. Import the SQL file into that new empty database, again via phpMyAdmin.
6. Edit wp-config.php with the new credentials:
define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_password' );
define( 'DB_HOST', 'localhost' );
This is the step that decides whether the site loads at all. Our guide on wp-config.php covers editing it safely — and if it’s wrong, you get the error described further down.
7. Check for hardcoded URLs in wp-config.php. Some setups define WP_HOME and WP_SITEURL there. If yours does and the domain is changing, update them; if the domain is staying, leave them alone.
The trap: never find-and-replace URLs in the SQL file
This is the single most damaging mistake in WordPress migrations, and it looks completely reasonable.
If you’re changing domain, the obvious move is to open the .sql file in a text editor and replace every olddomain.com with newdomain.com. Don’t.
WordPress stores some data — theme options, widget configurations, plugin settings — as serialized PHP arrays. In that format, every string is stored with its length declared in front of it:
s:21:"http://olddomain.com/"
↑ the string is 21 characters long
# After a naive find-and-replace:
s:21:"http://verynewdomain.com/"
↑ the string is now 25 characters, but still declares 21 — broken
PHP reads that length to know where the string ends. Change the text without changing the number and the whole serialized array becomes unreadable — so WordPress silently discards it. The symptom is theme settings, widgets and customiser options mysteriously reset to defaults, with no error message anywhere. And because it’s silent, people often don’t notice until weeks later.
The correct way is a tool that deserializes the data, replaces the string, recalculates the lengths and re-serializes. WP-CLI does exactly that:
# See what would change, without changing anything
wp search-replace 'olddomain.com' 'newdomain.com' --dry-run
# Then run it for real
wp search-replace 'olddomain.com' 'newdomain.com'
Our guide on WordPress and SSH covers connecting and using WP-CLI. If you don’t have SSH access, a reputable search-and-replace plugin does the same job through the dashboard — the requirement is that it handles serialization, which any purpose-built one does and a text editor never will.
Test before switching DNS
Don’t point the domain at the new server and then find out whether it works. Test first, privately, by overriding DNS on your own computer with the hosts file:
# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS / Linux: /etc/hosts
203.0.113.45 yourdomain.com
203.0.113.45 www.yourdomain.com
Then flush your DNS cache and load the site. Check the front end, log into /wp-admin, open a few internal pages, submit a form. Remove those lines when you’re done.
Only after that, switch the nameservers.
After the switch: five things to check
1. Re-save your permalinks. Go to Settings → Permalinks and click Save without changing anything. This regenerates the .htaccess rewrite rules on the new server. Skipping it is why “the homepage works but every other page is a 404” is the most common post-migration complaint.
2. Check HTTPS. Make sure the certificate is installed on the new host and that both Site URLs in Settings → General use https://. Our guide on redirecting HTTP to HTTPS covers enforcing it cleanly.
3. Clear every cache. The caching plugin, any server-side cache, and your CDN if you use one. Stale cache after a migration produces confusing half-broken pages. See clearing WordPress cache.
4. Check file permissions. A transfer can arrive with wrong ownership or permissions, which breaks uploads and updates. Our guide on WordPress file permissions has the correct values.
5. Confirm the PHP version. Match the old host’s version to start with, then upgrade deliberately afterwards — not during the migration.
If something breaks: symptom to cause
The good news about WordPress migrations is that the failures are predictable:
| Symptom | Almost always |
|---|---|
| “Error establishing a database connection” | Wrong credentials in wp-config.php, or the wrong DB_HOST — full guide |
| Homepage works, all other pages 404 | Permalinks not re-saved, or a missing .htaccess |
| White screen, no error | A plugin or PHP memory limit — white screen of death |
| Theme settings and widgets reset | Serialized data broken by a raw find-and-replace |
| Images missing, layout broken | Mixed content, or an incomplete wp-content transfer |
| Can’t log in to wp-admin | Cookies from the old server, or a hardcoded Site URL — login guide |
| “There has been a critical error” | A PHP fatal error — enable error logs to see it |
Whatever the symptom, the log tells you more than guessing does.
And the email
One thing this guide doesn’t cover, because it’s a separate job with its own timing: if your email is hosted at the same place as your site, it moves too — and it’s the part most likely to go wrong. Our guide on email migration covers the MX timing and the two-pass sync that stops messages going missing.
The honest shortcut
For most WordPress sites, let the host do it. Free migration is standard, they’ve done it hundreds of times, and they can adjust the destination server directly.
Do it yourself if the site is small enough to be quick, if you want to understand the mechanics, or if it’s complex enough that a standard process won’t fit. Either way, the checks after the switch — permalinks, HTTPS, cache, permissions — are worth running yourself regardless of who did the move.
Files, database, configuration and email. Copahost runs WordPress on LiteSpeed servers with NVMe storage, free SSL, one-click installs and support that answers — and we handle the migration from your current host at no cost.
See WordPress hosting plansFrequently asked questions
How do I transfer a WordPress site to a new host?
Copy the files to the new server’s public_html, export the database and import it into a new database there, then edit wp-config.php with the new database name, user, password and host. Test the site before changing DNS, switch the nameservers, and re-save your permalinks afterwards.
Do I need to change URLs in the database when migrating?
Only if the domain is changing. If you’re moving host and keeping the same domain, every URL in the database is already correct and needs no modification — which removes the riskiest step of the migration entirely.
Why shouldn’t I find and replace URLs in the SQL file?
Because WordPress stores theme options, widgets and plugin settings as serialized arrays, where each string is stored with its character length declared in front of it. Replacing the text without recalculating that length corrupts the array, and WordPress silently discards it — so settings reset with no error. Use wp search-replace or a plugin that handles serialization.
Will migrating WordPress affect my SEO?
Not if you keep the same domain and the same URL structure. Search engines see identical addresses serving identical content. SEO risk comes from changing the domain or permalinks, which requires a complete set of 301 redirects.
Why do all my pages show 404 after migrating?
The permalink rewrite rules haven’t been regenerated on the new server. Go to Settings, then Permalinks, and click Save without changing anything. That rewrites the .htaccess rules and the pages return.
Can I migrate WordPress with a plugin?
Yes, and it works well for small to medium sites. The limitation is size: plugin imports run through PHP and hit the server’s upload size and execution time limits, so very large sites either produce a package too big to upload or time out mid-import. Manual migration has no such limit.
How long does a WordPress migration take?
The transfer itself is typically 30 minutes to a couple of hours depending on site size. Add DNS propagation, which settles within hours for A records if you lowered the TTL in advance. Plan on the site being verifiably live on the new host the same day.
Conclusion
A WordPress migration is three files-and-database steps plus one configuration edit, and it’s much simpler than most guides suggest — because most guides assume you’re changing domain, and most people aren’t. Keep the same domain and there are no URLs to touch at all. Change it, and use a tool that understands serialized data rather than a text editor, or you’ll lose theme and widget settings without ever seeing an error. Test on the new server before switching DNS, re-save your permalinks afterwards, and check the log rather than guessing if something looks wrong. Or hand the whole thing to your new host, and spend your time on the verification instead.
Once the new site is confirmed working and you’re ready to decommission the old one, our guide on uninstalling WordPress from cPanel covers removing it cleanly.
