A Platform You Sell On Is Shutting Down. Now What?

Published July 31, 2026

Part of: Choosing Your Tools — our full guide on this topic.

Disclosure: Some links below are affiliate links. If you sign up through them we may earn a commission at no extra cost to you. We only recommend tools we'd genuinely suggest to a friend. See our full disclosure.

Every guide to changing platforms — including the one on this site — opens with the same question: is switching actually worth it? It is good advice. It stops a lot of pointless work. And it is completely useless on the morning you open an email that says the service you sell on is closing.

That guide’s final step is to run both tools in parallel and only cancel the old account once the new one is live and tested. That advice, too, quietly assumes something that has just stopped being true: that you own the clock.

This is the other kind of migration. Not the one you chose, for reasons you weighed, on a timetable you set — the one you were given, for reasons that are not about you, with a deadline someone else picked and can move. The steps are not the same steps, the order is different, and the thing that actually costs you money is not the thing you will spend the first day worrying about.

The quick version

• Export first, decide second. Exporting is the only step whose availability gets worse with time, and it is not the step you will instinctively do first.
• The date on the announcement is probably not your deadline. Read-only, export-off, and customer-lockout dates all land earlier and matter more.
• Assume the money does not transfer. If they processed payments, every active subscriber will have to subscribe again, by hand, on purpose. That is the real cost of the event.
• Split urgent from important. Reaching your list and taking money move in days. Courses, funnels and automations can be rebuilt over weeks.
• Time pressure selects for lookalikes, and the closest lookalike often carries the same risk you are currently living through.
• Tell your buyers before they find out — a dead link they discover themselves costs far more than an awkward email you send.
• This is not the backup problem. Having a copy of everything and having a business that still runs are separate, and you can have either without the other.

First, the boundary: this is not the backup article

It is worth being precise about this, because the two get run together and the confusion is expensive.

Keeping your own copy of what platforms hold for you answers exactly one question: do I still have the data? It is a good habit, it is cheap, and if you did it, today is much easier. But that article is careful to say what it does not buy, and it is worth quoting against itself here — it does not protect your revenue, and your copy of the subscriber list does not send email.

This article is about the other question: does the business still run? And the two are independent in both directions.

You can have an immaculate backup and a dead business. Every file on your machine, every subscriber in a tidy CSV — and no one is being charged, nothing can be bought, and the URL on your last four months of posts returns nothing. Nothing is lost and nothing is working.

You can also, less comfortably, have no backup at all and come through fine, if you rebuilt live before the door closed and pulled everything across while the account was still open. That is a worse way to do it and not a recommendation. It is proof that the two problems are genuinely separate: one is about possession, this one is about continuity.

If you have the backup, you skip roughly the first hour of what follows. You do not skip the rest.

The first hour: export before you think

The instinct on reading the announcement is to start researching where to go. Resist it for one hour.

Exporting is the only part of this whole event that is on someone else’s switch. Everything else — choosing a platform, rebuilding pages, emailing customers — is available to you at any time between now and forever. The export is available until it is not, and you will not get advance notice of that date the way you got advance notice of the closing date.

Three things make the window narrower than the announcement implies:

Wind-downs happen in an order the platform chooses. Functions get switched off in a sequence that suits their engineering and support load, not your migration. New signups usually go first, integrations and API access somewhere in the middle, and the account frequently drops to read-only well before the final date. Export tooling is not guaranteed to be the last thing standing.

Everyone is exporting at once. Export jobs that normally return a file in seconds are being requested by the entire customer base in the same fortnight. Queues lengthen, jobs fail and need re-running, and support — which is also winding down — gets slower exactly when more people need it.

Support capacity falls as the deadline approaches, not after it. The staff who would help you recover a failed export are, in many closures, among the first things to go.

So: take everything, now, while the taking is easy. The three-pile sort is the fast way to know what to grab — but under time pressure, the short version is the subscriber list with its fields and tags, the customer and order records with dates and amounts, the full text of anything you wrote directly into the platform, any testimonials people left on your product pages, a written description of what each automation does, and a list of every published URL.

And open the files. An export you have not opened is a filename, not a backup — this is the single most common way people discover, three weeks too late, that the download contained addresses and nothing else.

The dates that actually bind you

The announcement gives you one date in bold. It is rarely the important one.

Find out, specifically, and in writing if you can:

• When new customers can no longer sign up or buy. This is the date your revenue from that platform effectively ends, and it is often much earlier than the closure. Everything after it is admin.
• When the account goes read-only. After this you can look but not change — which means no exports you have not already taken, no edits to pages, and no fixing a broken link that is now permanent.
• When exports stop working. Sometimes stated, often not. If it is not stated, assume it is the read-only date and act accordingly.
• When people who already paid lose access. This is the one with an obligation attached, and it drives your customer communications more than any other date.
• What happens to the URLs. Whether they go dead, redirect somewhere, or sit there showing something you would rather they did not.

Two things about this schedule are worth internalising. First, it can move earlier. A wind-down that is going badly gets compressed; one that is going well almost never gets extended. Plan against a date before the one you were given.

