Migrating an active WooCommerce store means moving a system that keeps changing. While the new server is being prepared, orders arrive, customers sign up, subscriptions renew, and integrations keep syncing. The real challenge isn't moving the store. It's moving it without losing what happened during the move.
The site isn't a photograph
For an institutional site, a migration can be treated almost like a snapshot: copy files, export the database, import everything on the new server, and make the switch. WooCommerce is different. While we prepare the new infrastructure, the old store keeps changing.
You might get:
- An order
- A new customer
- A refund
- A stock change
- A renewal
- An address update
- A webhook from an external provider
That means a backup taken at 10:00 can already be outdated by 10:05. The migration needs to account for that from the start.
First you need to know which data is alive
Before moving anything, it's worth identifying which parts of the system change constantly and which can be copied ahead of time. Themes, plugins, images, or static files can be prepared in advance. Orders, users, sessions, stock, and some metadata can't. There are also plugins that keep their own tables, and external services that store references to internal IDs, URLs, or credentials tied to the current environment.
Checking WordPress's standard tables isn't enough. You need to understand what every important piece of the system writes.
Cutover timing matters
In a large migration, there's almost always a moment where you need to limit changes. It could be a brief maintenance window, temporarily putting the store in catalog mode, or pausing certain processes while the final sync happens. The key is keeping that window as short as possible.
A common strategy is to move everything heavy first: files, plugins, configuration, images, and an initial copy of the database. Then, close to the actual cutover, sync only the data that changed since that copy. The less you have to do during the cutover, the lower the risk.
DNS doesn't change instantly for everyone
Changing a DNS record doesn't mean every user immediately starts using the new server. For a while, some visitors may still be hitting the old server while others are already on the new one. That's especially dangerous for a store. If both servers accept orders at the same time, you can end up with two sources of truth.
That's why a migration shouldn't rely on the idea that "we switch the DNS and we're done." You need to think about what happens during that transition.
Payments need special attention
A store can look perfectly fine after migrating and still have serious problems. Payment gateways usually depend on:
- Return URLs
- Webhooks
- Keys
- Certificates
- Firewall rules
- Authorized IPs
- Scheduled tasks
A successful checkout on screen doesn't guarantee the whole flow actually worked. You need to confirm the order was recorded correctly, that the provider sent its notifications, and that WooCommerce processed the expected status changes. In a migration, testing the Pay button is just the beginning.
Cron and background processes
WooCommerce and many of its plugins depend on scheduled tasks for email, renewals, synchronization, cleanup, queue processing, and imports. A migration can leave the frontend working while those processes are stopped or, worse, running simultaneously on both servers.
Before the switch, it's worth knowing which cron jobs exist and who's running them. Afterward, you need to confirm that only the correct environment keeps doing it.
Integrations don't know we moved
ERP, CRM, inventory providers, marketing tools, fulfillment systems, and internal applications may be connected to the old WooCommerce. Some use the API. Others use webhooks. Others access files or custom endpoints directly.
There can even be processes nobody remembers because they've been running for years. Before migrating, you need to map out those connections. Finding them later, because they stopped working, is a lot more expensive.
Search-replace: doing it right matters
Changing URLs inside WordPress looks simple until serialized data shows up. A direct replace on SQL can alter the length stored inside a serialized structure and break the whole value. Tools like WP-CLI understand these structures and can replace URLs safely. The same risk appears when importing a production WordPress site locally.
It's also worth checking absolute URLs in plugin settings, generated content, caches, and files that don't necessarily live inside the database. The domain shows up in more places than it seems.
The migration isn't over when the switch happens
The homepage loading from the new server doesn't mean the migration is finished. After the cutover, you need to look at what actually matters. Placing a full order. Creating a user.
Validation includes testing transactional email, checking stock, confirming webhooks, running scheduled tasks, reviewing logs, and checking integrations. It also means comparing recent orders between source and destination and monitoring the store during the first few hours.
The biggest problems rarely show up by looking at the homepage.
Having a way back is also part of the plan
A migration should have a clear criterion for deciding when to move forward and when to roll back. If a critical problem shows up during the switch, improvising a rollback on the spot is a bad strategy. The previous server should stay available until you've confirmed the new environment is stable.
Backups should be clearly identified. And the team should know exactly what rolling back involves. A rollback isn't admitting the migration went wrong. It's just another tool of a well-prepared migration.
Moving data is the easy part
A WooCommerce migration isn't primarily an infrastructure problem. It's a state problem. You need to know what data changes, who can modify it, which processes depend on it, and how to avoid two different versions of the store starting to diverge. Copying WordPress is the mechanical part. The migration succeeds or fails on state control, cutover timing, and the ability to roll back without losing operations.