Software companies
What happens to your data when you cancel Zendesk, Jira or GitHub?
By SourceX Editorial · Updated
Short answer
When you cancel a help desk or issue tracker such as Zendesk or Jira Cloud, the vendor usually keeps your data for a limited window set by its terms, then deletes it. Code hosts such as GitHub often treat ending a paid plan differently from deleting an organization. The rule: export everything, with attachments and linked history, before you cancel.
Key takeaways
- Retention after cancellation is set by each vendor's terms, plan and data processing addendum, not by a common industry rule.
- Migration tools often move open work and recent history only, leaving closed records behind.
- A git clone does not include pull request review comments, issues or wikis held by the hosting platform.
- Exports lose much of their value if ticket, issue and commit identifiers are not preserved.
- Verify record counts and attachments against the live system before the cancellation notice goes in.
What happens to data after a SaaS subscription ends?#
Data in a canceled SaaS subscription usually moves through a short series of stages: active, then suspended or read-only, then deleted from production systems, then purged from backups. The length of each stage is set by the vendor's terms of service, its data processing addendum and its help center articles, and it can differ by plan.
Data processing addendums commonly require the vendor to delete or return customer data at the end of the service. That protects you from data lingering, but it also means the vendor is under no obligation to keep your archive once the window closes.
Read the difference between canceling a subscription, closing an account and deleting a workspace. Vendors use these words for different actions, and only some of them start the deletion clock. When a help center article and the contract disagree, the contract and DPA usually govern, so ask the vendor to confirm the timeline in writing.
| Stage | What you can usually do | What to confirm |
|---|---|---|
| Active subscription | Full export through the UI and APIs | API rate limits and export formats on your plan |
| Notice given, term running | Same as active until the end date | Renewal date and notice period |
| Suspended or read-only | Sometimes view or export, sometimes nothing | Whether admins keep access and for how long |
| Deleted from production | Usually nothing | Whether the vendor offers paid restoration |
| Purged from backups | Nothing | The vendor's stated backup retention |
How do help desks, issue trackers and code hosts differ?#
Help desks, issue trackers and code hosts store different kinds of history, so the export risks differ even when the cancellation rules look similar. The table summarizes the usual pattern; check each vendor's current documentation for the actual windows on your plan.
| System type | Examples | Usual pattern after cancellation | Easy to lose in export |
|---|---|---|---|
| Help desk | Zendesk, Intercom, Freshdesk | Account closed, then deleted after a vendor-set period | Attachments, internal notes, side conversations, satisfaction ratings, audit events |
| Issue tracker | Jira Cloud, Linear | Site deactivated, then deleted after a vendor-set period | Change history, comments, attachments, links to commits and pull requests |
| Code host | GitHub, GitLab | Ending a paid plan may only remove features; deleting the organization removes repositories | Pull request reviews, issues, discussions and wikis outside the git repository |
| Team chat | Slack | Downgrading can limit how much message history stays available; deleting the workspace removes it | Private channels and direct messages, depending on plan and policy |
| Docs and wiki | Confluence, Notion | Deleted with the site or workspace | Page history, comments and embedded files |
Why linked history is the part most often lost#
Linked history is the most valuable and most fragile part of a software company's records. A support ticket that mentions a Jira key, a Jira issue that references a pull request, and a pull request whose review thread explains the fix together tell the story from customer problem to shipped change. Each piece lives in a different system with its own export.
When systems are exported separately and the identifiers are stripped or renumbered, those links break. A migration tool that assigns new ticket numbers in the destination help desk is a common cause. Keep the original identifiers as fields in every export, even if the new system does not need them.
Code hosts deserve special care. Cloning a repository captures commits and messages, but review comments, issue threads and discussions stay on the platform and need a separate API export.
Export-before-cancel checklist#
An export before cancellation should be planned backward from the notice date, not left to the end of the term. Large accounts can take a long time to export through rate-limited APIs, and attachments are often fetched one by one.
- Read the vendor's terms, DPA and help center pages on cancellation, and record the stated retention window.
- Confirm an admin account that does not depend on single sign-on, so access survives an identity provider change.
- List every object type: tickets, comments, internal notes, attachments, users, organizations, custom fields, tags, macros and audit events.
- For code hosts, export issues, pull requests, review comments and wikis in addition to cloning repositories.
- Keep original identifiers and timestamps in every file.
- Store exports in company-controlled storage with restricted access and a written record of location.
- Compare record counts and sample attachments against the live system's own reports.
- Only then submit the cancellation or let the term lapse.
Who should own the shutdown decision?#
The shutdown of a system of record should have one accountable owner, usually the COO or whoever runs operations, with IT, finance and legal each signing off on their part. IT runs the export, finance tracks the renewal date and notice period, and legal checks retention duties, litigation holds and customer contract commitments before anything is deleted.
Write a short closure record for each system: what was exported, when, by whom, where it is stored and what was intentionally left behind. That record answers the questions that come later from auditors, acquirers or a data licensing review.
Watch the order of operations. Turning off single sign-on, removing the last admin or letting the payment card lapse before the export is verified can lock the team out of its own data earlier than the contract term suggests.
Illustrative: a scheduling software company retires its help desk#
Illustrative: a fictional scheduling software company decides to move from Zendesk to a help desk bundled with its new CRM. The vendor's migration tool copies open tickets and recent history, and the project plan assumes the old account can simply lapse.
During a pre-cancellation review, the COO notices that closed tickets with linked Jira issues, many describing bugs and the fixes that resolved them, are not part of the migration. The team runs a full API export of tickets, comments, internal notes, attachments and audit events, keeping the original ticket IDs and Jira keys, and stores it in a read-only cloud bucket owned by the company.
Record counts are checked against Zendesk's reporting before notice is given. The archive stays available for support analytics, and later for a metadata-only data licensing fit check.
How SourceX fits a system retirement#
System retirements are one of the most common moments when a software company reviews what its old records are worth. SourceX's fit check works from metadata only, such as system names, date ranges and record families, so the company can assess an archive before or after shutdown without sharing files.
If a package proceeds, the Supply step of the SourceX five-step transaction starts from the company's own exports. Large archives stay in the seller's storage or ship on encrypted drives, because SourceX never hosts multi-terabyte datasets.
Frequently asked questions
Does a migration tool move all of my history?
Often not. Many migration tools prioritize open and recent records, skip some object types such as audit events or side conversations, and renumber records in the new system. Ask the tool provider for a list of what is and is not migrated, and run a separate full export of the old system before cancellation.
Can the vendor restore data after it has been deleted?
Sometimes, within a limited period and occasionally for a fee, but no vendor is obliged to do so unless the contract says so. Once data is purged from backups it is gone. Treat any restoration option as an emergency measure, not a plan.
Is a third-party backup service a substitute for an export?
A backup service can be a good safeguard, but check two things before relying on it: whether it captures every object type you need, and whether you can still access and export the backup if you cancel the backup service too. Many backups are designed for restoring into the same system, not for long-term archives.
What about data held by marketplace apps and integrations?
Apps installed in Zendesk, Jira or GitHub often store their own data on the app vendor's infrastructure, such as time tracking, test results or custom fields. That data may not appear in the core export. List installed apps and check each one's export and deletion terms.
Do we have to delete exported data after cancelling?
Not automatically, but your own retention policy, customer contracts and privacy laws may require deleting personal data you no longer need. Decide what to keep, why and for how long, and document the decision with legal before the archive becomes long-term storage.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.