When a service shuts down, what actually happens to your data?

When a service ends, the operational decisions a company makes about user data tell you more about the company than the announcement does. Mozilla's Pocket shutdown was professional. Stadia issued full refunds for hardware and software — virtually unprecedented at this scale. Some shutdowns offer no export at all.

This post is a field guide to the four patterns we keep seeing, what each pattern signals about the company's posture, and the concrete steps to take when you spot the early warning signs.

The four patterns

Pattern 1 — Graceful Export

The company announces the shutdown well in advance, provides an export tool that produces files in a format you can actually use, keeps the export window open until the service goes fully read-only, and migrates anything that can be migrated to a successor product.

Canonical example: Mozilla Pocket (2025). Announced 22 May 2025. Service shut 8 July 2025. The API followed on 12 November 2025. Throughout the nine-month wind-down, users could:

• Export every saved article as a CSV (URL, title, time added, tags) or HTML bookmarks file.
• Continue using the app and browser extension until the cutoff.
• Migrate to recommended alternatives — Mozilla pointed at Raindrop and Instapaper.

What this pattern signals. The company has institutional memory of past shutdowns and treats wind-down as a product release in its own right. The team that owns the shutdown is staffed and accountable through the final cutoff. There is usually a public timeline document, updated as dates approach.

What to do as a user. Run the export within the first month of the announcement. Don't trust that the API will outlast the consumer UI — Pocket's API died four months after the consumer service. Test that your export files actually open in your replacement tool before deleting your original account.

Pattern 2 — Refund-and-Forget

The company can't gracefully preserve the data because the data was tied to the running service in a way that doesn't translate. Instead the company refunds purchases — sometimes very generously — and accepts that the data goes with the service.

Canonical example: Google Stadia (2023). When Google announced Stadia's closure on 29 September 2022, they also announced that every purchase — hardware, games, and DLC — would be refunded by the 18 January 2023 shutdown date. This was unprecedented at the time for a streaming-game platform. Save data was lost; no equivalent exists on any other platform.

What this pattern signals. The company is willing to spend significant money to manage the reputation cost of the shutdown. Often happens when the product is high-profile but the data is genuinely not portable (cloud-bound game saves; ephemeral session data; consumed credits).

What to do as a user. Read the refund policy carefully — the date by which you must claim usually trails the shutdown date by months, but not forever. Screenshot anything you want to remember (saved games, leaderboards, social profiles) before the service goes dark.

Pattern 3 — Archive-Then-Vanish

The service goes read-only first. The community can still see the content for months or years. Then the archive itself is finally shut down with much less notice.

Canonical examples. Vine shut its iOS/Android apps on 17 January 2017 but kept vine.co running as a "Vine Archive" until April 2019 — over two years of read-only access. GeoCities shut on 26 October 2009, with archive teams scrambling to preserve content before the deletion deadline; the Archive Team mirror preserves a substantial fraction. Google Code went read-only on 25 January 2016 and continues to host its archive at code.google.com/archive.

What this pattern signals. The company recognises the cultural value of the content but cannot justify ongoing investment. The product is often community-generated content with no clear successor.

What to do as a user. Don't rely on the archive lasting indefinitely. Take your own copy. Web archive teams (Archive.org's Wayback Machine, Archive Team) are excellent backstops but can't guarantee preservation of every page. If you have specific URLs you care about, save them to Wayback explicitly via web.archive.org/save.

Pattern 4 — Hard Cut

The service shuts on a specific date. There is no export. There is no refund. Sometimes there is no warning at all.

Canonical examples. Friendster (2015) — gaming pivot ended; user data was not preserved across the cutoff. Yik Yak (the original, 2017) — anonymous posts couldn't be exported and weren't preserved. Klout (2018) — public influence scores vanished on the GDPR enforcement date without an export path.

What this pattern signals. Either the company doesn't have the resources to plan a graceful shutdown, the data is sensitive enough that preserving it would create legal exposure (post-GDPR especially), or the data has no obvious portable form.

What to do as a user. If you suspect a service is in this category, treat now as the shutdown date. Anything you want from the service, take a screenshot or copy/paste today.

How to spot which pattern applies before the announcement

The single most useful signal is whether the service has ever published an export tool. A service with a polished export tool will almost certainly use Pattern 1 when it shuts down. A service that has actively not offered export — even after years of user requests — will almost certainly do Pattern 3 or 4.

The second signal is the financial structure. If users have paid money for the service (Stadia, premium subscriptions, in-app purchases), Pattern 2 is more likely. Investors and PR teams push hard for refunds at this scale.

The third is the parent company's reputation. Companies with a long shutdown history (Google, Microsoft) have institutional memory; small companies and startups often do not.