Second, the URLs outlive the platform in other people’s records even when they die on the web. They are in your old emails, in your social posts, in anything anyone linked to. That is a problem for later, but it starts accruing on the day the pages go dark, so put your URL list somewhere you will find it.

The layer nobody plans for: the money

Here is where a forced migration stops resembling a chosen one.

If the closing platform only held content — a page builder, a host, a course player — you have a work problem. Rebuilding is tedious, it is measured in days, but nothing is bleeding while you do it.

If it also processed the payments, you have a different problem, and it is the one that costs real money.

Stored card details sit under the platform’s merchant arrangement, not yours. The near-universal position is that they cannot simply be handed to you when the service ends, which means the recurring charges stop when the platform stops, and every active subscriber has to subscribe again, somewhere else, by an act of will. Their subscription does not move. It ends, and you invite them to start a new one.

That single fact is the whole financial story of the event, because it converts something silent and automatic into a decision each customer now has to take deliberately. Some meaningful share of people paying you every month are doing so partly out of inertia — not because they are being deceived, but because it is genuinely worth the small amount and never rises to the level of a decision. Ask them to re-decide and some of them will decide no. Ask them badly, or late, or in an email that reads like an apology, and more of them will.

There are two things to do about it, and neither is technical.

Have the new payment path live before you send the email. One message, one link, one working checkout. If the sequence is “we are moving, details to follow,” you have spent the attention you will only get once and asked people to remember you in a fortnight. They will not.

Give them a reason that is about them. The move is not interesting to your customers; the continuity is. What they want to know is whether the thing they pay for still exists, whether they lose anything, and what precisely they have to click. A short message that answers those three and nothing else outperforms a long one explaining the situation.

Occasionally there is a formal migration path to a named successor, sometimes with the billing carried across. If that exists, read exactly what it covers before relying on it — in particular whether it moves the payment method or only the customer record, because those are very different offers. But build the plan on the assumption that nothing financial transfers. That plan still works if you turn out to be lucky; the reverse is not true.

Choosing where to go, with a gun to your head

Now the decision — and the trap in it is specific enough to name.

Urgency selects for lookalikes. Under time pressure the cheapest option to evaluate is the one that most resembles what you are losing, because it requires the least new thinking: the same feature set, the same layout, the same mental model. That instinct is efficient and it is also how people end up on a similar company at a similar stage carrying a similar risk, and doing this again in two years.

The way to get speed without inheriting the problem is to split the move by urgency rather than by category:

Moves in days — the two things that must not stop:

1. The ability to reach your list. Somewhere you can import addresses and send. Nothing fancy.
2. The ability to take money. One working checkout for the thing that earns most.

Moves over weeks — everything else: courses and their hosting, funnels, the automations, the pages you were proud of, the design. All of it is rebuildable at leisure and none of it is losing you money while it waits.

Doing it in that order buys you the thing you actually lack, which is not time but calm. Once the list is reachable and money can arrive, the deadline stops being an emergency and becomes a project.

For the second half, the honest question is whether this is also the moment to consolidate. If you were paying for a page builder and an email tool and a checkout, and one of the three has just vanished, rebuilding the same three-part stack is a decision worth making on purpose rather than by default. An all-in-one with a genuine free tier — Systeme.io is one — puts the list, the automations, the pages and the checkout under a single account, which in this specific situation has a benefit beyond the bill: it is one migration instead of three, and one thing to learn in a week when you have no spare weeks. (Disclosure: that is an affiliate link — if you sign up we may earn a commission, at no cost to you. See our affiliate disclosure.) The counter-argument is real too, and it is the one this whole article is about: consolidating puts more of your business behind a single account. The free-tool stack roundup is the place to weigh that properly, and it is worth an evening even now.

What is not worth doing this week is a full re-evaluation of your stack. You are not in a good state to make that decision, and it will still be available to you in six months when you are.

What you owe the people who already paid

From your buyer’s side, the platform was never part of the deal. They bought from you. The infrastructure was an implementation detail they neither chose nor agreed to, and its ending is not something they consented to on your behalf.

That framing settles most of the awkward questions:

• Tell them before they find out. A customer who reads it in your email is being looked after. A customer who clicks a link they paid for and gets nothing has been let down, and the distinction is entirely about who spoke first.
• Say what they lose and by when. Vagueness reads as evasion even when it is just uncertainty. “I do not yet know what happens to the discussion area, and I will tell you by Friday” is a better message than silence until Friday.
• Give them the thing, not the promise. Where you can hand over files directly — the PDFs, the videos, the templates — do it, rather than promising a new login later. It ends the obligation cleanly and it is one fewer thing you have to build under pressure.
• Refund where that is the honest answer. If someone bought access to something ongoing three weeks ago and the ongoing part is ending, the money is not really yours. Offering before being asked costs a fraction of what being asked costs.

