Subscription Migration Nightmare? How to Save Your Mid-Dunning Customers on Shopify

Hey there, fellow store owners! Let's talk about something that can really keep you up at night when you're planning a big move for your subscription business: what happens to those customers who are right in the middle of a dunning sequence?

You know, the ones whose payment just failed, and they're waiting for the next retry attempt from your current subscription app. It's a surprisingly common concern, and it recently sparked a really insightful conversation in the Shopify community that I wanted to dive into. Because, let's be honest, losing those customers isn't an option.

The Great Dunning Migration Mystery: What Really Happens?

Our community member, lumine, kicked off the discussion with a pretty eye-opening observation: "The part that surprised me: the new app almost never inherits the retry position. Even when the saved card token moves over cleanly, the dunning state (this sub failed once, next retry in 3 days) lives inside the old app’s billing engine, not in Shopify or the gateway."

This is a crucial point. Many of us assume that if the payment method (the card token) moves, everything else follows. But as lumine points out, that specific "dunning state" – the count of failed attempts, the scheduled retry dates – is often hard-coded into your old subscription app's internal logic. It's not something native to Shopify itself, nor is it typically stored by the payment gateway in a way that's easily transferable between different subscription apps.

The "Fresh Active Sub" Trap

So, what does this mean for your customers? It means that when you migrate them to a new subscription app, those mid-dunning subscribers often land in their new home looking like completely fresh, active subscriptions. Your new app's default dunning flow won't pick up where the old one left off; it'll just start treating them as if their payments are due for the first time, not as someone whose payment already failed once or twice.

As Moss_Mercury wisely added, "I wouldn’t assume they’re written off, but I also wouldn’t assume the dunning state carries over cleanly. In most migrations the important pieces are the saved payment method + recreated subscription contract; the exact retry history/status can depend on the subscription app and gateway setup." They hit the nail on the head: the contract and payment method are key, but the history? That's where it gets fuzzy.

Your Proactive Plan: Don't Lose Those Recoverable Customers!

The good news, as the community made clear, is that these customers are often recoverable, but it requires a proactive approach. You can't just set it and forget it. Here’s a step-by-step plan, combining the best insights from our community discussion, to make sure your mid-dunning cohort doesn't vanish into thin air:

1. Before You Migrate: Identify Your Dunning Cohort.
   • Go into your old subscription app and export a detailed list of every single subscriber currently in a failed payment or dunning state. This is your critical "recovery list." Include customer names, email addresses, subscription IDs, and ideally, their current dunning status (e.g., "failed once, next retry in 3 days"). This list is your safety net!
2. Plan Your Import Strategy with the New App.
   • When you're working with your new subscription app provider, specifically ask them how they handle importing subscribers who were previously in dunning. Can you import them as "paused," "failed," or with a specific tag? This is crucial for distinguishing them from genuinely active subscribers.
   • As lumine suggested, if possible, you might want to "tag that cohort before you migrate, bring them in paused." This gives you control.
3. Payment Gateway & Token Migration Check.
   • Confirm that your saved payment method tokens (the encrypted card details) will migrate cleanly. This is generally smoother if you're sticking with the same payment gateway (e.g., staying with Stripe, just moving apps).
   • If you're switching gateways, be prepared: "The ones that genuinely vanish are usually where the card token didn’t migrate (different gateway), and those need full re-collection," warns lumine. This means you'll have to ask those customers to re-enter their payment details.
4. Post-Migration Verification & Recovery.
   • Once the migration is complete, don't just breathe a sigh of relief. Head straight to your Shopify admin and use the "Failed payment" customer filter. This will help you identify any customers whose payments immediately failed after the migration. Compare this list against your pre-migration dunning cohort.
   • For those customers you identified as mid-dunning pre-migration (and ideally imported as paused or tagged):
     • Run a deliberate recovery charge or a targeted win-back sequence. This is your chance to manually kickstart their payment process or send them a specific "update your card" link. Don't just let them get swallowed by the new app's default flow, which might not be appropriate for their actual status.
   • For any customers whose payment tokens didn't migrate (especially if you switched gateways) or who slipped through the cracks:
     • You'll need to send them specific card-update links to re-collect their payment information. Moss_Mercury emphasized having a "clean recovery list to send card-update links instead of losing them completely."

The key takeaway here is planning and verification. Don't assume anything will transfer perfectly, especially when it comes to the nuanced state of a dunning customer. By taking these proactive steps, you're not just preserving revenue; you're also ensuring a smoother experience for your customers, even if they hit a payment snag.

It's always amazing to see how the community comes together to share these real-world "gotchas" that you won't find in a standard migration checklist. This kind of shared experience is invaluable, and it's how we all get better at running our stores.