Move a WordPress site to a new host without downtime: back up, copy the files and database, test on the new server before DNS, replace URLs safely, switch DNS and protect WooCommerce orders.
To move a WordPress site to a new host without downtime, build a full copy on the new server while the old site stays live, test it privately, and only then point your domain at the new server. You can copy with a migration plugin, the new host's tool, or by hand. This guide covers the manual steps, the DNS timing and what a WooCommerce store needs, because orders keep arriving.
In short
wp-config.php. New domain: use WP-CLI search-replace, not a plain text replace.Move when the plan cannot meet a real need, such as old PHP versions, limits that cause errors, no backups or staging, a distant server or slow support. Do not move to cure a plugin error or a white screen: the new server would inherit the fault, and fixing common WordPress errors is quicker.
| Method | Good for | Watch out for |
|---|---|---|
| Migration plugin | Small and medium sites | Upload and time limits; vet the plugin as in our plugin guide |
| The new host's tool or service | Owners who want the host to copy the site | What it copies, and whether it can repeat the copy for a final sync |
| Manual move | Large sites, full control | More steps; needs file and database access, ideally SSH with WP-CLI |
A tool automates the copy, not the plan: the other steps still apply.
This follows WordPress's guide to moving WordPress for an unchanged address, where copying files and database is enough.
wp-content, wp-config.php and .htaccess, to the new server by SFTP or the host's tools.wp-config.php with the new DB_NAME, DB_USER, DB_PASSWORD and DB_HOST (usually localhost, not always). Keep $table_prefix identical to the imported tables..htaccess, and once the site loads, save Settings > Permalinks.With WP-CLI the database steps are two commands. The export runs mysqldump with the credentials in wp-config.php, so that tool must exist on the server.
# Old server: export the database to a file
wp db export before-move.sql
# New server, once the files and wp-config.php are in place
wp db import before-move.sqlBack up before you run anything
wp db import writes into the database named in wp-config.php. Point it at the new, empty database, never a live one, and keep an untouched backup of the old site.
The hosts file is a local map of names to IP addresses that your computer checks before DNS. Add a line with the new server's IP address and your domain, for example 203.0.113.10 example.com www.example.com (an example address), and only your computer reaches the new server. On Windows the file is in %SystemRoot%\System32\drivers\etc and needs administrator rights (Microsoft's documentation); on macOS and Linux it is /etc/hosts. Remove the line afterwards.
Test pages, media, forms, login and checkout in the payment provider's test mode. Expect a certificate warning if the new host has no certificate for your domain yet.
The copy holds live data and WordPress runs scheduled tasks when pages load, so emails or jobs can fire from it. Many owners add define( 'DISABLE_WP_CRON', true );, described in WordPress's wp-config documentation, to the copy and remove it before the switch. Action Scheduler can still start from admin requests, so keep sessions short.
If only the host changes, skip this section. If the domain changes, or you switch http and https or www and non-www, every stored URL must change. Much of it is PHP serialised data, which records each string's length, for example s:5:"hello";. A plain find-and-replace changes the text but not the length, so the value can no longer be read. WordPress's moving guide warns about this and recommends WP-CLI's search-replace, which handles serialised data.
# 1. Back up the database first
wp db export before-url-change.sql
# 2. Dry run: report only, save nothing
wp search-replace 'https://old-example.com' 'https://new-example.com' --all-tables-with-prefix --skip-columns=guid --dry-run
# 3. Run it for real
wp search-replace 'https://old-example.com' 'https://new-example.com' --all-tables-with-prefix --skip-columns=guid--skip-columns=guid follows WordPress's rule never to change the GUID column, and --all-tables-with-prefix includes unregistered plugin tables. --export=database.sql writes a converted file without touching the database. Repeat the dry run afterwards to see whether the old address remains.
A domain change also needs redirects: Google's site-move guide recommends server-side permanent redirects, generally kept for at least a year.
A certificate tied to the old server does not move with you, so ask the new host how and when it issues one. Let's Encrypt's challenge types differ: HTTP-01 needs your domain to reach the new server, so it may only succeed after the switch, while DNS-01 uses a TXT record.
MX records say where mail goes, so moving the site does not move mailboxes at the old host: copy them first or keep that mail service, and keep the MX, SPF and DKIM records unchanged. Changing nameservers moves every record, so recreate them all at the new DNS provider first; changing only the website's A record leaves mail alone.
www to the new IP address, removing any AAAA record if the new server has no IPv6.Your rollback is the old site: point the record back, which is fast with a low TTL. Agree in advance what triggers it, such as a failing checkout, and carry over any new orders.
Orders and customers live in the database, so an order placed on the old site after your final export is missing on the new one. Freeze, compare, or both.
Scheduled actions (WooCommerce > Status > Scheduled Actions) travel with the database, so check afterwards for failed or past-due ones; the speed guide explains them. Never run two live copies against one payment account, and if a provider accepts only listed IP addresses, add the new server's.
wp rewrite flush), then open posts and products.object-cache.php or advanced-cache.php in wp-content, check they suit the new one.DISABLE_WP_CRON unless the host runs a server-side task, and check wp cron event list.Visitors can keep using the old site until DNS changes, so there need not be a gap. Sites that take orders or comments still need a short freeze at the final copy, or a comparison.
It depends on the TTL and each resolver's cache. A lowered TTL shortens it, but some resolvers keep records longer, so keep the old site running.
No. With the same domain, copying the files and database and editing wp-config.php is enough.
It should not, if the URLs stay the same and the new site is complete, fast and reachable. Google says a short dip in crawling is normal.
Write your plan today: the TTL change, the backup, the database details and the window. If you have not chosen a host, start with how to choose WordPress hosting. Afterwards, follow the security checklist and browse WordPress plugins on DevMarket.
Fix the WordPress critical error and white screen of death calmly: back up, read the logs, find the cause by elimination, then handle database, 500, memory, maintenance mode, 404 and login errors.
9 min read
Choose a WordPress theme by testing, not by demo. Compare block and classic themes, sources, speed, accessibility, RTL support, WooCommerce, builder lock-in and licence terms on a staging copy.
9 min read
Use this WordPress maintenance checklist to plan weekly, monthly and yearly tasks: updates, backups, users, plugins, security, speed, PHP, domain and SSL, plus Site Health and WooCommerce checks.
9 min read
Every item on DevMarket has a human-reviewed release, an instant licence key and clear update and support terms.