Software companies
Do you need to back up Jira, GitHub and Zendesk?
By SourceX Editorial · Updated
Short answer
Yes, you need your own backup of Jira, GitHub and Zendesk: the vendors keep the services running, but recovering from your own deletions, cancellations and retention rules is largely your job. Zendesk starts permanent deletion of service data 90 days after an account is canceled, and Atlassian keeps deactivated paid-plan site data for 60 days. Back up full linked history, not just current records.
Key takeaways
- SaaS vendors work on a shared responsibility model: they protect the service, and you protect your history from your own deletions and cancellations.
- GitHub organization owners can restore deleted repositories within 90 days, but tickets removed by a Zendesk deletion schedule cannot be restored.
- Native tools have limits, such as one stored Jira Cloud backup file at a time and Zendesk exports that support must enable.
- The links between tickets, issues, pull requests and releases are what make history useful in audits, diligence and later data licensing.
Why vendor uptime is not a backup#
Vendor uptime is not a backup because the vendor protects the service, not your choices inside it. If an admin deletes a project, a retention schedule purges old tickets, an integration overwrites fields or a subscription lapses, the vendor is generally doing what the account told it to do.
This is the shared responsibility model that SaaS backup providers write about: infrastructure resilience is the vendor's job, while recovering your own data from your own actions is largely yours. Vendor terms reinforce it, with deletion timelines that begin when a subscription ends.
What Jira, GitHub and Zendesk keep#
Jira, GitHub and Zendesk each document what happens after deletion or cancellation, and the windows differ. The table summarizes vendor documentation at the time of writing; check current terms for your plan before relying on any of it.
| System | What the vendor documents | What it means for you |
|---|---|---|
| Atlassian Cloud sites (Jira, Confluence) | Deactivated site data is retained 60 days on Free, Standard, Premium or Enterprise plans; unsubscribing from all Jira products on a site deletes the Jira data immediately | Verify a full export before any plan change or cancellation |
| Atlassian Backup and Restore | Requires a Premium or Enterprise plan; backups sit in Atlassian-owned storage for 30 days | Good for recent mistakes, not for long-term archives |
| Jira Cloud backup manager | Stores only one backup file at a time and allows a new backup every 24 hours | Download each backup to storage you control |
| GitHub | Organization owners can restore deleted repositories within 90 days; restoring does not restore team permissions | Issues, pull requests and reviews still need their own capture |
| Zendesk tickets | Closed tickets are archived after 120 days; deletion schedules permanently delete archived tickets, and deleted tickets cannot be restored | Check for deletion schedules before assuming history exists |
| Zendesk after cancellation | Automated permanent deletion of service data starts 90 days after cancellation and cannot be reversed once it starts | Export before giving notice, not after |
What a useful backup has to capture#
A useful backup captures the relationships between records, not only the records. A Jira issue export without comments, attachments, links and change history loses the reasoning; a repository mirror without issues, pull requests and review comments loses the decisions.
Native tools have gaps to plan around. Atlassian supports exporting up to 10,000 work items with Jira Cloud's asynchronous CSV export and recommends splitting larger exports into JQL batches. Zendesk account exports are not turned on by default, the account owner must ask Zendesk support to enable them, and AI agent tickets cannot be exported.
- Jira: issues with comments, change history, attachments, issue links, custom fields, sprints and fix versions.
- Confluence: pages with version history and attachments, including rarely used spaces.
- GitHub: repositories plus issues, pull requests, review comments, releases and organization membership history.
- Zendesk: tickets with every public comment and internal note, ticket fields, users, organizations and help center articles.
- Cross-system keys: issue keys in commit messages, ticket links to Jira issues and release tags, so the history can be rejoined later.
Backup methods compared#
Backup methods range from native exports to API scripts and third-party SaaS backup tools. Most software companies combine them: a scheduled native export for a vendor-supported snapshot, plus an API-based or tool-based capture of the details and links the native export misses.
API capture takes planning. GitHub's REST API allows 5,000 requests per hour with a personal access token and 15,000 per hour for a GitHub App installation on a GitHub Enterprise Cloud organization, and GitHub's acceptable use policies prohibit excessive automated bulk activity. Large histories should be captured incrementally rather than in one pass.
| Method | Strengths | Watch for |
|---|---|---|
| Native exports and backups | Vendor-supported formats, no extra contracts | Plan restrictions, single stored copies, missing relationships |
| API scripts | Full control over fields and links | Rate limits, maintenance effort, platform terms on bulk access |
| Third-party SaaS backup tools | Scheduled capture and point-in-time restore | Another vendor holding sensitive data; review its security and terms |
| Migration archives | Complete snapshot at a moment, such as a GitHub organization migration export | Not a running backup; restores need a compatible target |
Why complete history matters later#
Complete history matters later because questions about the past arrive after the people who remember it have moved on. Security incidents, customer disputes, warranty claims, audits and acquisition diligence all ask what happened, who decided and when, and the answers live in ticket comments and review threads.
History also has value of its own. Linked records of how bugs were reported, diagnosed, fixed, reviewed and released are the kind of operational data AI developers license for coding and support use cases. A company that lets old projects expire, or cancels a help desk without an export, loses that option for good.
Retiring a feature or system is the riskiest moment. Atlassian, for example, announced that the Bitbucket Cloud issue tracker and wiki would be removed on August 20, 2026, with issues exportable as a zip file or migratable to Jira.
Illustrative: consolidating a help desk and two Jira sites#
Illustrative: a fictional vertical software company is moving from Zendesk to a new help desk and consolidating two Jira sites into one. The IT lead plans to cancel the old Zendesk account at renewal.
Before giving notice, the team asks Zendesk support to enable exports, runs a full JSON export and uses the API to capture ticket comments and internal notes. It finds a ticket deletion schedule set up years earlier and pauses it. For Jira, it downloads a site backup to company storage, exports issues in JQL batches and keeps a map of old issue keys to new ones.
The company ends up with a complete, linked archive of support and engineering history in its own storage, plus a written record of what was exported, when and by whom.
How SourceX thinks about backups#
SourceX sees backups as the step that keeps future options open. The SourceX five-step transaction begins with Supply, and a company can only license records it still holds; complete, linked exports of Jira, GitHub and Zendesk often decide whether a fit check finds a usable archive.
Large archives stay in the company's own storage or ship on encrypted drives, because SourceX never hosts multi-TB datasets. The SourceX Evidence Packet records provenance, including which system and which export produced each record set.
Frequently asked questions
Does Atlassian's own backup replace a separate backup?
Not fully. Atlassian Backup and Restore needs a Premium or Enterprise plan and keeps backups in Atlassian-owned storage for 30 days. That helps with recent mistakes, but long-term archives should sit in storage you control, in formats you can read without the vendor.
Do we need to back up GitHub if every developer has a local clone?
Local clones cover code, not the issues, pull request discussions, reviews and releases that live on the platform. They are also scattered across laptops and may be incomplete. Capture the organization's platform data separately and keep a full mirror of repositories under company control.
How often should backups run?
Match frequency to how much history you could tolerate losing and to vendor limits, such as Jira Cloud allowing a new backup every 24 hours. Many teams run frequent incremental captures with periodic full exports, and test restores so they know the files are usable.
Are backups subject to privacy rules?
Yes. Backups copy personal data from tickets, comments and user records, so retention policies, access controls and deletion requests apply to them too. Document where backups live, who can open them and how long they are kept.
Should we back up Slack and Confluence too?
If engineering and support decisions happen there, yes. Slack threads and Confluence pages often hold the reasoning that tickets only summarize. Check each vendor's export options by plan and its API terms, since some platforms restrict bulk export through their APIs.
Sources
- Under Zendesk's Service Data Deletion Policy, an automated process that permanently deletes the account's Service Data starts 90 days after the account is canceled or terminated, and once it starts it cannot be reversed. Source
- After a cloud site is deactivated, Atlassian retains data for 15 days for trials and 60 days for Free, Standard, Premium or Enterprise plans. Source
- Atlassian states that unsubscribing from all Jira products on a site deletes the Jira data immediately. Source
- Atlassian Backup and Restore requires a Premium or Enterprise plan and stores backups in Atlassian-owned storage for 30 days, expiring on the 31st day. Source
- Jira Cloud's Backup manager allows a new backup every 24 hours from the time the previous one finished and stores only one backup file at a time. Source
- Atlassian supports exporting up to 10,000 work items using the asynchronous Export CSV feature in Jira Cloud and recommends splitting larger exports into JQL batches. Source
- GitHub organization owners can restore deleted repositories owned by the organization within 90 days of deletion, and restoring does not restore team permissions. Source
- GitHub's REST API allows 5,000 requests per hour with a personal access token, while a GitHub App installation on a GitHub Enterprise Cloud organization gets 15,000 requests per hour. Source
- GitHub's Acceptable Use Policies prohibit using GitHub servers for excessive automated bulk activity. Source
- Zendesk automatically archives tickets 120 days after they reach Closed status, or sooner for accounts with extremely high ticket volume. Source
- Zendesk ticket deletion schedules delete archived tickets after a set period, and deleted tickets cannot be restored. Source
- Zendesk data exports are not turned on by default; the account owner must contact Zendesk Customer Support to enable them, and AI agent tickets cannot be exported. Source
- Atlassian announced that the Bitbucket Cloud issue tracker and wiki would be removed on August 20, 2026, with issues exportable as a zip file or migratable to Jira. Source
Related resources
- InsightShutting down a SaaS startup: what to do with Slack, Jira, GitHub and email
- InsightVendor AI training vs licensing your own data: who captures the value?
- InsightOwning the data vs having the right to license it: the wind-down distinction
- IndustrySoftware development agencies data
- IndustryEngineering consultancies data
- DataCode review records
See if your company qualifies
A short company assessment. No data uploads are needed.