What you are strictly required to do varies a great deal by where you and your customers live and by what you actually promised at the point of sale, so the legal shape of it is a question for a qualified adviser in your jurisdiction, not for a general article — the same caution that applies to what your terms say and how you handle customer data. Nothing here is legal advice.

Every bullet above is a standard you are applying under pressure, having had it imposed on you. It is worth noticing that the same four rules are exactly what somebody would want from you if you were the one deciding to stop — which is the whole of closing a membership, where you are the platform and there is nobody upstream to blame for the timing.

The part that is not jurisdiction-dependent: this is one of the few moments when ordinary competence is visible. Most customers have been on the receiving end of a service ending badly. Handling it plainly is unusual enough to be remembered, and a surprising number of the people who re-subscribe are re-subscribing to the way you handled it.

When this is not the situation you are in

Three things get mistaken for a shutdown and are different problems with different answers.

An acquisition is not a closure. A tool changing hands usually means it keeps running under a new name and a new roadmap. It is a prompt to reconsider, not an evacuation, and the mistake is treating it as urgent — the alternatives-after-an-acquisition case is the one this site has actually documented. Do the export anyway; that is free. Do not do the migration until there is a reason.

A free tier being withdrawn is a pricing event. Your data is fine, your customers are fine, and the question is whether the new number is worth paying. That is a subscription review, calmly, not a rebuild.

A feature being removed is a scope event. Annoying, sometimes genuinely disruptive, but the platform is still there and so is everything on it. Work out what specifically broke before concluding you have to move. Worth noticing what this feels like from the receiving end, because you will eventually be on the other side of it: removing something people were relying on is a change made underneath paying customers, and the reason it stings here is exactly the reason it needs doing carefully there.

And the near-opposite case, which looks identical from where you are standing and is a different job entirely: the platform is fine and it is you who has been removed from it. A suspension gives you no notice period, no export window and — the part that changes the tactics most — no deadline at all to plan against, because there is no date on it. What to do when your account is suspended is that playbook, and almost every step below inverts in it.

And one that runs the other way: if the platform is fine and it is your product that has stopped selling, that is a retirement decision — a different article and a completely different set of moves. The distinction is who is ending what. Here the product is fine and the shelf is being removed. There the shelf is fine.

Furthest from this article, and the one that inverts every instruction in it: the platform is fine, your account is fine, and you have decided to stop. Nobody hands you a notice period there and nobody owes you an export — you are the one who owes, to everyone who ever bought from you. Closing down an online business is that sequence, and the first step is the one nobody does first.

Afterwards: the one change worth making

The tempting conclusion is own everything, depend on nothing. It is not practical and mostly it is not even correct — the reason to use platforms is that they do difficult things well, and self-hosting the lot means becoming a systems administrator instead of running a business.

The useful version is narrower. Having just lived through it, you now know something you could not have known abstractly: which single layer, if it went, would actually end you.

For most solo businesses it is two things. The ability to reach your audience, which is why the email list keeps being the answer — not because email is virtuous, but because it is the one audience asset where the reachability itself is portable. And the ability to take money, which is worth understanding well enough to reconstruct somewhere else in a day.

Everything above those two is genuinely replaceable, and treating it as replaceable is what stops this from becoming a rule that you must never depend on anything. You are allowed to depend on things. Just know which dependency is load-bearing, keep that one somewhere you control or can rebuild fast, and let the rest be someone else’s problem to run well.

The other cheap habit, if you do not already have it: a place of your own that you actually own, even a small one. Not as your main storefront necessarily, but as the address that survives every platform decision anyone else makes — the one URL you can put in an email that will still resolve after the next announcement.

The order to do it in

1. Export everything, today. Subscribers with fields, customers with orders, published text, automation logic, URL list.
2. Open every export. A file you have not opened is a filename.
3. Get the real dates — signup-off, read-only, export-off, customer-lockout, URL fate — and plan against a date before the earliest one.
4. Confirm what happens to active subscriptions. Assume nothing transfers unless it says so in writing.
5. Stand up the two urgent things: somewhere to send email from, and one working checkout.
6. Write the customer email — what changes, what they lose, exactly what to click — and do not send it until the link in it works.
7. Send it early. Before they find out, not after you feel ready.
8. Handle the people who paid: files handed over, access restored, or refunds offered.
9. Rebuild the rest over weeks, in order of what earns.
10. Then, and only then, decide whether the stack you have rebuilt is the one you actually want.

The bottom line

A chosen migration and a forced one look similar on a checklist and are entirely different events. The chosen one is a project with a benefit at the end of it, and every guide to switching platforms is written for that. The forced one has no benefit — the best available outcome is that nothing gets worse — and it is run against a clock you do not control, which is why the ordinary advice inverts. You export before you decide instead of after. You move the money before the content. You accept a worse choice made quickly over a better one made in three weeks, because the three weeks are not on offer.

And you tell people early, which is the part that most affects how much of your income survives the event. The technical migration is a few days of dull work. The re-subscribe decision, taken independently by every customer you have, is the thing that decides what the business looks like on the other side — and the only lever you have on it is having behaved well while it was happening.