WooCommerce is a plugin, but it doesn’t update like one. It ships monthly, migrates its own database tables, and sits at the center of a web of extensions — payment gateways, subscriptions, shipping — each written against specific Woo versions. Updating it like any other plugin works right up until it doesn’t, and when it doesn’t, it’s your checkout that goes. This builds on the basic WordPress update routine; you’ll need a staging site, WP-CLI helps, and you should already know how to run a test order.

Read the WooCommerce changelog first

Before touching anything, read the release post at developer.woocommerce.com. You’re looking for two phrases: “database update” (means the update migrates order data — plan for it in step four) and “template changes” (means your theme’s Woo template overrides may now be outdated — see fixing outdated templates if that flag comes up after the update). Five minutes of reading tells you whether this is a quiet month or a careful one.

Check every extension’s compatibility line

Woo extensions declare which core version they’ve been tested against. On the Plugins screen, WordPress flags Woo extensions with compatibility warnings before you update — read them. Then check the changelog of each extension that touches money (payment gateway, subscriptions, taxes, shipping) for the Woo version you’re moving to. An extension that hasn’t shipped a release in a year is a yellow flag; a payment gateway that doesn’t list your target Woo version is a hard stop. Wait for the extension, not the other way around — a store that’s one version behind is in far better shape than one whose gateway just broke.

Update on staging: core, Woo, extensions, theme

On your staging copy, in this order — each layer is written against the one before it:

wp core update
wp plugin update woocommerce
wp plugin update --all
wp theme update --all

Watch the output for errors, then load the staging admin. If anything fataled, staging just earned its keep and you get to find the culprit at zero cost.

Run the database update deliberately

If the release migrates data, the admin shows a banner: “WooCommerce database update required.” Don’t click it reflexively — take a fresh database backup first, because this step rewrites order data and it only runs forward. Then run it and watch it finish:

wp db export pre-wc-migration-$(date +%Y-%m-%d).sql
wp wc update

On a store with years of orders this can take a while. Let it run; interrupting a half-done migration is how quiet updates become long evenings.

Test-order the staging checkout

Now prove it: run the full test-order loop on staging with your gateway in test mode — order, confirmation email, order records, refund. Checkout is exactly where a Woo/extension version mismatch shows up, and staging is exactly where you want to meet it. Spot-check a few old orders in the admin too; the database migration touched them, and you want to see totals and statuses intact.

Ship, then test-order live

Push staging to live (or repeat the same updates on live), run the database update there, and then — this is the step that separates updated from verified — place a real small order on the live store and refund it. A completed live order with a matching gateway record and a confirmation email in your inbox is your proof the store still does its one irreplaceable job. Log what you updated and when; a store stays alive on exactly this kind of boring, dated evidence.