Shutting a small tool down: what do I actually owe the people who have data in it?

The order matters more than anything else, and the rule is: build the export before you announce.

Announcing first produces a wave of people asking how to get their data out, discovering there is no good way, and being angry at exactly the moment you have no leverage and no time. Ship the export, test it, then tell people.

A reasonable sequence:

1. Build and test a complete export. Everything they put in, in a format they can actually use: not a database dump. Open formats, one download, and check it by importing it somewhere yourself.
2. Stop new signups and stop charging. Nobody should be paying for a service with a known end date, and turning off billing early buys you enormous goodwill for very little money.
3. Announce, with a date, and say plainly what happens and when.
4. Remind them. At least twice more before the date. People ignore the first email.
5. Keep it read-only for a period after the end, if you can afford to.
6. Then turn it off and delete.

The read-only period is the cheapest kindness available, the running cost with nobody writing is usually small, and it catches everybody who missed the emails.

On how much notice, from the receiving end of a two week shutdown that was genuinely disruptive: more than you think, and much more for anything a business depends on.

Rough guidance:

A consumer tool: a couple of months is decent.

Anything a business uses in its workflow - three months minimum, because they have to find a replacement, migrate, and retrain people, and none of that is at the top of anybody's list.

Anything integrated into other systems - longer, because somebody has to write code.

Four years of accumulated data pushes it towards the longer end, since exporting and rebuilding elsewhere is real work for them.

What made the shutdown I lived through bad was not the closure. It was two weeks notice, an export that only produced part of the data, and no reply to questions. Any one of those fixed would have made it fine.

What helps enormously and costs nothing: name a replacement. Even better, help people move: a migration guide, or an export in a format the obvious alternative can import. People remember that, and if you build something else later they will turn up.

And answer the emails. The volume is smaller than you fear and silence is what turns disappointment into resentment.

The last obligation, and the one people skip because the interesting part is over: actually delete the data.

Holding sixty customers' material indefinitely on a server you no longer maintain is a liability with no upside. It is not your data, you have no reason to keep it, and an unmaintained system holding other people's information is exactly what gets breached.

So:

Say in the announcement when data will be deleted, and then do it on that date.

Delete the backups too, which is the step that gets forgotten. A deleted database with six months of retained snapshots is not deleted.

Cancel the third party services that also hold copies: analytics, error tracking, email tools, whichever payment processor. Each of those has some of your customers' information.

Keep only what you genuinely have to for accounting or legal reasons, which is usually transaction records rather than user content, and keep it somewhere appropriate rather than in a dormant application database.

One practical note: take one final backup and keep it briefly, a few weeks past the deletion date: for the person who emails saying they missed everything. Then destroy it. That single retention has saved a customer relationship for me more than once, and keeping it longer than that turns a kindness into a liability.