Migrate WordPress to another host without losing your orders

9 min read

A migration from WordPress to another host, with the same domain, must preserve orders, their payments and stock updates. The critical point is not the copy: it is the moment when the old server stops writing and the new one becomes the sole authority.

A backup restores a past state. A migration organizes continuity between two states. Prepare the new server while the store remains open, then freeze writes, sync, and open only after validation.

Fix authority and access before any copy

Combine access to both hosting, DNS and payment services. Identify who authorizes the freeze, who executes the switch, and who validates the commands. The store manager must be able to refuse reopening.

Take inventory of PHP and WordPress versions, extensions, command storage, media, scheduled tasks, mail senders and logistics connections. Add incoming and outgoing webhooks, API modifying stock, and data stored elsewhere.

WordPress asks to save the site files and its database before changing servers ^[3]. A complete restoration requires these two sets ^[2]. Also check their restoration in an isolated environment.

Agree on an operating rule: only one server can accept writes. Validate the data processing conditions at the new host, restrict access to clones and plan for their deletion after validation.

Copy to prepare, without opening a second store

The example is fictitious and does not describe a customer of 4SYSTEM: a spare parts store is still receiving orders during preparatory copying. The old site remains the reference. The clone is used to verify hosting, media, shopping cart and connections, not to produce actual orders.

Isolate this clone before its first start: block the sending of emails, real payments, logistics calls and the execution of tasks. A local preview with the usual domain does not constitute protection.

With WooCommerce Subscriptions, keeping the same domain after copying the database does not trigger staging mode: renewals can be processed in real mode ^[9]. So don’t be fooled by the word “preproduction” in the hosting panel.

Keep the usual public URLs and adjust the connection to the database if its parameters change: WordPress distinguishes between maintaining the domain and changing the configuration ^[3]. Postpone functional updates: they would complicate diagnosis and rollback.

Migrating WordPress to another host: freeze then synchronize

The preparatory copy becomes out of date as soon as a new order arrives. To get the toggle state, follow this order:

1. Close order pass and suspend backend changes, imports, syncs, and write API calls. A simple maintenance page is not enough.
2. Reconcile payments already incurred with orders from the old site. Notifications in transit must be processed there before cutting or kept in a durable queue for tested replay.
3. Check the recovery options of the payment provider. Do not confirm receipt of a webhook without lasting preservation. Without documented replay or possible reconciliation, postpone the switch.
4. Stop WordPress tasks, hosting crons and extensions files. Log the last allowed state and still pending events.
5. Create the final backup, base then files; restore the files then the database to the isolated destination, in accordance with the order recommended by WordPress ^[2].

Final synchronization replaces the preparatory state with the coherent set of frozen data, including the extension tables and recent media. Do not just copy orders: stocks, accounts, notes and related statuses must follow. Require proof of freezing and reconciliation of pending orders before authorizing DNS.

Toggle DNS without creating two active sites

Note the records that actually direct web traffic: IPv4, IPv6 and possibly CDN. Verify that the planned change does not affect email records. If you reduce the TTL, do it ahead of time and note its previous value.

The DNS does not switch all visitors simultaneously. Some caches may still lead to the old server while others reach the new one. So choose the new one as the writing authority, regardless of what your browser sees.

The old server must remain unable to accept commands, callbacks or administrative modifications. Keep it in maintenance; a relay to the destination is only acceptable after technical validation of the routing and webhooks signatures.

Control HTTPS, canonical domain, administration and caches from multiple accesses. The display does not prove that the correct base is responding, nor that all payments are reaching it. Keep proof of the server address contacted.

Receive the recovery and neutralize the old automations

The acceptance testing begins before opening: administrator connection, media, basket, delivery, taxes and payment process in test mode, without real collection on the clone. Then compare the sample orders and pending payments with the final saved status and the service provider's references. Check their associated statuses, ratings and stocks.

Reactivate processing on the new server only after this validation. Check each queue before launching to avoid replaying an action that has already been performed. The replay of webhooks must control their identifiers to avoid double processing. Reopen orders, then track an authorized order through notification and logistics processing.

The old hosting retains its automatisms as long as you do not neutralize them. For Subscriptions, staging mode does not stop all scheduled events, and other extensions can still send emails ^[9]. Separately control Action Scheduler, WP-Cron, external crons and SMTP sender. Stopping the Action Scheduler runner can also block events from other extensions using this library ^[9].

Document recurring checks in your management process maintenance and backups. Only delete the old environment after deferred events have been reconciled and routing and the absence of residual writes have been confirmed.

Switch log: traceable decisions

The following log provides completed entries for the fictional store. The technical pilot holds the evidence; the store manager signs the opening decision. The parts shown are expected validations, not observed results.

Enter for each line the actual time, the speaker and the secure location of the evidence. Note the identifiers useful for reconciliation, never the card data.

Go back without deleting new writes

Rollback depends on writes, not just server operation. Apply this decision tree:

• No new entries on the destination? Keep both sites closed, confirm this absence, then reestablish the old one as authority before modifying the DNS and reactivating its processing.
• Have orders, payments, accounts or stocks changed? Preserve the new state immediately. Prioritize a correction on the new server; an old backup would erase these changes.
• Is the return of accommodation still necessary? Freeze the destination, save its full state, and restore this recent state to the old isolated server. Revalidate pending integrations and events before giving authority back to it.
• Both servers wrote? Freeze all writes on both servers according to the procedure above, then maintain their states separately. Have orders, payments and logistics actions reconciled before any recovery; no improvised SQL merge guarantees their consistency.

A refund, email or shipment already triggered is not canceled by restoration. Reconcile service provider references and logistics logs to decide which events to resume. If the absence of new entries is not demonstrable, treat the case as a recovery after entries.

Frequently asked questions

A webhook arrives on the old server after opening: what to do?

Do not try to reactivate its store to process this single event. Check if the provider plans a retry and if the notification is in your durable queue. Reconcile its reference with the payment recorded on the new site, then apply the tested recovery mechanism. Without sufficient proof, keep the case in manual review.

Can we keep the old hosting only for emails?

Yes, if the boxes and their DNS records voluntarily remain with this service provider. Then separate the maintenance of messaging from that of WordPress: the old application, its tasks and its automatic sending must remain neutralized. Check the contract dependencies before termination and test reception, sending and authentication from the selected service.

Can a basket opened before frost be guaranteed?

Not with just copying the commands. A shopping cart may depend on sessions, cookies or external storage whose resumption must be verified. Warn buyers of the freeze and test this case at the destination. Do not confuse abandoned cart and committed payment: the latter requires reconciliation before asking the customer to start again.

Prepare the next switch

Start by completing the entry inventory and assigning journal decisions. Then schedule the freeze only when isolated copying and resumption of notifications are enabled. If no one can confirm sole authority or preserve orders that appeared after opening, defer the switch. To frame this preparation, you can consult the web services of 4SYSTEM.

Sources

• Backups : Advanced Administration Handbook | Developer.WordPress.org (accessed 2026-10-08)
• Migrating WordPress : Advanced Administration Handbook | Developer.WordPress.org (accessed 2026-10-08)
• How Subscriptions Handles Staging Sites and Migrations Documentation - WooCommerce (accessed 2026-10-08)