How to Deploy WooCommerce Staging Changes Without Overwriting Live Orders

A WooCommerce staging site is a separate copy of a store used to test changes before customers see them. The live site continues to receive orders and customer updates while staging is being tested. If you replace the live database with an older copy from staging, you erase activity recorded on the live site since that copy was made.

Deploy the tested code or design changes without replacing the live database. Orders and customer details are recorded in the database, which also stores settings and much of the store’s content. Site files hold themes, plugins, and custom code. If a change also affects content or settings stored in the database, move only the specific data you need or make the change directly on the live site.

Find where the change is stored

Theme, plugin, and custom-code changes are commonly stored in files under wp-content. When you deploy those files without replacing the database, live orders usually remain in place. In its update guidance, WooCommerce describes the store as a combination of files and database data. It recommends testing updates on staging, then applying the tested update set to production.

Check where dashboard changes are stored. A page-builder layout may be in the database. The same may be true of a plugin setting or an edited page, so deploying files alone will not move these changes. For a small, known change, make the same change on the live site. For a larger change, work with someone who understands the relevant database tables and records to move only the data you need.

Handle changes to the database or its structure separately from a full database push. For example, a plugin update might run a routine that upgrades the database. Follow the plugin’s instructions, and do not assume that moving its files alone completes the upgrade.

Deploy files and keep the live database

Before you deploy, back up the live site’s files and database. Make sure you can access the backup if the live site becomes unavailable. WooCommerce advises backing up before database changes in its database import and export guidance.

For code changes, deploy only the changed files, release a tested version from version control (a record of code changes), or transfer selected files. If your hosting provider lets you choose which files to deploy, check the selected paths before confirming the push. For example, Kinsta documents file-only and selective pushes for its own environment tools; other hosts may handle deployments differently, so check your provider’s instructions.

A backup helps you recover if a deployment fails. Restoring it does not combine staging changes with newer live activity. If you restore an earlier backup, you can lose orders or customer updates recorded after that backup. Stores using WooCommerce Subscriptions also need to account for subscription records, payment tokens, and renewal activity, which WooCommerce discusses in its backup restoration guidance.

Move database changes selectively

When a change is stored in the database, identify the specific content or settings you need. Move only those records with a method suited to the change, or recreate the change on the live site. Importing the entire staging database to transfer one page or setting also replaces unrelated records, including newer live activity.

Take care when transferring selected database tables. A table can contain both settings and live data, and one WooCommerce feature can use several related tables. Do not rely on a general list of tables to exclude. Ask an experienced operator to identify the tables involved and any related data the feature needs, including data added by extensions.

The review must account for how WooCommerce stores orders. High-Performance Order Storage (HPOS) is WooCommerce’s newer order-storage feature, which stores orders in dedicated tables. Other stores use the older WordPress posts-and-metadata storage. Some stores also have compatibility or synchronization settings that determine which storage location WooCommerce treats as the current source of order data. Before transferring selected database data, check the live store’s HPOS setting and synchronization status. WooCommerce’s HPOS documentation and database table reference describe the relevant storage and tables.

Some hosts suggest copying the live database to staging before deploying staging changes to the live site. This gives staging more recent data, but it does not protect orders placed after the copy. If customers place orders before you deploy, replacing the live database with the staging copy can still erase those orders. For an active store, keep the live database as the current source of data unless your migration plan preserves new live data.

Check payments and integrations on staging

A staging copy can include settings that connect to real payment, email, or fulfillment services. Before testing, check each extension and integration so activity on staging does not trigger unwanted actions in those services.

WooCommerce documents a WooPayments migration issue involving the wcpay_account_data and wcpay_onboarding_test_mode options. Copying those values to production can leave WooPayments in test mode, so exclude them from a transfer to live as directed in its site migration guidance.

WooCommerce Subscriptions checks the site URL saved when the extension was activated to identify a staging site. On staging, it requires manual renewals and suppresses subscription-related emails, but WordPress or other plugins may still send emails. Review the extension’s staging guidance, then check how your other payment gateways, webhooks, email services, and fulfillment connections behave. Do not assume those services automatically recognize a staging site.

Limit checkout interruption and test the live store

Put the live store in Coming Soon mode during an update if it requires database changes or other work that should not run while customers are checking out. WooCommerce recommends this approach for its update procedure and advises you to complete any required WooCommerce database update before continuing testing. Maintenance mode reduces activity during the change, but it does not make an old staging database safe to import.

After deployment, test the live store features affected by the changes. Check product pages, the cart, and checkout. Then verify payment methods, shipping and tax calculations, and order emails. Test relevant extension features too. If the changes affect order storage or processing, test refunds and subscription purchases or renewals if your store uses those features. WooCommerce’s large-store HPOS guidance recommends testing migration behavior on staging. The synchronization time reported for its test store applies only to that store, so do not use it as a general estimate.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com