Build a pre-update compatibility checklist for a WooCommerce subscription store

Short answer: write down what can change, test it on staging, then decide

Before you update WooCommerce, WooCommerce Subscriptions, WooCommerce Memberships, your payment gateway, your theme or WordPress itself, do four things: list exactly what you run, copy the store to staging, run the same short set of renewal and access tests, and make a go or no-go decision against criteria you wrote down in advance. The rest of this page explains each part. The same logic is built into the first category of the book, and you can run it from the complete book.

1. List what you run

You cannot judge compatibility without knowing versions. Record, with the date: WordPress, WooCommerce core, WooCommerce Subscriptions, WooCommerce Memberships, your payment gateway plugin and any extension that touches carts, checkout, emails, taxes, currencies or product bundles. Note the PHP version your host runs and whether High-Performance Order Storage (HPOS, the WooCommerce setting that stores orders in dedicated tables rather than in WordPress post tables) is on. WooCommerce documents that Subscriptions is compatible with HPOS, but each of your other extensions must be checked individually.

Also record how you take renewals: which gateway, whether it supports automatic renewals for each payment method you accept, and how many subscribers use automatic versus manual renewal.

2. Read the release notes for the right things

WooCommerce publishes release notes on its developer blog, and the releases page lists every core version with its date. Skim them for changes to checkout (including the Blocks-based checkout), orders, the REST API, scheduled actions and payment-related behavior. WooCommerce states that Subscriptions generally supports the most recent core version and the previous one, so if you are more than one release behind, plan the update in steps rather than in one jump. Note anything you cannot interpret and bring it to your developer or support contact before the update, not after.

3. Build a staging copy you can trust

Staging is a full copy of your site, database included, that cannot charge real customers or email them. Put the copy behind a password, switch your gateway to its test or sandbox mode, and make sure outgoing email is disabled or redirected. Subscriptions has its own handling for sites that look like duplicates or staging copies, so read the staging section of the WooCommerce Subscriptions documentation before you rely on a copy: you do not want a copy to process live renewals. Take a fresh full backup of the live store first, and confirm you can restore it. The staging article explains the trade-offs.

4. Run the same test sequence every time

1. Browse and buy a subscription product as a new customer (test payment). Confirm the subscription, the order and the confirmation email.
2. Trigger a renewal for that subscription and confirm a renewal order is created and paid.
3. Simulate a failed payment with your gateway’s test card for declines and confirm the retry and email behavior matches your settings.
4. Change the payment method on a test subscription from the My Account page.
5. Cancel, pause and reactivate a test subscription.
6. As a member, open restricted content and confirm access is granted. Change the subscription status and confirm access follows as you intend.
7. Check the WooCommerce scheduled actions screen for failed or past-due actions.
8. Check the checkout in both the classic and the Blocks-based form if you use either.

The detailed procedure for steps 2, 3 and 7 is in the renewal testing workflow.

5. Define a go or no-go gate before you start

Write the pass criteria first: every step above passes, no new failed scheduled actions, no new PHP errors in the logs, and the checkout completes on the devices your customers use. If one step fails, you either find the cause and retest, or you postpone. Do not decide the gate after seeing the result; that is how a failed test gets explained away.

6. Update live in a quiet window, then watch for 48 hours

Update during your lowest-traffic period, with the backup taken just beforehand. For the next 48 hours, watch the things that fail quietly: renewal orders created on schedule, scheduled actions, gateway logs, support inbox and member-access complaints. Renewals are scheduled for specific times, so the first real proof is the first batch of renewals after the update. If you see a pattern, stop updating further components and work through the recovery steps rather than changing several things at once.

What to record every time

Keep a short log: date, versions before and after, what you tested, what failed, what you changed, and who approved the go decision. When something breaks months later, this log is the fastest way to find the update that did it.

Where to look up compatibility

Use sources that name versions. The WooCommerce Subscriptions documentation states its requirements and compatibility (including its HPOS compatibility and the rule that it generally supports the latest core version and the previous one). The Memberships documentation does the same for that extension. Inside WordPress, the extension’s changelog lists what changed in each version, and WooCommerce’s settings include a features screen that can warn when an installed plugin is not marked compatible with a feature such as HPOS. For your gateway, use the vendor’s own documentation, because only the vendor can tell you which payment methods support automatic renewals in which version.

If a plugin has no compatibility statement at all, treat it as unknown, not as safe. Unknown items go to the top of your staging test list.

Items teams forget

• Theme overrides of WooCommerce templates (cart, checkout, My Account, emails). A core or extension update can make an old override out of date.
• Custom code snippets that change prices, taxes, shipping or subscription behavior. Ask whoever added them to list them.
• Caching rules. My Account, checkout and member-only pages should not be served from a shared cache. A cache change after an update can lock members out or show someone else’s page.
• Webhooks and integrations (email platforms, accounting, CRM, fulfilment) that listen to order or subscription events.
• Tax and currency plugins that recalculate recurring orders. See the book’s categories 15 and 17.
• Email templates and settings for renewal, failed-payment and expiry notices.

A sample go or no-go record

Decision: go, postpone or roll back; name of the person who decided; date and time.

If a test fails

Do not push on to the next test and hope. Note the exact error text and the step, restore the staging copy to its starting state, and repeat the failing step once to see whether it is consistent. Then isolate the cause by disabling extensions on staging one at a time, or by updating components one at a time, until the failure appears. When the cause is a version combination, you now know what to postpone. When the cause is a setting, you now know what to change before the live update. The book’s category 19 covers testing extensions after core updates in detail.