How to move WordPress to a new server or host with zero downtime, including the domain change, URL update, and DNS cutover done in the right order.
Moving WordPress to a new server, the right way
One rule carries a clean host move. Copy everything to the new host first, test it on a temporary URL, and only change DNS once the new site is verified working. Do it in that order and your visitors never see downtime. They keep hitting the old host until the new one is proven.
I have run host moves across a wide range of scale. Single small-business sites on one end. On the other, Sportsnet.ca, a high-traffic sports news site with hundreds of articles, where I came in for the final stages as Lead Developer and the cutover could not afford a wobble. I have also worked on moving the 13+ newspaper blogs across the National Post and Postmedia network onto WordPress VIP, which taught me that scale mostly multiplies the redirect surface. The safe sequence never changed at any size. You transfer the files and the database, update wp-config.php, handle any domain change and the URL update that comes with it, point DNS at the new server, then verify the result. Leaving a slow host or changing host and domain at the same time, the steps below hold up either way.
Prefer a hands-off move? A managed WordPress Migration handles the transfer, the URL update, redirects, and DNS cutover for you. To baseline your current site before moving, run a free pre-migration audit.
What you need before you start
Pull these together before you touch anything. Having them on hand turns a stressful move into a checklist you tick off.
- Access to the old host. FTP/SFTP credentials and database access (phpMyAdmin or similar).
- Access to the new host. FTP/SFTP, the ability to create a database and user, and a temporary URL or hosts-file method to preview.
- A full backup. All files plus a database export. This is your rollback.
- Your domain registrar login. You will change nameservers or DNS records at cutover.
- Matching PHP version. Confirm the new host runs a PHP version your theme and plugins support, to avoid a 500 error on arrival.
If you would rather move without a plugin and control every step yourself, the manual WordPress migration guide covers the file-and-database approach in depth. If you want a plugin to package the whole site, compare the best WordPress migration plugins first.
Move WordPress to a new server, step by step
Here is the full sequence, start to finish. Each step lines up with the structured how-to steps further down, so follow whichever format you like.
1. Back up the current site
Export the database from the old host (via phpMyAdmin or your panel) and download the entire site directory over FTP, including wp-content, wp-config.php, and .htaccess. Confirm the database .sql file and file archive are complete before continuing.
2. Create the database on the new host
In the new host’s control panel, create a new database, create a database user, and assign that user to the database with full privileges. Note the database name, user, password, and the host value (often localhost, sometimes 127.0.0.1 or a dedicated hostname).
3. Upload the files
Connect to the new host over FTP and upload your WordPress files, typically into public_html if this is the primary site. Let every file finish. Partial uploads cause errors that are miserable to trace later.
4. Import the database
Open phpMyAdmin on the new host, select the new (empty) database, and import your .sql file. Make sure the format is SQL and the partial-import option is unchecked.
5. Update wp-config.php
Edit wp-config.php on the new host so DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST match the database you just created. Change only the values inside the quotes.
6. Update the URLs (if the domain changed)
If the domain is changing, update the stored URLs. For a simple change, set both fields in Settings → General, or override them in wp-config.php. For a thorough update that also fixes content, images, and serialized data, run a search-and-replace, covered in the next section.
7. Test on a temporary URL
Before changing DNS, preview the site on the new host using a temporary URL or by editing your local hosts file to point the domain at the new server’s IP. Click through key pages, check images, test forms and checkout.
8. Cut over DNS
Once verified, update your domain’s DNS (nameservers or A record) to point at the new host. Lower the TTL a day ahead so the change propagates fast.
9. Flush permalinks and clear caches
On the new live site, go to Settings → Permalinks → Save Changes to regenerate rewrite rules, then clear all caches. This prevents the classic post-move 404s.
Handling the domain change and URL update
Change the domain and every URL stored in the database has to change with it, or you get redirect loops, broken images, and dead internal links. Those URLs hide in posts, settings, menus, and serialized plugin data. A two-field change in Settings will not cover a real domain move.
Here is the part most guides skip past. If you are only switching servers and keeping the same domain, replicate the URLs exactly so every page stays at its old address. Do that and the move is invisible to Google. Nothing moved, so SEO barely feels it. The URLs are the thing I guard hardest. The hardest migration I have done was the Scattergood Foundation, a legacy CMS rebuilt on WordPress, and the part that ate the most hours was not the content. It was the redirects. Hundreds of legacy article URLs, every one mapped to its new home, and the structure underneath them was a deep many-to-many taxonomy where a single publication belonged to a fistful of categories at once. The content move itself is usually the easy half. Preserving the years of accumulated SEO value bolted to those URLs is the hard half, and a sloppy move bleeds rankings there without ever throwing an error.
The official URL settings
The official WordPress documentation spells out two fields under Settings → General. Site Address (URL) is where visitors reach your site. WordPress Address (URL) is where the core files live. Both want https:// and no trailing slash. WordPress also documents a RELOCATE method. Add define( 'RELOCATE', true ); to wp-config.php, hit wp-login.php on the new server to auto-update the Site URL, then strip the line out. Leaving it in is a security hole.
The thorough fix is a search-and-replace
For a real domain change, run a database search-and-replace that swaps old domain for new everywhere, serialized data and all. A raw SQL update corrupts that serialized data quietly. WordPress’s own WP-CLI tool unserializes, replaces, then re-serializes the safe way.
wp search-replace 'https://olddomain.com' 'https://newdomain.com' --skip-columns=guid --precise --dry-runPer the WP-CLI documentation, --dry-run reports what would change without touching anything, and --skip-columns=guid leaves the GUID column alone (rewrite it and you break feed-reader identity). Read the dry-run, then run it again without --dry-run. The full database walkthrough, phpMyAdmin alternative included, lives in the manual migration guide.
How to move with zero downtime
Downtime during a host move is optional, not inevitable. The trick is DNS timing and testing before cutover. Those two habits are the only reason a high-traffic site like Sportsnet.ca can change servers without a reader noticing. When thousands of people are reading articles while you are mid-cutover, you do not get to wing it. You lower the TTL, you test on a temporary URL until you are bored of clicking, and you flip DNS knowing exactly what they will land on.
Lower TTL in advance
Drop your DNS record’s TTL (time to live) to 300 seconds a day ahead of the move. Change DNS at cutover and the new value then propagates in minutes, not hours. I lower the TTL the day before every single cutover. Cheapest insurance in the whole process.
Test before you switch
Verify the new server works before DNS ever points to it. Use the host’s temporary URL, or add a line to your computer’s hosts file that maps the domain to the new server’s IP so only you see the new site. Then click through everything that matters. Homepage. Key pages. Images, forms, checkout. I run this pass myself on the hosts-file copy before a single visitor gets routed over. The only safe time to find a broken page is while you are still the only one looking at it.
Freeze content during the cutover
Between exporting the database and going live, avoid publishing posts, approving comments, or taking orders on the old site. Those changes live only in the old database and will be lost. For busy sites, schedule the cutover for a low-traffic window and keep the freeze short.
Keep the old host running
Do not cancel the old hosting immediately. Keep it live for a week or two after cutover so any visitors still hitting the old IP during DNS propagation see a working site, and so you have a rollback if something surfaces.
Verify the move and fix common issues
Run a short verification pass the moment DNS flips. Almost every post-move problem lands somewhere in the table below, and each row points to the detailed fix.
| Symptom after cutover | Likely cause | Fix |
|---|---|---|
| Database connection error | Wrong DB credentials in wp-config.php | Match all four DB values to the new host; grant the user access |
| Posts and pages 404 | Rewrite rules did not transfer | Settings → Permalinks → Save Changes |
| Too many redirects | Site URL mismatch or forced HTTPS | Set WP_HOME and WP_SITEURL; align SSL settings |
| Images broken | Old domain URLs in the database | Run a serialized-safe search-and-replace |
| 500 error | PHP version or memory mismatch | Match PHP version; raise memory; check error log |
Hit any of these and the WordPress migration errors guide carries the full cause-and-fix for each one. After that, confirm SSL is valid on the new host, resubmit your sitemap in Google Search Console if the domain changed, and put 301 redirects in place from old URLs to new. When the URL structure cannot stay put, this is where the slow, finicky work lives. On the Postmedia network, each newspaper had grown up on different legacy software, so the old URL patterns were inconsistent from one publication to the next, and reconciling them was a job with no shortcut. I map every old address to its new home before launch, then I walk the redirects one at a time and actually request each one to confirm it resolves. It is tedious. There is no clever way around checking that a 301 fires and lands where you meant. Visitors and search engines both have to arrive in the right place, and a single broken redirect in a map of hundreds is how you quietly lose the rankings the whole move was meant to protect.
A calm, ordered host move
Respect the order and none of this is hard. Back up. Copy the files. Create and import the database, update wp-config.php, fix the URLs for any domain change, test on a temporary URL, then cut over DNS dead last. Skip the testing or flip DNS too early and a calm migration turns into a stressful one fast. For SEO, the single best move is keeping the URLs identical wherever the host lets you.
If the site is mission-critical, or you are changing host and domain at the same time, a managed WordPress Migration takes on the transfer, the URL search-and-replace, redirect mapping, and a zero-downtime DNS cutover, with post-launch QA so nothing reaches your visitors broken. Start with a free pre-migration audit, or read the full WordPress migration guide for the bigger picture.
Frequently asked questions
How do I migrate WordPress to a new server without downtime?
Copy every file and the database to the new host first. Test on a temporary URL. Only then change DNS, once the new site is verified working. Lower your DNS TTL a day ahead so the cutover propagates in minutes, and keep the old host running for a week as a fallback.
What do I change in wp-config.php when moving hosts?
Four values. DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST, all matched to the database you created on the new host. DB_HOST is usually localhost, though it can be 127.0.0.1 or a dedicated hostname. Touch only what sits inside the quotes.
How do I change the WordPress URL after migrating to a new domain?
Set both the WordPress Address and Site Address under Settings → General, or define WP_HOME and WP_SITEURL in wp-config.php. A full domain change needs more than that. Run a serialized-safe search-and-replace so URLs buried in posts, menus, and plugin data get updated too.
Do I need to update DNS to move WordPress to a new host?
Yes, whenever you change servers. Once the new site is tested and working, point your domain’s nameservers or A record at the new host. While DNS propagates, some visitors hit the old server and some hit the new one, depending on where they are.
How long does a WordPress host migration take?
For a typical small site, the file and database transfer runs under an hour. DNS propagation adds anywhere from minutes to a few hours, set by your TTL. Large sites and e-commerce stores take longer. Bigger databases, and a lot more to test before you trust the move.
Will I lose SEO when I move WordPress to a new host?
Not if the URLs stay the same and the site never goes down. Change the domain and it is a different story. Put 301 redirects in place from old URLs to new, then resubmit your sitemap in Google Search Console to hold onto your rankings.