Moving a WordPress site to a new host is one of those jobs that sounds risky and mostly is not, provided you do the steps in the right order. The risk is almost never in copying the files. It is in the cutover: the moment you change DNS and visitors start arriving somewhere new. Get that part wrong and you lose form submissions, orders and a chunk of goodwill.
This guide covers the whole job end to end. You will find the pre-flight checks worth doing first, the three genuine ways to move a site and when each is appropriate, a manual migration step by step, and an honest account of what tends to break afterwards. If you would rather not do any of it yourself, our engineers handle free migrations on every plan, and the last section explains why that path exists.
What “No Downtime” Actually Means
Almost every host advertises zero-downtime migration, and the phrase is doing a lot of work. It does not mean the internet pauses while your site changes address. It means the old site keeps serving right up until the new one is verified, and the switch between them is a DNS change rather than a gap.
Here is the sequence that makes that true. You copy the site to the new server while the old one carries on running untouched. You test the copy on a temporary address that only you can see. Only when you are satisfied do you point the domain at the new server. During propagation, some visitors resolve to the old host and some to the new one, and both are working, so nobody sees an error.
The failure mode people actually hit is different, and it is worth naming early: the two servers diverge. A visitor lands on the old site during propagation, submits a form or places an order, and that record is written to the old database, which you are about to abandon. For a brochure site this is a rounding error. For a store it is lost revenue. The WooCommerce section below deals with that directly.
Before You Move Anything
Half an hour of preparation removes most of what goes wrong later. None of this is difficult, but skipping it is how a two-hour job turns into a weekend.
Take a full backup you have actually tested
Back up files and database, download a copy off the server, and check the archive opens. A backup that lives only on the host you are leaving is not a backup, and one nobody has opened is a hypothesis. Our guide on cloning a website covers the mechanics if you want a full copy to work from rather than a compressed archive.
Write down the environment you are leaving
Note the PHP version, the WordPress version, the database version and any non-default server settings such as raised memory limits or a longer maximum execution time. Sites break after migration far more often because the new server runs a different PHP version than because a file failed to copy. If you are moving to a host that lets you switch PHP per site, match the old version first, then upgrade deliberately once the site is stable.
Inventory the things that are not in the database
A WordPress site is usually more than its files and tables. Email accounts on the domain, cron jobs, DNS records for subdomains, SSL certificates, redirects living in server config rather than a plugin, and any API keys tied to a server IP address are all easy to overlook. List them now while the old account is still open, because getting back in after cancellation is nobody’s favourite afternoon.
Lower your DNS TTL, at least a day ahead
This is the single most useful thing you can do in advance and the one most people skip. TTL, or time to live, tells resolvers how long to cache your DNS record. If it is set to 24 hours, some visitors will keep hitting the old server for a full day after you switch. Drop it to 300 seconds a day or two before the move and propagation shrinks from a day to a few minutes. Put it back afterwards.
Freeze changes
Stop publishing, stop plugin updates, stop editing. Any change made on the old site after you take your copy is a change you will have to make again by hand. Tell whoever else has an author login too.
The Three Ways To Migrate WordPress
There are three real options. They differ in how much control you have and how much can go wrong quietly.
1. Let the new host do it
Most managed hosts will move the site for you, and the good ones do it by hand rather than by script. You hand over your existing control panel login and they take it from there, usually giving you a staging URL to sign off before anything changes. This is the least risky option and it is normally free, so if it is available it is hard to argue for doing it yourself. It is worth checking whether “free migration” means one site or all of them, and whether an engineer or a plugin is doing the work. Every FastCow plan includes migrations done by our team, at any number of sites.
2. A migration plugin
Plugins such as Duplicator or All-in-One WP Migration package the site into a single archive you restore on the new server. For a small site this is genuinely quick and there is little to think about.
The limits show up as the site grows. Large sites hit upload limits and PHP timeouts partway through, and a half-finished import is worse than none. Free tiers often cap archive size. And a plugin cannot tell you that your new server runs an older PHP version, so it will happily restore a site that then throws a fatal error. Use one for a modest site, be sceptical past a couple of gigabytes.
3. Manually, by hand
Copy the files, export the database, import it, edit the config. It sounds harder than it is, and it is the only method with no size limit, no timeout and no black box. If you have shell access, WP-CLI makes it considerably faster. The next section walks through it.
How To Migrate WordPress Manually
Ten steps. Do them in order, and do not touch DNS until step eight.
Step 1: Copy the files
Connect to the old host over SFTP or SSH and take everything in the WordPress root: wp-content, wp-admin, wp-includes, and the loose files including wp-config.php and any .htaccess. Do not skip the hidden dotfiles, which is a default in some FTP clients and a common cause of missing redirects.
If both hosts give you SSH, compressing first is dramatically faster than transferring thousands of small files: tar -czf site.tar.gz . then move the single archive. A site with a large media library can contain tens of thousands of files, and per-file overhead dominates.
Step 2: Export the database
From phpMyAdmin, choose your database, select Export, and take a full SQL dump. From the command line, mysqldump -u user -p dbname > backup.sql does the same and copes better with large tables. If the export stalls in phpMyAdmin, the database is too big for it and the command line is your answer.
Step 3: Create the database on the new host
Make a new database, a new user, and grant that user full permissions on it. Keep the credentials to hand. There is no benefit to reusing the old names, and a fresh user with a strong password is a small security win while you are here.
Step 4: Import the database
Import the SQL file into the new empty database, either through phpMyAdmin or with mysql -u user -p dbname < backup.sql. Watch for errors rather than assuming success. A truncated import usually shows up as a partially populated wp_posts table, which you will not notice until content is missing.
Step 5: Upload the files
Put the files into the new server’s web root, which is commonly public_html or httpdocs. If you compressed in step one, extract in place. Check that file ownership and permissions came across sensibly: directories at 755 and files at 644 is the normal arrangement, and anything set to 777 should be corrected rather than copied.
Step 6: Update wp-config.php
Edit wp-config.php on the new server with the new database name, user and password. The host is usually localhost but not always, so check your host’s documentation. While the file is open, confirm the table prefix matches what you imported, because a mismatched $table_prefix produces a site that looks like a fresh install and sends people into a panic.
Step 7: Test on a temporary URL
Do not point DNS yet. Most hosts give you a temporary address or a staging domain; use it. If yours does not, edit your local hosts file to resolve your domain to the new server’s IP for your machine only. That is the better test anyway, because the site loads under its real domain name, which means links, cookies and SSL behave as they will in production.
Click through properly. Load the homepage, a post, a category archive, a page with a form, and the admin. Check images render rather than 404. Log in. Run a search. If anything looks wrong, fix it now while the live site is still safely on the old host.
Step 8: Lower the TTL and prepare the DNS records
If you did not reduce TTL earlier, do it now and wait for the old value to expire before continuing. Have the new A record, and any AAAA, MX or CNAME records, written down and ready so the change itself takes seconds rather than minutes of hunting.
Step 9: Point the domain
Update the A record to the new server’s IP address. If you use a CDN or a DNS proxy, change it there rather than at the registrar. Leave the old hosting account active and paid for at least a week: it costs very little and it is your rollback.
Step 10: Issue SSL and verify
Once DNS resolves to the new server, issue the certificate. Most hosts do this automatically through Let’s Encrypt within a few minutes. Load the site over HTTPS, confirm the padlock, and check that HTTP redirects to HTTPS. If you are unclear on what the certificate is actually doing, we have a primer on SSL certificates.
Managed Hosting solutions for WordPress backed by Speed, Security and Scalability
Talk To Sales →The DNS Cutover, Explained Properly
This is where most migrations go wrong, and it is worth understanding rather than following blindly.
DNS is a distributed cache. When you change a record, nothing is pushed anywhere. Resolvers around the world simply stop using their cached copy when its TTL expires and fetch the new one. That is why propagation is not a progress bar: different networks update at different moments, entirely depending on when they last asked.
The practical consequence is that for a window after the change, your site exists in two places at once and both are live. Neither is broken. The question is only whether they are diverging. A read-only site can sit in that state for a day without harm. A site taking orders, comments or form submissions cannot, because half of them are landing in a database you are about to throw away.
Three things keep that window short. Lower the TTL in advance, which is the big one. Change the record at the authoritative source rather than an intermediate. And keep the old server running so that anyone still resolving there gets a working site rather than a connection error. If DNS misbehaves afterwards, our walkthrough of DNS server not responding errors covers the usual causes.
What Usually Breaks, And How To Fix It
These are the problems that show up again and again after a migration. None is serious if you know to look for it.
Hardcoded URLs in the database
If the domain changed as well as the host, the old URL will be scattered through post content, widget settings and options. Do not fix this with a plain SQL find and replace, because WordPress stores some settings as serialised PHP and a naive replacement corrupts the string lengths, silently breaking widgets and theme options. Use WP-CLI’s wp search-replace or a plugin built for the job, both of which unserialise properly.
Broken permalinks and 404s on every page except the homepage
The classic symptom of a missing or unread .htaccess. Log in, go to Settings then Permalinks, and click Save without changing anything, which regenerates the rules. On nginx there is no .htaccess at all and the rewrite rules live in the server config, so this is one to raise with your host.
Mixed content warnings
The page loads over HTTPS but assets are still requested over HTTP, so the padlock disappears. This is almost always leftover absolute URLs in content. The same search-replace that fixes hardcoded domains fixes this, running from http://yourdomain to https://yourdomain.
Missing images
If the media library shows entries but the files 404, the uploads folder did not copy completely, which is common when a transfer is interrupted. Re-transfer wp-content/uploads on its own and compare file counts rather than trusting the client’s summary.
Email stops working
Two separate causes get confused here. If your email was hosted with your old web host, changing the A record does not move it, but changing nameservers does, and MX records that were not recreated will take mail down. Separately, PHP mail from contact forms often fails on a new server because it is not configured or is blocked as spam. Sending through an authenticated SMTP service rather than PHP mail is the durable fix, and worth doing regardless.
A fatal error on a PHP version mismatch
An older theme or plugin that ran on PHP 7.4 can throw a fatal error on PHP 8.2. This is why step one includes noting the old version. Match it, confirm the site is stable, then move up a version at a time and test in staging rather than on production.
Caching and CDN confusion
Old caching plugins frequently hold server paths that no longer exist. Deactivate the caching plugin before you migrate and reconfigure it afterwards rather than carrying the config across. If you use a CDN, purge it after the cutover, otherwise you will spend an hour debugging a page that was fixed twenty minutes ago. Our piece on how a CDN affects WordPress performance explains what it should be doing once settled.
Migrating A WooCommerce Store
A store raises the stakes because orders arrive continuously and each one is money. The techniques are the same, the sequencing is stricter.
The problem is the divergence window described earlier. An order placed on the old server after you took your database copy exists only there. Copy the database again at cutover and you overwrite anything that happened on the new one; do not, and you lose the order.
There are two workable approaches. The simpler is a short maintenance window at your quietest hour: put the store into maintenance mode, take a final database export, import it, switch DNS, and open again. With a low TTL that is usually fifteen to thirty minutes of not accepting orders, which for most stores is cheaper than reconciling by hand.
The alternative, if closing is not acceptable, is to migrate first, keep both live during propagation, then export only the orders and customers created on the old server in that window and import them. That is more work and needs care over ID collisions, but nothing is refused.
Whichever you choose, test the checkout on the new server before switching, with a real transaction in your gateway’s test mode. Payment gateways sometimes tie API keys or webhooks to a domain or IP, and a webhook that silently fails means orders that are paid for but never marked as paid. Check the gateway’s webhook log after go-live rather than assuming.
The Post-Migration Checklist
Work through this once the domain resolves to the new server.
- Load the homepage, a post, a page, a category archive and the admin over HTTPS
- Confirm the padlock and that HTTP redirects to HTTPS
- Submit a contact form and confirm the email arrives
- Place a test order if you run a store, and check the gateway webhook fired
- Check the media library renders and upload a new image
- Re-save permalinks and click through to a few deep URLs
- Confirm scheduled posts and any cron-driven jobs still run
- Re-enable and reconfigure caching, then purge the CDN
- Point monitoring and analytics at the new server, and check Google Search Console for a crawl error spike
- Restore your DNS TTL to its normal value
- Take a fresh backup on the new host so you have a clean restore point
- Leave the old account running for a week, then cancel
Once things have settled, it is worth running through a maintenance checklist so the new environment starts in good order rather than inheriting the old one’s neglect.
One last note on expectations. A migration is a good moment to notice you were on the wrong plan, not just the wrong host. If the old site was slow because it was starved of resources, moving it unchanged to another cheap plan reproduces the problem faithfully. It is worth reading the difference between managed and shared hosting before you choose where it lands, and if speed was the reason you are moving, what site speed does to revenue is the case for spending slightly more.
And if none of the above appeals, that is a legitimate answer. Managed WordPress hosting exists partly so this job is somebody else’s. Our engineers do the move by hand, hand you a preview URL, and only change DNS once you have signed it off, free on every plan from $25 a month. US sites can read more about where we host in the USA.