How long your data outlives the account

Cancelling a subscription starts two clocks, not one. The first is how long you can still get your work back. The second is how long the vendor keeps it after you cannot. They are rarely the same number.

Four vendors publish both clocks in some form, and all four were read against their live documentation on October 25, 2026. The numbers are specific enough to plan around, which is why they belong in an evaluation rather than a crisis.

Microsoft publishes the whole staircase, including the step where only admins can read

The Microsoft 365 for business documentation names four states in order. "A subscription goes through the following statuses over the course of its lifecycle: Active > Expired > Disabled > Deleted."

The durations are published as a table. For all subscription terms bought directly, Expired lasts 30 days and Disabled lasts 90, with Deleted marked as the "Terminal state".

What changes at each step is access, not storage. During Expired, "data is accessible to all". During Disabled, "data is accessible to admins only" and "users can't access apps in Microsoft 365".

Apps do not fail outright; they degrade. They "eventually move into a read-only, reduced functionality mode and display Unlicensed Product notifications".

The last step is the one to read before a migration. At Deleted, "data is deleted and Microsoft Entra ID is removed, if not in use by other services", and the subscription "can't be reactivated".

One warning deserves to be quoted whole. "If a subscription is deleted, adding a new subscription of the same type doesn't restore the data that was associated with the deleted subscription."

The start of the clock is also defined, and it is not the day you click cancel. "The Expired status starts on the subscription end date, not the date that you turned off recurring billing."

GitHub promises 90 days, with two exceptions that matter

GitHub's Terms of Service give one number for deletion. Barring legal requirements, "we will delete your full profile and the Content of your repositories within 90 days of cancellation or termination".

The parenthesis in that sentence is the honest part. Deletion applies "though some information may remain in encrypted backups".

The export window runs on the same clock as the deletion. GitHub will make "a reasonable effort" to provide a copy of account contents, and "you must make this request within 90 days of cancellation, termination, or downgrade".

So the recovery clock and the deletion clock are the same 90 days, and both are measured from an event you may not have scheduled. A downgrade counts as the trigger too.

Then there is the exception that no deletion request can reach. "We will not delete Content that you have contributed to other Users' repositories or that other Users have forked."

For a small team that published anything in public, that sentence is the real retention policy. The copy you control goes; the copies other people made stay.

Anthropic publishes a 30-day floor and two much longer ceilings

The commercial retention article starts with the short number. For API users, "we automatically delete inputs and outputs on our backend within 30 days of receipt or generation", with four stated exceptions.

Those exceptions are a longer-retention service under your control, an agreement to the contrary such as a zero data retention agreement, enforcement of the usage policy, and compliance with law.

For products that save conversations, deletion is a two-step event. A deleted conversation is "removed from your chat history immediately" and "deleted from our back-end storage systems within 30 days".

The ceilings are where the policy stops being short. If a chat is flagged by automated trust and safety systems, inputs and outputs are kept "for up to 2 years" and classification scores "for up to 7 years".

Feedback has its own clock, and it is longer than most people expect from a thumbs-down. "Where you have provided feedback to us... we retain data associated with that submission for 5 years."

On the consumer side the training clock is separate again. If you allow chats to improve the product, the company "may retain your data in a de-identified format for up to 5 years in our model training pipelines".

And turning the setting off is forward-looking by its own terms. Data "will still be included in model training runs that are already in progress, or in models that have been trained".

Notion stacks two 30-day windows, and sells history by the tier

Notion's help documentation describes a trash period followed by a second, quieter one. "By default, pages will remain in Trash for 30 days before they are permanently deleted from Trash."

The sentence after it is the interesting one. "Once pages are permanently deleted from Trash, they are retained for 30 days before they become inaccessible to all users, even workspace owners."

So the word "permanently" marks the end of your access, not the end of storage. Enterprise workspace owners may customise these settings, per the same page.

Version history is a priced feature rather than a property of the data. Past versions are available "7 days if you're on a Free Plan", 30 on Plus, 90 on Business and "any number of days" on Enterprise.

That turns a recovery question into a plan question. The length of your undo is set by the invoice, not by the incident.

Five numbers to write down before you sign

• When the clock starts. Subscription end date at Microsoft, cancellation or downgrade at GitHub.
• How long you can still read. 30 days for everyone at Microsoft, then 90 for admins only.
• How long you can still export. 90 days at GitHub, and the request is on you to make.
• How long they keep it anyway. Encrypted backups at GitHub; 2 years for flagged content and 7 years for safety scores at Anthropic.
• What no deletion reaches. Forks and contributions to other accounts at GitHub; de-identified data already in a training run.

What follows in practice

Export on the day you decide, not on the day you cancel. Two of these four vendors tie the recovery window to an event that may already have passed when the decision is made.

Then separate the two clocks in your own notes. A vendor that deletes in 30 days and keeps safety scores for 7 years is not contradicting itself, and a buyer who conflates the two will misread both.

Finally check who can read during the quiet period. An admin-only window is useful if your admin is still employed, and worthless if the person who left owned the account.

What the vendor does with the same material while the account is live is a different question, examined in who reads what you type and the default that trains on your work.

Leaving is harder than the marketing suggests, which is the argument in the claim that you can always switch. A vendor can also end a dependency without your consent, as in when a model you built on is retired.

Retention sits next to the uptime and credit language discussed in an SLA credit is not a refund.

Subject pages for two products whose retention terms are quoted here: Claude and GitHub Copilot. Plan structure sits in our primer on AI assistant pricing for small teams.

A deletion policy is not a promise to forget you. It is a schedule describing when you stop being able to look, and a separate list of reasons the record stays.

Sources, read against the live page markup on October 25, 2026: Microsoft Learn on subscription expiry; GitHub Terms of Service, effective April 27, 2026; Anthropic Privacy Center retention articles dated July 2, 2026; Notion Help on deleting and restoring content.