WooCommerce Hosting Migration: An Orders, Payments and Stock Checklist

A WooCommerce hosting migration is not complete when the homepage loads on the new server. Orders, payments, stock, customer accounts and background jobs must remain consistent. For a Singapore store connected to a POS, ERP or fulfilment service, those connections need as much attention as the website itself.

Use this checklist when asking a hosting provider to plan a move. It is a planning guide, not an instruction to overwrite a live database. A busy store needs an agreed cutover procedure and a person responsible for deciding whether it is safe to reopen checkout.

Why a product export is not a complete store migration

A catalogue export and a full hosting migration serve different purposes. WooCommerce’s product migration guidance distinguishes product-transfer tools from whole-site migration. Your migration scope must also account for the data and behaviour provided by extensions, including subscriptions, custom order fields and integrations.

Create an inventory of the database, uploads, code, configuration and external services. Confirm the order-storage configuration and extension compatibility instead of assuming a tool understands every custom table. Compare the destination environment with the current WooCommerce server recommendations and the requirements of your plugins.

Prepare an isolated rehearsal

Test a recent copy before planning the live switch. Restrict access and prevent the rehearsal site from sending customer emails, charging payment methods or submitting fulfilment requests. Review payment webhooks, scheduled tasks, subscriptions and connected systems individually: blocking search indexing alone does not make a staging store safe.

Record the expected results for several representative products: a simple item, a variation with size or colour, an out-of-stock item and any product with special pricing or custom options. Test logged-in and guest shopping journeys on mobile as well as desktop.

Choose how new writes will be controlled

The key cutover question is what happens to changes made after the first copy. Orders can arrive through checkout, a POS, an API or an integration. Inventory adjustments, refunds and administrative edits are writes too.

For a controlled migration, the responsible team should identify every write source, agree when it will pause or be routed to the authoritative system, and explain how final data will be transferred and checked. A maintenance message on the website does not automatically stop APIs or background jobs. Avoid two independently writable stores unless the team has designed and tested a safe synchronisation method.

DNS is only one part of the switch. DNS TTL affects record caching; it does not move orders or guarantee that every visitor changes servers at the same moment. Plan for requests that continue to reach the old environment.

Acceptance checks before reopening checkout

• Orders: reconcile recent orders, statuses, totals, line items and payment references, including changes during the cutover window.
• Products: confirm SKUs, variation choices, prices, tax settings and stock behaviour for representative items.
• Payments: use the gateway’s supported testing method; verify callbacks and order-status changes without creating uncontrolled charges.
• Customer access: test login, account history and password-reset behaviour with approved test accounts.
• Integrations: check POS, inventory, delivery, accounting and ERP connections, including their error queues.
• Background work: confirm that scheduled tasks run from the intended production environment only.
• Caching: check that cart, checkout and account behaviour remain correct for different customers.
• Search continuity: preserve URLs where possible; inspect redirects, canonical tags, sitemap availability and accidental staging noindex settings.

Record the result, time and reviewer for each check. A successful payment page is insufficient if the stock update or fulfilment notification fails afterwards.

Subscriptions require additional care

WooCommerce’s subscription recovery guidance describes risks including missing transactions and renewals being processed again after restoring older data. Review payment tokens, renewal schedules and the extension’s migration procedure with the responsible developer. Do not assume that importing the latest orders into an old staging copy is safe for subscriptions.

Plan rollback around transactions, not just files

Before cutover, agree the conditions that would trigger a rollback and who approves it. After the new store accepts orders, simply switching DNS back can leave valid transactions on the other server. The recovery plan must account for the authoritative order history, payments and inventory before another change is made.

Keep the old environment available under controlled access for the agreed retention period. Do not leave an abandoned, writable copy processing jobs. Arrange secure disposal of temporary backups and staging data after acceptance and retention requirements are met.

What should you ask a migration provider?

Can you promise no downtime?

Ask for the actual method and its limits. Some stores require an agreed checkout pause. A documented data-consistency plan is more useful than an unsupported promise of a completely invisible migration.

Do we need a VPS for WooCommerce?

Not necessarily. The choice depends on workload, integrations and support requirements, not product count alone. Compare managed WordPress hosting with VPS hosting after reviewing the store.

Plan your WooCommerce move with QUAPE

Send your store URL, current hosting arrangement, key extensions, connected systems and preferred migration window. QUAPE can discuss the hosting fit and the testing scope; custom integration changes can be assessed through our e-commerce development service. Request a WooCommerce migration review without sharing credentials or customer exports in the enquiry form.