How to update WooCommerce safely: before, on staging, on the live store, and if it breaks

A WooCommerce update differs from other plugin updates in three ways. It can change the database as well as the files. Your theme may hold its own copies of WooCommerce's templates, which the update does not touch. And each extension states which WooCommerce version it was tested with.

The safe order follows from those three. Read what the release changes, check your extensions and template copies, and take a backup. Update a staging copy and place a test order there. Then repeat the same update on the live store with the checkout closed, so that going back would cost no orders.

How to safely update WordPress has the method for any update: a backup, one thing at a time, and a way back. This page covers what WooCommerce adds to it.

What makes a WooCommerce update different

Before you update

Update a staging copy first

WooCommerce's guide is direct about this: "Do not test updates directly on your production site." How to set up a WordPress staging site covers making the copy and stopping it from emailing customers or taking real payments.

If something fails on staging, the live store has not changed. Stay on the version you have, and work out which part failed. When it is an extension, how to find a plugin conflict has the method.

Update the live store

Orders placed between the backup and a restore

A backup holds the orders that existed when it was made. Restore it, and every order placed afterwards is gone from the store, though the customers paid.

How to avoid the problem. The order of the steps above does it: checkout closed, then the backup, then the update, then the test, then reopening. While the checkout is closed, no customer can order, so the backup stays current. If the test order fails, you put back the earlier files and that database, and lose nothing but the test order. WooCommerce's guide says the same: "keep the site out of checkout, restore from your backup if needed, and troubleshoot the issue on staging before trying again on production."

This only holds until you reopen. Do not reopen until the test order has gone through. And before any restore, look at WooCommerce, then Orders, for anything newer than the backup.

If the fault shows after you have reopened. Orders have arrived, and a restore would remove them. Work in this order.

1. Close the checkout again.
2. Look for a repair that leaves the database alone: an update to one extension, an earlier version of one extension, or a template copy brought up to date. The checkout-down runbook works through these.
3. If only a restore will do, export every order placed since the backup first.

The command below writes those orders, with their customers, addresses and items, to a file in your home folder. --user is the ID of an administrator, which WooCommerce's commands require. --after is the time of the backup, on the store's own clock. Set it a few minutes early: an extra order in the file does no harm. The command returns at most 100 orders.

wp wc shop_order list --user=1 --after=2026-10-08T02:00:00 --format=json > ~/orders-since-backup.json

Without WP-CLI, go to Analytics, then Orders, set the dates, and use the "Download" link above the table for a CSV. Keep the "New order" emails the store sent you as well.

After the restore, enter each order again: go to WooCommerce, then Orders, and select "Add order". Match each one to its payment in your payment provider's dashboard.

If the update breaks the store

Keep the checkout closed, place a test order, and note where it stops. The fault may lie in an extension or in a template copy and not in WooCommerce itself. The failed update runbook covers a store that will not load at all.

Going back to the previous version

WordPress.org keeps every earlier release of WooCommerce. They are under "Previous Versions" on the plugin's Advanced View, with this warning: "Previous versions of plugins may not be secure or stable. They are not recommended for use on production websites."

The command below replaces WooCommerce's files with those of the version you name, which is the number you wrote down before the update. It does not change the database. --force is needed: without it WP-CLI answers "Plugin already installed" and does nothing.

wp plugin install woocommerce --version=11.1.2 --force

Why the database may not match

The update changed the database to suit the new code. Installing older files does not change it back. WooCommerce's documentation says: "Reverting to an older version can cause data inconsistencies if the database schema has changed."

Its instruction is to "Use this approach only on a staging environment, and restore a matching database backup before activating the older version." It calls restoring that backup "essential". So the documentation offers a live store no way back by files alone.

Going back by files alone is least risky when the release notes said "Database update: No", because that release left the database as it was. WooCommerce's instruction to try it on staging first still applies.

Putting the database back

The next command overwrites the database with the file you exported. Every order, customer and setting saved since that export is lost, which is why it belongs to the case where the checkout stayed closed. Run it after the older files are in place. Run it first, and the newer code would begin updating the restored database again.

wp db import ~/before-woocommerce-update.sql

Then read WooCommerce, then Status. "WooCommerce version" and "WooCommerce database version" should both show the earlier release.

After going back by files alone, do not run wp wc update. On the older version it finds nothing to do, and it records the older version's number as the database version without undoing anything.

Stay on an older version only until a fixed one is out.

The "WooCommerce database update required" notice

WooCommerce's update guide describes a notice that appears after some updates, with two buttons: "Update WooCommerce Database" and "Learn more about updates". It says to have a backup before you select the first. A "View progress" link then opens Scheduled Actions, and a "WooCommerce database update complete" message confirms the end.

Since WooCommerce 9.9 you may never see it. The release notes for 9.9 say all stores "will now run database updates and migrations automatically in the background", and that developers can opt out with a filter. So on a current store the notice appears only where someone has switched the automatic update off.

Either way, check that the update finished. Under WooCommerce, then Status, "WooCommerce database version" shows the new release. If it does not, run wp wc update, or go to WooCommerce, then Status, then Tools, and use "Update database".

Version numbers, and how often to update

WooCommerce's release calendar says there is "no distinction between major and minor releases in our versioning system". A move from 11.1 to 11.2 is a full release, like a move from 10.9 to 11.0. Releases "typically occur on a 5-week cycle". Template files can change in any of them.

WooCommerce's guide says: "A monthly cadence works well for most stores." It then gives the exception: "Update sooner than your regular schedule if a release includes a security fix or resolves broken functionality your store depends on."

Falling far behind has a cost of its own. WooCommerce's security policy says ordinary security fixes are published for the latest version only. Only for the most severe, a CVSS score of 9 or more, does it patch the last 21 releases, and versions older than that receive nothing. WooCommerce's own extensions are tested against the latest release series and the one before it.

To take a fix release and nothing larger, WP-CLI has --patch:

wp plugin update woocommerce --patch

Automatic updates for WooCommerce

WordPress can update any plugin by itself. On the Plugins screen, "Enable auto-updates" in a plugin's row switches it on for that plugin. WordPress's documentation says these updates run twice a day, that the site emails the result, and that you should be able to go back to a previous version of the site before you enable them.

WooCommerce's update guide does not mention automatic updates. Every step it lists is one an automatic update skips: the backup, the staging copy, Coming soon mode and the test order. On a current version the database update then follows by itself. The result is new files and a changed database, at an hour you did not choose, with the checkout open and no backup taken first.

Leave them off for WooCommerce, and for payment gateways, when any of these is true:

• The store takes orders most days.
• The theme overrides WooCommerce's templates.
• An extension or a gateway comes from a third party.
• Nobody would place a test order the same day.

They can be the lesser risk on a store that would otherwise go months without an update. Pair them with frequent database backups, and read the email WordPress sends.

Switching them off does not rule out every automatic update. For one security patch in September 2021, WooCommerce said automatic updates "began rolling out" to "all stores running impacted versions".

wp plugin auto-updates status woocommerce

wp plugin auto-updates disable woocommerce switches them off. On a plugin where they are already off, it ends with an error line that can be ignored.

If you would rather hand this over, our WooCommerce maintenance service is the Store care plan: updates are tested on a staging copy first, checkout and payment are tested after every update, and order data is backed up more often.