| Quick Answer:
Dunning management is a critical part of subscription migration because it controls what happens when recurring payments fail, including retries, payment-failure states, customer notifications, and cancellations. During a migration, payment tokens, retry schedules, subscription statuses, and billing rules can stop working even when subscriptions still appear active. This guide explains how to protect recurring revenue recovery during a subscription migration by mapping your existing dunning workflow, migrating the data it depends on, testing failed-payment scenarios, and monitoring the first two renewal cycles. |
Your migration went well. Every subscription came across, the statuses read Active, and scheduled renewals are firing on time. But weeks later, the deposits don’t match the forecast.
That is what makes migration-related dunning failures dangerous: nothing necessarily breaks visibly. WooCommerce Subscriptions can continue triggering scheduled events while treating the site as staging, preventing payments and renewal emails from being processed.
Nothing errored. Nothing alerted. The renewals simply collected nothing.
Dunning management is the system that recovers a subscription payment after it fails: the retry schedule, the payment-failure states, the customer notifications, and the status changes that decide whether a declined card becomes a renewal or a cancellation. In a subscription migration it is the piece most likely to survive on paper and stop working in practice, because nothing about its failure throws an error.
If you are moving a book of a few thousand subscribers, this is not a rounding error. It is the difference between recurring revenue recovery continuing on day one and finding out at the first renewal date that it didn’t.
A migration breaks dunning management by making it inapplicable, not by breaking it
For a $1M+ WooCommerce business, the risk depends on what kind of migration you are actually doing — and how much recurring revenue sits behind the subscriptions.
The staging flag — infrastructure and domain migrations. If a store moves servers or changes its live URL, WooCommerce Subscriptions can interpret the new environment as a staging site. Scheduled subscription events still run, but renewal payments and subscription emails are not processed in staging mode. For a high-volume subscription store, the storefront can look completely healthy while automatic recurring revenue has quietly stopped.
The manual-renewal fallback — large subscriber bases. WooCommerce supports manual renewals, and subscriptions can require customers to pay renewal orders themselves. That becomes a very different revenue model when applied to hundreds or thousands of existing subscribers: instead of automatic collection, recovery now depends on customers receiving the renewal request and completing payment.
The detached token — payment and gateway migrations. WooCommerce specifically identifies subscription migrations, changes to an associated Stripe account, and staging-site renewal processing as scenarios that can leave a payment method invalid or detached from the customer at the gateway. For businesses moving payment infrastructure while carrying a large recurring-revenue base, this can turn an apparently successful migration into a silent renewal failure.
The common thread is not that the subscription disappeared. The business lost the mechanism that made the subscription collectible.
That is why dunning has to be treated as part of the migration itself — especially for subscription-heavy ecommerce businesses where a small percentage of affected renewals can translate into a meaningful recurring-revenue gap.
Also Read: Subscription Billing Migration: 7 Decisions to Lock Before You Migrate
Migrating active subscriptions?
Don’t leave failed-payment handling until after the move. See how we migrate subscriptions while protecting billing continuity.
What dunning management protects, and what a subscription migration puts at risk
Dunning is not one setting. It is five moving parts that only work as a sequence, and a migration can sever any one of them independently.
| What it is | What it does | What migration threatens | How you’d notice |
| Retry schedule | Re-attempts a failed charge on a defined timetable | Resets to the new platform’s default, or stops applying entirely | Renewal revenue drops without a matching rise in cancellations |
| Payment-failure states | Holds the subscription in a recoverable state between attempts | Statuses map incorrectly, so subscriptions land as active or expired instead of on-hold | Members keep access while unpaid, or lose it on the first decline |
| Customer notifications | Tells the customer to update their card | Templates don’t carry over, or fire for every subscriber at once | Silence, or a support queue on day one |
| Status transitions | Decides when a failure becomes a cancellation | Grace periods and hard-cancel rules reset to defaults | Involuntary cancellations spike in month one |
| Historical failure data | Tells you which customers are already at risk | Left behind as “old platform data” | Your at-risk list starts empty |
Map your existing dunning workflow before the subscription migration starts
The useful exercise here takes an hour and almost nobody does it: write down, on one page, what your current platform does when a payment fails.
Six things to document before anyone touches data:
● How many retry attempts, and on what timetable
● What state the subscription enters after each failed attempt
● Which email fires at which attempt, and what it says
● At what point access, delivery, or service is actually suspended
● At what point the subscription hard-cancels rather than staying recoverable
● Who on your side gets alerted, and at what threshold
Most teams discover they cannot answer three of the six. That is not a failure of record-keeping. It is that dunning has been working invisibly for years, so nobody had a reason to write it down.
You cannot verify that a behavior survived a migration if nobody wrote down what the behavior was. This document is what turns post-launch testing from “does it look right” into “does it match”.
We at WisdmLabs picked this up on a migration for MollyMy, a subscription wellness brand. After their platform move, recurring payments stopped processing entirely and the system failed silently, so subscribers were manually repurchasing instead of renewing.
The root cause was metadata linking subscriptions to their payment methods, missing or corrupted in the migrated data. Restoring those links returned them to a 100% renewal success rate in 30 hours.
The fix was fast. Finding it was the expensive part.
Don’t migrate subscription records without migrating the revenue lifecycle around them
A subscription record is not a subscription. It is a row that points at several other things, and the pointers are what break.
Six data sets have to arrive together for recurring revenue recovery to work on day one:
● Payment tokens and gateway customer IDs. Without these, there is nothing to charge.
● Renewal dates and billing anchors. A shifted anchor charges people early, which produces disputes rather than revenue.
● Subscription status, mapped deliberately. Not guessed at by an importer.
● Historical payment and failure data. This is your at-risk list.
● Coupon and discount state. A subscription renewing at the wrong price is a failed renewal with extra steps.
● In-flight retry state. The one nearly everyone forgets.
On cutover day, some subscriptions may already be on attempt three of five. If that state does not migrate, the sequence can restart or disappear entirely.
None of this shows up on a standard data-mapping spreadsheet, which is why moving to WooCommerce with a live subscription book is a different exercise from a catalog migration.
| 🛒 Subscription ecommerce scenario
A store running monthly replenishment boxes migrates to WooCommerce. Products, customers, and subscriptions all land correctly. What doesn’t land: the gateway tokens for roughly a third of the book, because the old processor scoped them to the previous domain. Those subscriptions are set to manual renewal, which is the documented fallback. WooCommerce’s own migration guide describes the sanctioned workaround: deliberately trigger failed renewals so customers are prompted to re-enter card details. That is a defensible plan when it is deliberate. It becomes a revenue problem when customers discover it through a failed-payment email on launch day. |
You Might Like: WooCommerce Subscriptions Migration: 5 Key Steps
Test failed-payment scenarios before you cut over, not after
Most migration testing verifies that a payment succeeds. That test passes on a broken dunning setup, because a successful charge never touches the recovery path.
Test the failures instead. Run each of these on the new platform before go-live, with a real gateway in test mode, and check the whole sequence rather than the first response.
| Test scenario | What should happen | What a silent failure looks like |
| Card declined | Retry fires on schedule, subscription goes on hold, first dunning email sends | Order fails once, no retry, no email |
| Expired card | Same as decline, with the update-payment-method link working | Email sends with a broken or old-domain link |
| Insufficient funds | Full retry window runs, then a renewal invoice | Subscription cancels on first failure |
| 3DS or SCA challenge | Customer is prompted and can complete it | Charge fails with no customer-facing prompt |
| Subscription mid-retry at cutover | Sequence continues from where it was | Sequence restarts, or the subscription drops out of it |
| Lapsed subscription in grace period | Access continues, billing retries | Access revoked immediately |
| Subscription with an active coupon | Renews at the discounted price | Renews at full price, customer disputes |
The reason to test the failure rather than the success is that this class of bug does not announce itself. A clean import log is not evidence that dunning works. It is evidence that nothing crashed.
If your renewal or gateway logic is customized, these tests also identify where migration-specific development is required.
Test the renewal—not just the migration
Staging, data validation, payment testing, and subscription checks help catch problems before they affect paying customers
Monitor the first two renewal cycles like a launch, because that’s when this surfaces
Migration go-live checklists usually end at go-live. For a subscription business, the meaningful test happens weeks later.
Five things worth instrumenting from day one:
● Renewal success rate against a pre-migration baseline. You need the baseline captured before you move. Afterwards is too late.
● Count of subscriptions on manual renewal. This number should match what you expected. If it drifts upward after launch, something is converting them.
● Retry attempt volume. Zero retries is not good news. It usually means nothing is entering the retry path.
● Dunning email send volume. Compare against your historical rate, in both directions.
● Involuntary cancellations. Segment these away from voluntary ones or the signal disappears.
Two cycles rather than one, because monthly plans surface in week four but quarterly and annual plans do not. A book with meaningful annual revenue can look completely healthy for eleven months.
| ⚠️ The false all-clear
The subscriptions dashboard is not enough. A subscription can remain marked Active in WooCommerce while billing has paused at the gateway. Compare your WooCommerce subscription data with actual gateway transactions and renewal revenue. The ledger, not the dashboard, is your post-migration source of truth. |
Also Read: Migrate at the Wrong Time, and You Lose the Season
| Will your dunning survive the cutover? A 6-question pre-migration check
Answer yes or no. Count the “no” answers. 1. Can you produce your current retry schedule as a document: how many attempts, over how many days, and what happens at each step? (Y/N) 2. Do you know, by count, how many subscriptions will land on manual renewal after the move? (Y/N) 3. Has your payment gateway confirmed in writing that your tokens transfer? (Y/N) 4. Have you run a deliberate failed payment on the new platform and watched the full retry sequence finish? (Y/N) 5. Do you have a pre-migration baseline renewal success rate to compare against afterwards? (Y/N) 6. Is one named person responsible for watching renewals through two full billing cycles after go-live? (Y/N) 0–1 no. Recovery is already part of your migration plan. Validate the failed-payment scenarios and monitor the first renewal cycle closely. 2–3 no. The gaps are specific and closable before cutover. Document the retry workflow and get the token confirmation in writing before you set a date. 4–6 no. Failed-payment recovery is not yet under control. Resolve the gaps before setting the cutover date. |
Conclusion
A subscription migration succeeds when the money keeps arriving, not when the records arrive.
Before setting a cutover date, verify the recovery path: document your retry workflow, confirm how payment tokens will be handled, test deliberate payment failures, and assign someone to monitor renewals after launch.
The question is not whether your subscriptions migrated. It is whether the system that collects money from them when a card fails migrated with them.
Start by running one deliberate failed payment on the new platform before cutover, and watching the full retry window play out end to end.
If that test has never been run on the platform you are moving to, plan your subscription migration with WisdmLabs →
FAQ
Will our saved payment methods transfer when we migrate subscriptions to WooCommerce?
Sometimes, and you want it confirmed in writing rather than assumed. Gateways often enforce domain-level validation or token scoping that invalidates credentials after a move. Where tokens cannot transfer, WooCommerce’s documented fallback is manual renewal plus a prompt to re-enter details. Plan that as a campaign, not a discovery.
What happens to a subscription that’s mid-retry when we cut over?
Usually nothing good, unless you planned for it. A subscription sitting on attempt three of five either restarts the sequence, re-emailing a customer who already knows, or drops out of the retry path and cancels. The practical fix: pause new failures for a short window before cutover and let in-flight sequences finish.
Why did renewals stop even though every subscription shows Active?
This is the signature symptom of a migration-related dunning failure. The most common cause on WooCommerce is the staging-site flag: when the site URL changes, Subscriptions can treat the site as staging, fire scheduled renewals, and attempt no payments. Check the stored site URL, and read your renewal ledger rather than the dashboard.
Should we change our retry schedule during the migration or after it?
A migration is a reasonable time to widen it, since you are validating the whole recovery path anyway. Recurly’s recovery research found invoice recovery rates are lowest where the dunning window is seven days or less, roughly the WooCommerce default. Change one thing at a time: validate retries work as-is, then adjust.
