Moving off Gumroad: your subscribers cannot come with you

What you can actually take with you

Gumroad does give you a real export, worth taking properly rather than in a hurry on your last day. From the Sales tab you can download a CSV of customers and their purchases for a date range you choose; if it is not ready immediately it gets emailed to you.

Two details catch people out. The timestamps are in UTC, so add a day of buffer at each end of the range or you will clip orders off the edges. And filters applied on screen do not carry into the export.

• Comes with you: purchase ID, item name, buyer name, buyer email, sale price and tax
• Comes with you: your product files, prices and sales copy
• Comes with you: reviews, as quotable text rather than portable ratings
• Stays behind: card details, tokens, anything a new processor could charge against
• Stays behind: billing anniversaries — each cycle restarts when that person re-subscribes
• Stays behind: the payment relationship, and the revenue until people rebuild it

The one genuine exception, and why it is probably not yours

There is a real, documented way to move saved cards between processors, worth recognising when somebody waves it at you. Stripe calls it a payments data import: the old processor sends your card data to Stripe's migrations team, encrypted with a published PGP key, never by ordinary email.

The conditions are the point. Your old processor has to agree and take part, and many require the account owner to request it. It is PCI-regulated work, with compliance shared between both parties. The old provider might take days or weeks to hand the data over; Stripe then typically imports within ten business days of a correct file.

Even then, subscriptions are not included. You rebuild them separately, then confirm the old processor has cancelled all automatic billing. The route assumes you hold the merchant relationship at both ends, and a creator selling through Gumroad does not — Gumroad is the merchant — so there is no vault of yours to move.

Which is why anyone promising to migrate your subscribers without your subscribers doing anything is either describing something else, like a customer list, or selling you something.

Run both platforms in parallel, not one after the other

The biggest avoidable loss in a subscription migration is announcing the move before the new thing can receive anybody. People meet a half-built page or a confusing login, and you have spent your one moment of attention on a bad impression. There is no second announcement.

So the order is fixed. The new platform goes live and tested before anyone hears the word moving — subscribe to it yourself with a real card and check the receipt, the login, the delivery and the cancellation. Then leave Gumroad running untouched while you move people across. Paying for both for two months is the cheapest part of this.

• Build the new offer and subscribe to it yourself, end to end
• Leave the Gumroad product live and billing as normal
• Move subscribers across in waves over six to eight weeks
• Unpublish on Gumroad after wave one, so nobody new lands there
• Keep Gumroad open until the last renewal date has passed
• Only then close it deliberately

Waves, not a single announcement

Start with twenty or thirty of your most engaged members — the people who open everything and would forgive a broken link. You are not only moving them; you are finding the problems in your new flow that you cannot see yourself.

Wave two is everyone whose renewal falls in the next month. The renewal date is the natural moment to ask: the charge is already on their mind, the decision is open, and nothing overlaps. Timing the ask to the billing cycle rather than your calendar is worth several points on its own.

Wave three is everybody else, spread over the following weeks and nudged twice. Wave four is the quiet ones, who have not opened an email in six months and are paying out of inattention. They convert worst, and that is fine — some of what looks like migration churn is a subscription that had already ended in every sense but the charge.

Why we are moving, please re-enter your card fails

That email fails for three reasons. It turns your administrative problem into their chore. It asks for card details in a message about a change of billing system, which is exactly the shape of a phishing email people have learned to distrust. And it carries no deadline, so it joins the pile of things to do later, which is where subscriptions quietly die.

The version that works gives a reason that benefits the reader, makes the new thing concretely better in one specific way, holds the price where it was, and answers the double-billing fear in the first three lines rather than the last. Never migrate and raise the price in the same message. You can do both, but not at once and not be believed.

• Line one: what is changing, and when their current billing stops
• Line two: they will never be charged twice, said plainly
• Line three: the one thing that is better for them
• The link, alone, to a page with their email already filled in
• A deadline that is real, because their old billing genuinely ends
• A reply address that reaches a human, because some will ask first

Closing the Gumroad side without stranding anyone

The endgame turns on one distinction. Deleting a membership product cancels every active subscription on it, so those customers stop being charged and lose access. Unpublishing keeps existing members billed and able to reach their files while stopping anyone new from joining.

So unpublish is the tool for the migration, and delete is only for the very end. Cancelling everybody on day one feels decisive and is the most expensive move available to you: a subscriber whose payment has already stopped has been handed a free exit at the moment you were about to ask them for effort. Keep the old product billing until the last renewal has passed, then close it.

When not to move at all

Here is the arithmetic almost nobody runs. Four hundred members at ten dollars a month is forty-eight thousand a year. Suppose moving saves ten percent in fees — four thousand eight hundred a year, a genuinely good saving. Now assume a twenty-five percent loss, an ordinary result rather than a disaster: a hundred people, twelve thousand a year, gone permanently.

The fee has to be catastrophic to beat that, and it rarely is. The larger and steadier your base, the worse the case for moving — the opposite of how it feels, because a large base is when fees start to look outrageous. The cheap time to move is early. At forty subscribers the loss is ten people and you replace them in a month.

Reasons that justify the cost: you are being forced out by a policy change, a shutdown or restricted payouts; you need something the platform cannot do and will not add; or you are rebuilding the offer anyway, so subscribers would have re-decided regardless. Reasons that do not: fees alone on a healthy base, a nicer interface, an affiliate link.

A fair way to decide

Write two numbers down before anything else. What the move earns or saves you over twelve months, in money rather than in feelings about the interface, and the annual value of a quarter of your subscribers. If the first does not comfortably beat the second, the move is a hobby funded by your own revenue. If it does, commit properly, because a hesitant migration loses more people than a decisive one.

And accept the frame: migrating a subscription base always costs subscribers. The question was never how to move without losing anybody — it is whether the gain is worth the cost, and whether you would rather pay it now or at three times the size in two years. If you do go, go somewhere you will not have to leave again; you can run a storefront, digital products and subscriptions in one place free at onesol.io.