Shutting down a product is a project, not an announcement. The teams that do it well spend more effort on the shutdown than they did on most feature launches, because a bad shutdown is the last thing your users remember about you.

Give real notice

30 days is the bare minimum for a free tool. For anything paid, or anything storing user data, give 90 days. If people built workflows or businesses on top of you, they need time to find and migrate to a replacement — not just export their data, but actually re-integrate somewhere else.

Announce on every channel you have: email to every account (not just active ones — that lapsed user might come back next month expecting the tool to exist), an in-app banner, a pinned post on your status page or blog, and if you have one, a note in the API response itself.

X-Product-Sunset: 2026-12-15
X-Product-Sunset-Info: https://example.com/shutdown

Data export, done right

“You can export your data” is not the same as “you can actually use your data somewhere else.” Export in a format the next tool can import, not a format that’s technically complete but practically useless.

• CSV or JSON, not a PDF, not a proprietary binary.
• Include IDs and relationships, not just display values — if a user has orders linked to customers, export both tables with the keys intact, not a flattened report.
• Give a real download, not “email support to request an export.” At scale that queue becomes the bottleneck that makes people miss your deadline.
• Test the export yourself by importing it into a plausible replacement tool before you ship it. If you can’t get your own export to round-trip, neither can your users.

Refunds

Refund anything unused. Pro-rate the current billing period back to the shutdown date at minimum; refunding the full last payment is better and cheap goodwill if your cash position allows it. Don’t make users ask — refund automatically and email confirmation. A user who has to fight for a $12 refund from a company that’s shutting down anyway will tell that story for years, disproportionate to the amount.

Communicate why, briefly

You don’t owe a full post-mortem, but “we’re shutting down” with no reason reads as evasive and invites speculation. One or two sentences: ran out of runway, acquired and the product’s being folded in, not enough usage to justify the maintenance burden. Whatever it is, say it plainly. People are far more forgiving of an honest “this didn’t work out” than of vague corporate language.

Keep the lights on for reads, at least

If it’s technically feasible, keep the service in read-only mode past the write cutoff — let people log in and export data for a grace period even after new writes stop. This catches the users who missed every earlier notice and log in on day one of the outage confused. A hard, simultaneous cutoff of both writes and reads maximizes the number of people who lose data through simple inattention, not through fault of their own.

Open source it if you can

If the product isn’t a security or liability risk to keep alive, and you have no reason to protect the IP, open-sourcing the code lets your most committed users self-host or fork it. You don’t owe this, but it costs you little once the product is dead and it converts a chunk of “you abandoned us” sentiment into goodwill.

The gotcha

The account that goes quiet for eight months and logs in during your shutdown window is not an edge case — it’s normal usage for anything that isn’t checked daily. Plan your timeline and exports around that user, not around your active daily users who’ll see the first email and move fast.