Key takeaways
- **Move WordPress Site to New Host:** Use this guide to decide what to fix first, what can wait, and how the work should support more trust, stronger mentions, and better visibility.
Migrating a WordPress site to a new host takes four steps: back up files and the database, upload them to the new server, point DNS after testing on a temporary URL, and verify every page before you cut over. Done in that order, visitors see zero downtime because the old host keeps serving traffic until the new one is proven.
Most migrations that break do so because someone changed DNS first and tested second. Reverse that. This guide walks the full move for a standard WordPress install. If you would rather have it handled for you, our website migration service team can run the move.
Why hosts get changed in the first place
Owners rarely move for fun. The trigger is almost always one of four things. Speed: the current server takes 3 or more seconds to return the first byte, and page speed drags rankings and conversions down with it. Cost: a renewal price doubles at the end of an introductory term. Support: a ticket sits unanswered for 48 hours while the site is down. Or resource limits: the plan caps PHP memory at 128 MB and a growing plugin stack keeps hitting the ceiling.
Whatever the reason, the move itself is mechanical. The site does not change. Every file and every database row lands on the new server exactly as it left the old one. What changes is the machine underneath. That is why a clean migration is invisible to visitors: same content, same URLs, faster hardware.
Before you start, confirm the new host meets three minimums. It should run the same PHP major version as the old host or newer, offer SFTP and phpMyAdmin access, and let you preview the site on a temporary URL. Miss any of those and the move gets harder than it needs to be.
Step 1: Take a full backup before touching anything
A WordPress site is two parts: the files (themes, plugins, uploads, core) and the MySQL database (posts, settings, users). You need both.
- Files live in the site root, usually a folder like public_html. The wp-content directory holds everything custom.
- The database is exported as a .sql file through phpMyAdmin or a plugin.
Pull both to your local machine before you start. A 5 GB media library and a 400 MB database is a common size for a business site with 2 years of content. If your files exceed 2 GB, compress wp-content in chunks so the download does not time out.
Keep one backup untouched. If the migration goes sideways, that copy restores the original in under 30 minutes. Label it with the date and never edit it. A second working copy is the one you upload and change.
Write down your current PHP version, MySQL version, and the list of active plugins before you move. If the new site misbehaves, the first question is always what differs between the two servers. Having the old numbers on paper saves an hour of guessing.
Step 2: Set up the new host and upload
Create an empty database on the new host and note the database name, user, and password. You will need these three values for wp-config.php.
Upload in this order:
- Files to the site root via SFTP or the host file manager. A 5 GB upload over a stable connection takes 20 to 40 minutes.
- Import the .sql file into the new empty database through phpMyAdmin.
- Edit wp-config.php with the new database name, user, password, and host (often localhost).
If the site uses a caching plugin, clear its config folder after upload. Stale cache paths pointing at the old server cause white screens more often than any other single issue.
Watch the phpMyAdmin import size limit. Many hosts cap uploads at 50 MB, and a 400 MB database will not import through the browser. When that happens, split the .sql file or use the command line import if your host allows SSH. A database that imports halfway leaves you with missing posts and no error, so confirm the row counts match the old site after import.
Set file permissions after the transfer. Folders should be 755 and files 644. SFTP sometimes resets these during upload, and wrong permissions block WordPress from writing uploads or updating plugins.
Step 3: Test on a temporary URL before DNS
This is the step that protects your uptime. Do not change DNS yet.
Most hosts give you a temporary URL or a preview link that resolves to the new server. If not, edit your local hosts file to map the domain to the new server IP. That lets your browser see the new site while the rest of the world still sees the old one.
Check these before you trust the new copy:
- Homepage and 5 to 10 deep pages load without error.
- Images and downloads resolve, not broken links.
- Contact forms submit and the test message arrives.
- Admin login works and the plugin list matches.
- Checkout completes a test order if the site sells anything.
Fix problems here, where only you can see them. A broken plugin found on a preview URL costs nothing. Found after DNS cutover, it costs sales.
Test on a phone as well as a desktop. Responsive layouts sometimes pull assets from a path that only breaks on mobile, and you want to catch that before visitors do. Run one page through a speed test too, so you have a baseline number to compare against the old host.
Step 4: Lower TTL, then change DNS
Two days before cutover, lower your domain's DNS TTL to 300 seconds. TTL controls how long resolvers cache the old record. A default TTL of 86400 seconds means some visitors keep hitting the old host for a full day after you switch. Dropping it to 300 shrinks that window to 5 minutes.
When testing passes, update the A record (or the host records at your registrar) to the new server IP. Propagation with a 300 second TTL completes for most visitors inside 15 minutes and worldwide within an hour.
Leave the old host running for 48 hours. Traffic drains from old to new gradually, and any visitor cached on the old record still gets a working site.
Pick a low-traffic window for the switch. For most business sites that is early morning or a weekend, when a stray issue affects the fewest people. Have your backup ready during this window so you can revert the DNS record if something serious surfaces.
Step 5: Verify and issue SSL
Once DNS resolves to the new host:
- Confirm HTTPS works and the padlock shows. Reissue the SSL certificate on the new host if it did not migrate.
- Force HTTPS in the host panel or via a redirect so no page loads on plain HTTP.
- Submit the site to a crawl and check for 404s or mixed-content warnings.
- Watch the new server error log for 24 hours.
Update any hardcoded URLs in the database that still point at a staging or temporary domain. A search-and-replace tool that handles serialized data does this safely; a raw SQL find-and-replace can corrupt serialized plugin settings.
Handling email and DNS records you did not move
The most common post-migration surprise is broken email. Website migration moves the site, not your mailboxes, unless email happens to run on the same server. Before you touch DNS, record every existing record: MX for mail, TXT for SPF and DKIM, and any CNAME records for tools like your CRM or verification services. Recreate them on the new DNS or leave them pointed where they were.
If you only change the A record and leave the MX records alone, email keeps flowing to its current provider without interruption. Trouble starts when a migration copies the whole DNS zone to a new provider and drops records that were never part of the website. Compare the old zone file against the new one line by line, and confirm mail still arrives with a test message before you consider the move finished.
Common problems and fixes
| Symptom | Cause | Fix |
|---|---|---|
| White screen after upload | Wrong database credentials in wp-config.php | Recheck name, user, password, host |
| Broken images | URLs point to old domain | Run serialized search-and-replace |
| Login redirect loop | Cached siteurl mismatch | Set siteurl and home in database |
| Mixed content warning | HTTP asset on HTTPS page | Force HTTPS, update asset URLs |
| Slow first load | Cache not rebuilt | Clear and regenerate cache |
| Missing recent posts | Database imported partway | Reimport and confirm row counts |
| Email stops arriving | MX records changed with the move | Restore original MX records |
Related terms
You may see this topic described with related searches like change web host, how to change hosting provider, how to migrate a website, how to migrate wordpress site to new host, and how to move a website to a new host. Those phrases are useful when they clarify what the reader needs next, but they should still point back to one clear plan.
Related searches such as how to move a wordpress site, migrate wordpress site, migrate wordpress to new host, move website to new host, and transfer web hosting are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Related searches such as wordpress transfer are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Frequently asked questions
How long does a WordPress migration take?
A standard business site moves in 2 to 4 hours of hands-on work, spread across a day to allow DNS propagation. Sites over 20 GB or with complex plugin stacks take longer because uploads and database imports run longer.
Will my site go down during migration?
No, if you test on a temporary URL and only change DNS after the new copy is verified. The old host keeps serving visitors the entire time. Downtime happens when people switch DNS before testing.
Do I need a plugin to migrate WordPress?
No. Manual migration through SFTP and phpMyAdmin works for any site and gives you full control. Migration plugins speed up smaller sites but often hit limits on large media libraries or restricted hosts.
What happens to my email during the move?
Website migration moves the site, not email, unless email runs on the same server. Check your MX records before changing DNS. If email uses a separate provider, leave the MX records untouched.
Will migrating hurt my search rankings?
No. Moving to a new host keeps every URL the same, so search engines see no change in structure. Rankings can actually improve if the new host is faster, since page speed is a ranking factor. Rankings only suffer when URLs change, which is a domain move, not a host move.
Should I migrate during business hours?
No. Change DNS in a low-traffic window, usually early morning or a weekend, so any stray issue reaches the fewest visitors. Do the backup and upload work whenever suits you, since those steps do not affect the live site.
Can I host my WordPress site on GoDaddy?
Yes, GoDaddy can host a WordPress site, but fit depends on traffic, plugin load, staging needs, backups, and support expectations. For a business-critical site, judge hosting by speed, reliability, restore process, and support quality.
Where should I host my WordPress site?
Choose the option that matches the job. If the decision affects traffic, leads, revenue, or trust, treat it as a question of risk and measurable outcome instead of a preference call.
Where can I host a WordPress site for free?
Free WordPress hosting exists, but it is rarely a good fit for a business site because speed, support, backups, and control are limited. Use free hosting only for testing or a temporary project, not for a site that needs to rank or convert.
Where can I host my WordPress site for free?
Free WordPress hosting exists, but it is rarely a good fit for a business site because speed, support, backups, and control are limited. Use free hosting only for testing or a temporary project, not for a site that needs to rank or convert.
What is the cheapest way to host a WordPress site?
In this guide, what is the cheapest way to host a wordpress site points back to the practical work behind move WordPress site to new host: what matters, what changes first, and how the result should be measured.
Where to go next
Test changes safely before any move with a WordPress staging site. If you are also changing addresses, our website migration service team can protect the move.
If you would rather hand the whole move off, our website migration service team runs the backup, transfer, testing, and cutover so you keep your uptime and your rankings.