Updating WooCommerce from staging without overwriting live orders

A staging site gives you somewhere to test WooCommerce changes before customers see them. The awkward part comes afterwards: the test site looks right, but the live shop has kept taking orders, changing stock and registering customers while you were working.

My approach is to plan how the tested change reaches production before starting the work. For an ordinary plugin update, I would usually apply the tested versions to the existing live store. I would not treat the staging database as a newer copy of the business.

Why pushing the whole staging site can lose orders

Imagine copying a shop on Monday, testing a theme change for three days and replacing the live database on Thursday. The staging copy knows about Monday's orders. It does not automatically know about the purchases, refunds, customer accounts and stock adjustments made afterwards. This is a hypothetical example of the problem I would look for in a deployment plan.

A successful-looking push can therefore leave the storefront working while the order history goes backwards. The payment provider may still have a successful payment, and the warehouse may already have dispatched the parcel. Those external events are not undone because the website database was replaced.

The first question I ask is exactly what a hosting control panel means by push to live: files, the whole database, selected tables, or some combination. A reassuring button label is not a deployment specification.

Separate code changes from store data

I would write a short change list before testing. A theme stylesheet, a plugin version, a checkout setting and a redesigned page are different kinds of change. Some live in files; others live in the database. A files-only deployment will not reproduce every setting or page edit.

For each item, I want to know how it will be applied to the existing store and how I will confirm it worked. That could mean installing an exact plugin release, applying a documented setting, importing narrowly scoped content or running a reviewed migration. Moving an entire database to transfer one setting is a much broader operation.

Selective table pushes also need scrutiny. A table can contain several types of content, and records may refer to entries elsewhere. I would investigate those relationships rather than assume that excluding a table called orders protects everything.

Check the store's order storage and extensions

WooCommerce's High-Performance Order Storage documentation describes dedicated order tables and an optional compatibility sync with the older WordPress storage. I would establish which storage is authoritative on the store and whether synchronization is enabled before planning any data movement.

That is not a reason to switch storage modes during a routine update. It is a reason to avoid an old migration recipe that assumes every order is stored in the same place. Extensions can have their own records and dependencies too.

Subscriptions deserve particular attention. WooCommerce's backup and restore guidance for Subscriptions recommends testing redesigns on a clone and applying the changes to the existing site while preserving its database. I would review the installed subscription and payment extensions before proposing an alternative.

Unsure what your staging push will overwrite?Send me the change you want to release and how your host handles staging. I can review the deployment approach and scope the work needed.
Talk to Adam about your store

Make staging a controlled test environment

I would check what the clone can do outside WordPress before running tests. Customer emails, fulfilment requests, accounting syncs, stock feeds and payment activity all need an explicit test arrangement. Password protection is useful, but it does not stop background code from contacting another system.

My test plan would identify which integrations are disconnected, which use a sandbox and where test messages are captured. I would keep a record of those differences so a disconnected staging integration is not mistaken for a fully tested live workflow.

For payment testing, I would use the provider's documented sandbox on the isolated copy. I would not replace the live store's keys with test keys and leave real customers to discover it. My article on Stripe test keys on a live WooCommerce store explains that separate problem.

Test the order journey, including the staff's work

WooCommerce's official update guide advises a current backup, staging tests and checking the store's important workflows. I would turn that guidance into a checklist for the particular shop, rather than stop when the homepage loads.

• Choose representative products, including variations and any special pricing or add-ons.
• Check the cart, shipping choices and the totals for the scenarios the store supports.
• Follow guest and account checkout using the agreed test payment setup.
• Check the resulting order, stock change and captured customer message.
• Run the staff's next step: picking, labels, exports or the relevant integration.
• Exercise any subscription, booking or download workflow that the change could affect.

I would record the versions tested and the expected outcome. If the live release uses different versions, settings or integrations, the staging result only proves part of the journey.

Agree the release window and recovery plan

Before deployment, I would agree who controls the release, how customers will be kept out of checkout during the necessary changes and who handles incoming order work. Closing the storefront does not by itself pause every webhook, subscription renewal or external stock update.

Some WooCommerce releases require a database update after the plugin files change. The official guide describes completing that update and checking its progress. I would include that step where applicable, then verify the live store before reopening checkout.

Recovery needs its own decision. WooCommerce warns that restoring an older backup can omit orders and customer information created in the intervening period. For Subscriptions, previously completed scheduled renewals can also return to a pending state.

I would therefore establish what happened after the backup before restoring it. Reverting files may be appropriate for one problem; a database migration or incompatible schema may require a different recovery. The plan should say how affected orders and external activity will be reconciled, not simply say restore if anything breaks.

When there is no staging site yet

I would start by establishing a suitable test copy and a way to recover it. The host, plugin licences and connected services all affect that setup. If an urgent fix cannot wait for the usual process, I would agree a narrower release and recovery plan for that specific issue.

Once the first release is documented, future updates become easier to repeat: the same representative orders, known integration differences and a clear record of what changed. That gives ongoing maintenance something concrete to check.

Get help with WooCommerce updates and maintenance

I provide WooCommerce development and troubleshooting, including inherited stores, plugin conflicts and checkout problems. A focused review can establish whether the missing piece is a test environment, a safer deployment process or a repair to the store itself.

For an enquiry, tell me what you want to update, whether the shop has subscriptions or external integrations, and what staging or backup facilities you currently have. You do not need to assemble a complete technical brief or send passwords in the first message. My service pricing page explains audits, project work and ongoing care.

Plan the update before pressing push.Describe the store and the change. I will help identify the next step and agree the scope before work starts.
Discuss your WooCommerce updateSee maintenance and project pricing