The API death timeline

The single most underappreciated aspect of shutdowns: the API often dies before the user-facing service.

For Pocket the API kill date was 12 November 2025 — over four months after the consumer service shut on 8 July 2025. Plenty of users had migrated their Pocket data via the API in the meantime, only to discover later that they hadn't actually grabbed everything. By the time they tried to re-export, the API was gone.

The lesson: export first, validate the export, then migrate. Never start the migration with the export.

A working migration checklist

Whenever a service you depend on announces a shutdown, run this list within the first 14 days of the announcement.

1. Read the official timeline document. Look for these dates: feature freeze, read-only date, consumer shutdown, API kill, archive end. They are often not the same.
2. Find the export tool. If there isn't one, immediately switch to scraping your own data via whatever public means exist (the official UI, the unofficial API, a screen-recorder if necessary).
3. Run the export. Save the raw export files in two separate locations (local disk + cloud backup). Don't trust that the export tool will still work tomorrow.
4. Inspect the export format. Open a sample. Does it contain everything you remember saving? Often it doesn't — exports frequently omit attachments, comment threads, or tags depending on the service.
5. Pick a replacement. Test it with a small subset of your data before you bulk-migrate.
6. Plan for what won't transfer. Followers, likes, view counts, integrations — these almost never migrate. Decide whether you care.
7. Migrate.
8. Hold the original account. Until the actual shutdown date, keep the original account active in case you need to re-export. Don't proactively delete.
9. After the cutoff: confirm your data is intact in the replacement. This is where Pocket users who relied solely on the API got burned — they thought they were done, but the API kill four months later took their unfinished migration tooling with it.

Specific exports to make right now

If you use any of these services today, the export should already exist. Pulling it as a one-time hygiene exercise costs nothing and gives you a snapshot you can compare against if anything ever changes.

• Google Takeout — every Google product you use, takeout.google.com. Run it once a year.
• Apple ID Data and Privacy — privacy.apple.com. Covers iCloud, App Store, Apple Music history.
• Twitter / X archive — Settings → Your account → Download an archive of your data. Includes every tweet you've ever posted as JSON.
• GitHub user migration archive — Settings → Account → Export account data. Doesn't include private repo contents but does include profile data, follows, stars.
• Discord data request — Settings → Privacy & Safety → Request all of my data. Takes up to 30 days to deliver.
• Notion — Settings & members → Workspace → Export all workspace content. Choose Markdown + CSV.

Frequently asked

If a service announces a shutdown, do I get my data back automatically?

No. There is no legal obligation in most jurisdictions to provide data on shutdown — GDPR's portability right is about ongoing service, not service-ending. Some companies provide export tools as a goodwill gesture; many don't. Treat any post-announcement export as something you need to initiate.

What about end-to-end encrypted services? Can I really recover my data?

Often, no. E2EE services where only the user has the keys (Signal, ProtonMail with old crypto, some Skype variants) can't decrypt your data even with full server access. If the service shuts and your local client decrypts on-device, your local copy is what you have. If the keys are on their servers, the company can usually offer an export; if not, the data is gone with the service.

My export contains JSON. How do I actually use that in another tool?

Look for an importer in the replacement tool. Most reputable services advertise import paths from common competitors. If nothing exists, the conversion is usually a one-time scripting job — JSON → CSV is 20 lines of Python; JSON → another service's API is more but tractable. The Status Meaning Decoder and our Notebook cover specific conversion patterns.

What if the service goes down before I export?

You're partly out of luck, but not entirely. (1) Check the Wayback Machine for any public pages you authored — it captures a substantial fraction of the public web. (2) Many shutdowns include a final-call email with one last download link; check spam folders. (3) Some services run a "post-shutdown export" period where the consumer service is gone but a barebones download endpoint stays alive. Stadia, for instance, allowed save-data downloads after game refunds were processed.

What we're watching now

A few sunsets are already on the calendar; treat any data you have in them as time-bound.

• Google Fitbit Web Challenges — sunsets 30 June 2026. If you have years of step-count challenge data, export now.
• GitHub Issue Projects (classic) — sunsets 24 August 2026. Migration tool to the new Projects exists; run it well before the cutoff.
• Google Jamboard app — already partially retired; data export was offered through 2024 and many users missed it.

The Shutdown Radar tracks active sunset countdowns with the data-export deadlines surfaced inline. The Internet Graveyard catalogues the finished ones with each service's data outcome marked — useful both as a historical reference and as evidence when someone tells you "this service will be fine."

The most useful frame for thinking about your data: anything you can't export today is at the mercy of whoever runs the service. The closer to a key part of your life it is, the more this matters.