On Tuesday, April 9, 2024, between 8:00 and 11:00 UTC, WooCommerce.com left the Woo.com domain and returned to its original address. One hundred and sixty-one days earlier, the company behind WooCommerce had abandoned its historic domain, then found that its users were finding it less easily in Google. The release of its own version 8.8, scheduled for that day, had been pushed back so it could test calmly after the switch.
That episode is a reminder that a migration is not won in the tool that copies the files. It is won in the schedule: when to lower the DNS records’ time to live, when to freeze orders, when to switch, and how to roll back if something breaks.
This guide is a complete runbook, from seven days before the switch to two weeks after. It separates two operations that have nothing in common: changing host while keeping the same address, and changing domain. Every command was checked against the official documentation, and the examples use the addresses reserved for documentation, example.com and 203.0.113.10.
What “without downtime” really means
Two clocks: DNS caches and writes
A migration without downtime has to watch two clocks at once. The first is the DNS cache clock: for a while, some visitors still reach the old server, others already the new one. The second is the write clock: an order, a comment or a sign-up received on the old server after the final database copy is lost, or has to be reconciled by hand.
The first risk is handled by preparing DNS ahead of time, the second by freezing writes during a short window. A migration plugin handles neither.
Changing host or changing domain
The most common case is a host change at the same address. It needs no URL replacement in the database and no change of address declared to Google: the risk is concentrated on DNS, writes and the new server’s configuration.
Changing domain is a different operation, with a real SEO risk: URL replacement in the database, permanent redirects, a declaration in Search Console. This guide’s real case illustrates it. Each step below states which operation it applies to.
Step 1: the inventory, before touching anything
What WordPress already knows
The Site Health screen, Info tab, under Tools, gathers the essentials: WordPress version, site addresses, database and folder sizes, active and inactive plugins, PHP version and server limits, wp-config.php constants. A button copies everything to the clipboard: keep that snapshot, it will be used to compare the old and new servers.
On the command line, a few commands give the same picture, as our selection of essential WP-CLI commands explains.
wp core version
wp plugin list
wp db size
wp option get home
wp option get siteurl
wp cron event listWhat WordPress does not see
The inventory must also cover what lives around WordPress: the whole DNS zone, with A, AAAA, MX and TXT records for email authentication, CAA records that restrict certificate authorities, and DNSSEC signing if it is enabled. Add the server’s scheduled tasks, the web server rules, PHP extensions, the object cache, the CDN, the outgoing email path and the IP allowlists at your payment providers.
A frequent trap: if the old server also answers over IPv6 and only the A record is changed, IPv6 visitors keep reaching the old server. Change the AAAA record at the same time, or remove it.
Step 2: lower the DNS TTL a week ahead
What TTL promises, and what it does not
The TTL, or time to live, tells an intermediate DNS server how long it may cache an answer. RFC 2181 puts it plainly: “The TTL specifies a maximum time to live, not a mandatory time to live.” Some resolvers enforce a minimum of a few tens of seconds, others cap long durations: Google Public DNS generally limits its own to six hours.
“DNS propagation takes 24 to 48 hours” is therefore not a law: a change reaches visitors as caches expire. With a TTL that is already low, most switch within minutes.
How far ahead
Lowering the TTL on the day of the switch is useless: caches keep the old value, sometimes 24 hours, until it expires. It has to be lowered at least one old-TTL period before the switch. For a host change, Google recommends moving to a value of a few hours at least a week ahead. A value of 300 seconds, set seven days before, leaves a good margin.
Once the migration is confirmed, raise the TTL back to a normal value. If you also change DNS provider, do not delete the old zone and keep it updated with the new values: RFC 8767 allows a resolver to serve expired answers, the old address included, if the authoritative server stops responding, and suggests a cap of seven days.
Changing DNS servers: a different schedule
If you are also changing DNS provider, the delegation lives in the parent zone, with its own TTL. A query against the .com servers shows it.
dig +norec NS example.com @a.gtld-servers.netFor a .com, that TTL is two days, and the registry sets it, so you cannot lower it. AWS documentation recommends lowering the TTL of the NS records at both the old and the new provider, then waiting two days before changing name servers.
If DNSSEC is on, remove the DS record at the start of that wait: according to AWS, signing cannot be active at two providers at once, and a .com DS record can stay cached for a day. If you can, do not combine a host change and a DNS provider change on the same day.
Behind a CDN
If your domain goes through a proxy such as Cloudflare’s, visitors receive the CDN’s addresses, not your server’s. The switch then means changing the origin in the CDN, and no longer depends on visitors’ DNS caches: that is the most comfortable situation.
Step 3: copy files with rsync, in two passes
The first pass happens a few days ahead, without pressure, to copy most of the volume.
rsync -az --info=progress2 -e ssh /var/www/example.com/ deploy@203.0.113.10:/var/www/example.com/The trailing slash on the source matters: it means “copy the contents of this directory”. The -a option preserves permissions, dates and links, but not access control lists, extended attributes or hard links, which require -A, -X and -H.
The second pass happens during the freeze, deleting files that disappeared at the source. The rsync documentation warns that --delete is dangerous if used incorrectly: first do a dry run that lists the changes.
rsync -az --delete -n -i -e ssh /var/www/example.com/ deploy@203.0.113.10:/var/www/example.com/Then run it again without -n. Thanks to the quick check on size and date, only files changed since the first pass are copied. Exclude cache folders, backup archives and, if the new server has its own credentials, its wp-config.php from the first pass on, for example by adding --exclude=wp-config.php --exclude=wp-content/cache/ to both commands: an exclusion added only on the second pass comes too late, and --delete leaves excluded files alone.
Step 4: export and import the database with WP-CLI
WP-CLI’s export command relies on MySQL’s or MariaDB’s dump tool, with the credentials from wp-config.php. It does not add the option that guarantees a consistent copy of InnoDB tables: pass it yourself. The dash sends the output to standard output.
wp db export - --single-transaction --quick | gzip > ~/site.sql.gzCopy the archive to the new server, outside the web root, create the database if needed, then import from standard input. The import does not drop tables missing from the dump: start from an empty database.
gunzip < ~/site.sql.gz | wp db import -Keep the same DB_CHARSET and DB_COLLATE values as on the old server: a misconfigured character set is enough to turn apostrophes and accents into garbled characters. For a WooCommerce store, check the order storage state after the import with wp wc hpos status. The wp wc hpos verify_data command compares the dedicated tables with the posts tables and is only relevant when compatibility mode is on.
Step 5: replace URLs, only if the domain changes
If the site’s address changes, it has to be replaced everywhere in the database, including in serialized data, where WordPress and plugins store the length of each string. A plain find-and-replace in the SQL file breaks those lengths; the WP-CLI command handles them. Always start with a dry run.
wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-onlyTwo options matter. By default, the command only processes tables registered with WordPress; WooCommerce registers only part of its own, so the order tables, both the high-performance order storage tables and the order items table, would be missed without --all-tables-with-prefix. And the guid column must never be changed: the official documentation warns that feed readers would then show old posts as new.
Finally, the stable version of WP-CLI does not match URLs escaped in JSON, in the form https:\/\/old.example.com. Run a second pass on that form if your plugins store it.
Step 6: test the new server with the hosts file
Windows, macOS and Linux
The hosts file lets your computer alone reach the new server under the site’s real address, without changing anything in public DNS. Add a line with the new server’s IP address and the site’s two names.
203.0.113.10 example.com www.example.comOn Windows, the file lives in C:\Windows\System32\drivers\etc and editing it requires administrator rights; then clear the cache with ipconfig /flushdns. On Linux and macOS, it is /etc/hosts. Do not forget to remove the line after the test.
Without touching the hosts file
The curl tool offers a command-line alternative, which its documentation describes as a sort of /etc/hosts alternative provided on the command line.
curl -I --resolve example.com:443:203.0.113.10 https://example.com/Google also suggests testing on a temporary name, such as beta.example.com, excluded from indexing. With WordPress, that means changing the copy’s address, and therefore a URL replacement: the hosts file avoids that step.
Testing traps
During the test, WordPress starts its scheduled tasks by calling its own address. As long as public DNS points to the old server, those calls go from the new server to the old one: scheduled tasks and some Site Health tests are meaningless before the switch.
Worse: two copies at the same address both think they are in production. WooCommerce Subscriptions warns that a copy migrated with the same domain does not trigger its staging mode, and can therefore take real renewal payments. On the inactive copy, turn off the processing of queued tasks, and block its emails.
Step 7: the freeze window for orders and comments
Warn, then close
The day before, announce the window with WooCommerce’s store notice, a banner set in the Customizer, which block themes can still reach. At the start of the window, close the cart and checkout: WooCommerce’s “Coming soon” mode, applied to store pages only, replaces the cart, checkout and shop pages with a holding page. It swaps the page display without blocking a checkout already being submitted, and administrators and shop managers bypass it: note the last order number at the final export, and check that none arrived on the old server afterwards.
Close comments too, with a filter in a small file in the mu-plugins folder.
<?php
add_filter( 'comments_open', '__return_false' );Why maintenance mode is not enough
The wp maintenance-mode activate command shows a 503 error to every visitor, and WordPress ignores the maintenance file after ten minutes. It is a tool for a quick update, not for a migration window. A freeze targeted at writes leaves the rest of the site readable.
How the window runs
During the freeze: second rsync pass, final database export, import on the new server, quick checks through the hosts file, then the DNS switch. Reopen orders and comments on the new server only. The old one stays closed to writes until it is shut down.
Step 8: the switch and the SSL certificate
The certificate before the switch
The certificate must be valid on the new server before the first visitor arrives. If your site sends the HSTS header, a browser that meets an invalid certificate does not even offer to continue: the site is unreachable.
HTTP-01 or DNS-01
Let’s Encrypt’s HTTP-01 validation fetches a file from your domain, on port 80. Before the switch, it therefore reaches the old server. Three solutions: copy the existing certificate and key, validate through DNS-01 with a TXT record, or redirect the validation path from the old server to the new one. Also check the CAA record if the new host uses another certificate authority.
The moment of the switch
Change the A and AAAA records, or the origin in the CDN. Watch both servers’ logs: traffic should slide from the old to the new one within minutes, thanks to the TTL lowered a week earlier.
The real case: 161 days on Woo.com, then the return
The story of WooCommerce.com between 2023 and 2024 is a textbook case. It is a domain migration documented by the company itself, with an acknowledged loss of visibility, a public rollback and a timed switch window. It illustrates almost every step of this guide.
The departure
On October 31, 2023, WooCommerce announced that WooCommerce.com was becoming Woo.com. The migration covered the platform, the marketplace, the agency program and partnerships; merchants had nothing to do. WP Tavern reported the announcement the same day, and The WP Minute gathered the community’s reactions to the rebrand and the new site two days later.
Two days later, on November 2, Google started a core algorithm update. Another followed on March 5, 2024, rolled out over forty-five days, and Google itself warned of ranking fluctuations.
The decision
On April 5, 2024, Kevin Bates, from the growth team, announced the return to WooCommerce.com. His reasoning fits in one sentence: “Moving to Woo.com created challenges for our users to find WooCommerce in Google searches”, a situation made worse by the March update. The company had brought in SEO experts, and asked its partners to update their references to Woo.com.
The same day, the developer team delayed WooCommerce 8.8: the migration, covering every subdomain, would take place on Tuesday, April 9, from 8:00 to 11:00 UTC, and the new version should not land the same day, to leave room for testing after the switch. In the comments, a team member explained that the site had been on track to regain its rankings when Google’s update set it back.
The switch
The day before, a reader pointed out that some images had never been redirected to the new domain; the team replied that this was part of the move back, and that some things might be in flux for a while. On April 9, the migration took place within the announced window. The developer blog changed address too, and the company wrote that the domain change had contributed to the decline in organic traffic.
To this day, woo.com returns a permanent redirect to woocommerce.com. WooCommerce published no traffic figures: the cause of the drop is its own reading, intertwined with Google’s updates.
What the story teaches
A domain change is an SEO project, not a hosting chore. The inventory must include every subdomain and every file host: the move back covered all of WooCommerce’s subdomains, developer blog included. On switch day, you ship nothing else: WooCommerce moved its own release. The window is announced, short and timed. And rolling back is possible, but it is a migration in its own right, with reversed redirects and partners to notify.
Step 9: the rollback plan
The rollback plan is decided before the switch, not during the outage. It comes down to five elements: the list of triggers, such as checkout failing, server errors or emails no longer going out; the exact DNS values to restore; the old server intact and closed to writes; the list of orders and comments received on the new server since the switch, to replay by hand; and a deadline beyond which fixing forward beats going back.
RFC 9199 recommends keeping the old infrastructure at least as long as the longest TTL involved, including the parent zone’s. Google advises shutting down the old hosting only when its traffic falls to zero. For WooCommerce subscriptions, an old server left running keeps taking real renewal payments: turn off its task processing before leaving it on.
Step 10: post-migration checks
Search Console
For a host change at the same address, Search Console’s Change of Address tool is not used. Simply keep the verification file or tag, and expect a temporary drop in Googlebot’s crawl rate right after the switch. For a domain change, the tool is required, with permanent redirects kept for at least a year according to Google.
Scheduled tasks
Check that no task is overdue with wp cron event list, and recreate the system tasks on the new server if WP-Cron was disabled there, as our guide to WP-Cron and system cron explains.
Transactional emails
By default, WordPress sends its emails with PHP’s mail() function. On a server with no mail service, nothing goes out. And since February 2024, Gmail requires every sender to have SPF or DKIM authentication and valid reverse DNS. Add the new IP address to SPF, or route emails through an authenticated relay, then test a real order end to end.
Caches, permalinks and the old server
The wp cache flush command only empties the object cache: purge the page cache and the CDN too. If pages return a 404 error, regenerate the rewrite rules. Check core file integrity with wp core verify-checksums, and plugin files with wp plugin verify-checksums --all, then watch the old server’s logs until its traffic falls to zero.
Migration plugins and their limits
All-in-One WP Migration
More than 5 million active installs: it exports the whole site into a single archive and handles serialized data. Its free version limits imports to the upload size the host allows; the unlimited extension costs $69 per year for fifty sites, at the time of writing.
Duplicator
More than a million installs: it produces an archive and an installer, with a URL replacement wizard. The free version does not support multisite networks. Archives and installers left on a server are sensitive files, to delete after use.
Migrate Guru and WP Migrate
Migrate Guru, free, with more than 200,000 installs, migrates server to server through its own servers, up to 200 GB, with five migrations per month per user. WP Migrate, with more than 200,000 installs, excels at URL replacement in the database; pushing and pulling between sites is reserved for its paid version.
What no plugin controls
Some of these tools promise a migration without downtime. None of them controls DNS caches, the write freeze, the new server’s certificate, scheduled tasks on two copies or email authentication. Downtime depends on the runbook, not on the archive tool. Above all, keep an independent backup, with one of the WordPress backup plugins we compared.
Summary table: the runbook day by day
| When | Actions | Domain change |
|---|---|---|
| D-7 | Inventory, TTL at 300 seconds | Redirect plan for every URL |
| D-2 | First rsync pass, import rehearsal, hosts test, certificate | URL replacement dry run |
| D-1 | Announcement through the store notice | Notify partners |
| D-day | Freeze, second pass, final database, DNS switch, reopening | URL replacement, 301 redirects |
| D-day, +1 h | Test order, emails, tasks, caches | Change of Address tool |
| D+2 | TTL raised again | Indexing follow-up |
| D+7 to D+14 | Old server at zero, then shutdown | Redirects kept at least a year |
Frequently asked questions
How long does DNS propagation take?
As long as it takes caches to expire, meaning at most the old TTL. With a TTL lowered to 300 seconds a week ahead, most visitors switch within minutes. A DNS server change also depends on the parent zone’s TTL, two days for a .com.
Do I need a migration plugin?
No, if you have SSH access: rsync and WP-CLI do the job, with more control. A plugin helps on hosting without command-line access, but it does not replace the runbook.
Should I declare the change in Search Console?
Only if the domain or subdomain changes. For a simple host change at the same address, the Change of Address tool is not used.
What if I am locked out of the admin after the migration?
Check the home and siteurl options. As a last resort, the WP_HOME and WP_SITEURL constants in wp-config.php force the addresses. The RELOCATE constant also exists, but the documentation warns that leaving it in place is insecure.
How do I avoid double subscription charges?
By turning off the processing of queued tasks on the copy that must not charge, or by changing its address to trigger WooCommerce Subscriptions’ staging mode.
When should I shut down the old server?
When its traffic falls to zero in the logs, as Google recommends, and no earlier than the longest TTL involved. In practice, keep it one to two weeks, closed to writes.
Conclusion
A migration without downtime involves no magic: a TTL lowered a week ahead, two copy passes, a cleanly exported database, a discreet test through the hosts file, a short write freeze, a certificate ready before the switch, and a rollback plan decided in advance. Each step is simple; their order is what makes the difference.
WooCommerce.com’s return recalls the rest: changing domain is an SEO project, a switch day is shared with nothing else, and rolling back is always possible if you planned for it. To choose the destination, our comparison of WordPress hosting providers is a good starting point.
Sources
- WordPress Advanced Administration Handbook. Migrating WordPress
- WordPress Developer Resources. wp search-replace
- WordPress Developer Resources. wp db export
- WordPress Developer Resources. wp db import
- WordPress Developer Resources. wp_is_maintenance_mode()
- WordPress.org Documentation. Site Health Screen
- Google Search Central (December 2025). Changing your hosting
- Google Search Central (August 2026). Site moves with URL changes
- Google Search Console Help. Change of Address tool
- IETF (July 1997). RFC 2181, Clarifications to the DNS Specification
- IETF (March 2022). RFC 9199, Considerations for Large Authoritative DNS Server Operators
- IETF (March 2020). RFC 8767, Serving Stale Data to Improve DNS Resiliency
- Amazon Web Services. Making Route 53 the DNS service for a domain that’s in use
- Cloudflare Docs. Time to Live (TTL)
- Google Public DNS. Frequently Asked Questions
- Linux man-pages. rsync(1)
- Microsoft Support. How to reset the Hosts file back to the default
- Linux man-pages. hosts(5)
- curl. curl man page
- Let’s Encrypt (February 2026). Challenge Types
- MDN. Strict-Transport-Security
- WooCommerce. How Subscriptions Handles Staging Sites and Migrations
- WooCommerce. Coming soon mode
- WooCommerce Developer Docs. HPOS CLI tools
- WordPress Advanced Administration Handbook. Mail
- Google. Email sender guidelines
- WooCommerce, David Callaway (October 31, 2023). Say hello to Woo.com
- WP Tavern, Sarah Gooding (October 31, 2023). WooCommerce Rebrands as Woo
- WooCommerce, Kevin Bates (April 5, 2024). Woo.com migrating back to WooCommerce.com
- WooCommerce Developer Blog (April 5, 2024). WooCommerce 8.8 is Delayed
- WooCommerce Developer Blog (April 9, 2024). WooCommerce.com Domain Migration
- Google Search Central Blog (March 5, 2024). March 2024 core update and new spam policies
- WordPress.org (October 2026). All-in-One WP Migration and Backup
- ServMask (October 2026). Unlimited Extension
- WordPress.org (October 2026). Duplicator
- WordPress.org (October 2026). Migrate Guru
- WordPress.org (October 2026). WP Migrate Lite
- Google Search Status Dashboard. Ranking incident history
- The WP Minute, Matt Medeiros (November 2, 2023). Find WooCommerce inside Woo.com
- WooCommerce. WooCommerce Customizer
- WordPress Developer Resources. wp_maintenance()
- WordPress Developer Resources. comments_open hook
- WordPress Advanced Administration Handbook. Loopbacks
- Microsoft Learn. ipconfig
- Cloudflare Docs. Proxy status
LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.