What Happens to Your Planning Data When an App Shuts Down

When a productivity app shuts down, data portability decides what survives

Service shutdowns are frequent enough that the IndieWeb community maintains a year-by-year site-deaths catalog. Recent entries include Tome (2026); Refern, Fitocracy, and Read.cv (2025); and Cohost, 8Tracks, Mozilla.social, Post News, and TinyLetter (2024). A productivity app shutting down is a routine event, not a rare one, and the more services your planning system depends on, the likelier you are to live through one.

For planners, the stakes run past losing a task list. Years of routines, completion history, and carefully tuned setups live inside these tools, and when the service goes, all of it goes with it. Data portability, the practical ability to get your data out in a form you can still use, is what separates a manageable migration from a total loss. This article covers what is typically lost when an app sunsets, which export formats survive, which backup habits are worth building, and which ownership questions to ask before you commit recurring work to any tool.

The anatomy of an app sunset

Most shutdowns follow the same arc: an announcement, a usually brief export window, servers going offline, then deletion. What survives is decided by the export window, not by account ownership. You can own your data legally and still not own it practically, because a right to your data is worth only what the export path delivers before the deadline.

Most people learn the export window exists when the announcement arrives, which leaves little time to act. The loss is also bigger than the visible task list. What disappears includes the routine setup accumulated over years, the completion history that showed what actually got done, and the tuning that made the system feel fair rather than arbitrary.

Two shutdowns, two exit paths

Pocket and Wunderlist bracket the range of exit experiences: a generous but expiring export window in one case, a migration-only funnel in the other.

Mozilla shut down Pocket for good on July 8 and switched the read-it-later app to export-only mode. Users had until October 8 to export their saves, after which all accounts and data were deleted. Three months is a comparatively generous window, and it still expired. Deleted data does not negotiate with deadlines.

Wunderlist shut down on May 6, 2020, five years after Microsoft's 2015 acquisition, and after that date to-dos stopped syncing. The official announcement said lists could be imported into Microsoft To Do only "for a period of time," implying that exports to any other app would end with the service. That is a migration-only exit: the vendor built one path, and it led to the vendor's own successor. Anyone who wanted their lists in a third-party tool had to move them before May 6.

The pattern generalizes. Wait until the end of a shutdown, and you accept whatever exit path the vendor designed, on the vendor's schedule.

What generic exports strip from a rotation system

Standard shutdown advice stops at exporting your tasks. For anyone running recurring work, that advice quietly fails. A generic task export, usually a CSV of current tasks, preserves item names and due dates. It drops everything else: how many times each item has run, weight drift, shuffle and fairness state, streak history, and capacity settings.

For a rotation-based system, the state is the system. Restoring the list without the rotation state means starting from zero even though the export technically succeeded, because years of fairness tuning cannot be re-typed from memory. The fairness a rotation encodes, the guarantee that the furnace filter gets its turn and no chore quietly never comes up, lives in the state rather than in the item names.

Cycles approaches this from the opposite end. It is a rotation planner built around strict, weighted, and shuffled rotations, so run counts, weights, and fairness are core product data rather than export afterthoughts.

Export planning data: formats that survive and formats that strand you

Open, structured, self-describing formats survive: CSV, JSON, and plain text or Markdown. Any tool can read them decades later because the meaning travels with the file.

Four kinds of export strand you:

• proprietary databases
• encrypted server blobs
• PDF or screenshot "exports" that flatten structure
• vendor-specific backup files that only the vendor's own app can re-import

The practical test is simple: if you can open the file in a text editor and still tell what it means, it survives. Structure is the differentiator. An export that preserves the look of your planner but not the relationships between the data is a photograph of your system, not a backup of it. Before committing to any planner, check whether its export is a real data file or a vendor-locked courtesy.

Why cloud-first planning apps carry structural risk

Shutdown risk in cloud-first apps is architectural, not a matter of vendor goodwill. In cloud apps the server holds the primary, authoritative copy of your data, and the copy on your device is a subordinate cache. Any change has to reach the server before it counts as having happened, which means your planning system depends, by design, on someone else's infrastructure staying online.

In its essay on local-first software, the Ink & Switch research group states the consequence plainly: "If a service shuts down, the software stops functioning, and data created with that software is lost." Even a successful export only partly repairs that, because "without the servers there is normally no way for you to continue running your own copy of that software."

If you are weighing cloud convenience against local control, the tradeoffs between local-first and cloud planners deserve their own evaluation.

Local-first software treats planning data as yours

The architectural answer to shutdown risk has a name. "Local-first software" was coined in a 2019 paper by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan at the Ink & Switch research lab and presented at the ACM SIGPLAN Onward! conference. The term covers software that prioritizes local storage and local networks over remote datacenter servers.

The manifesto's ideals include working offline, collaborating across multiple devices, and improving security, privacy, long-term preservation, and user control of data, all while retaining full ownership of the files you create. Its central argument is that collaboration and ownership are not in conflict; you do not have to trade one for the other.

For planners, that argument carries weight. Cycles is a local-first rotation planner: planning decisions happen without a server round-trip, and your planning data belongs to you rather than to a service you rent. A vendor's exit timeline matters far less when the authoritative copy of your system already lives where you decide it lives.

Backup habits worth building

Data protection works best as recurring work, not as a panic response to a shutdown email.

• Build a quarterly export ritual instead of exporting once and forgetting it.
• If you use a rotation planner, add the export to the rotation itself. Recurring work deserves recurring protection.
• When you export planning data, choose open formats: CSV, JSON, or Markdown. Vendor-specific backup files strand you even when they are available.
• Keep the files somewhere you control, independent of the app's own ecosystem.
• Open each export and check it. A backup you have never opened is an assumption, not a safety net.

Six data portability questions to ask before you commit

Run these against any planner you use now or consider adopting:

1. What export formats does it offer: open and self-describing, such as CSV, JSON, or plain text, or proprietary files only its own app can read?
2. Does the export preserve full state, including history, run counts, weights, and settings, or just current list names and due dates?
3. Where does the authoritative copy of your data live, on your device or on the vendor's servers?
4. Does the app work offline, or does every planning decision require a server round-trip to count?
5. What is the documented shutdown story: a clear export path with a reasonable window, or a migration-only funnel to the vendor's chosen successor?
6. Can you back up on your own schedule, at any time, without waiting for a shutdown announcement to unlock your data?

Pair these with the privacy questions worth asking before tracking your life in an app. Both sets are easier to answer before you have committed years of history.

Real ownership is architectural, not legal

Shutdowns are a when, not an if; the site-deaths catalog keeps growing year after year. Practical ownership has three parts: open export formats, a backup ritual you have actually tested, and a tool whose architecture does not depend on someone else's servers. For recurring work specifically, protecting the rotation state rather than just the task list is what separates "my system survived" from "I'm starting over."

Cycles is built local-first so your planning data stays yours. See how Cycles works.