Systems and records
Jira issue history: what full exports keep and lose
By SourceX Editorial · Updated
Short answer
A Jira CSV export keeps current field values, comments and many links, but it drops the issue changelog: the record of who changed status, assignee, priority and fields, and when. To keep full issue history, pair a site backup with an API pull of changelogs, worklogs and remote links, and store attachments under their issue keys.
Key takeaways
- Jira CSV exports show each issue's final state; the changelog of transitions and field changes is not included.
- A site backup carries the full database, but it is built for restoring into Jira, not for reading or analysis.
- The REST API returns changelogs, worklogs, comments and remote links per issue, within rate limits.
- Development data shown in Jira, such as commits and pull requests, usually has to be exported from the code host.
- Keep issue keys unchanged everywhere, because they are what link Jira to code, tickets and chat.
What each Jira export method keeps#
Each Jira export method keeps a different slice of issue history, and none of them alone gives a readable, complete record. The table compares the three main routes on Jira Cloud; Data Center adds direct database access, which holds everything but needs schema knowledge to read.
A Jira Cloud site backup from the Backup manager can include attachments, avatars and logos if you select them. Atlassian allows a new backup every 24 hours and stores only one backup file at a time, so download each one before the next replaces it. Separately, Atlassian Backup and Restore on Premium and Enterprise plans keeps scheduled backups in Atlassian-owned storage for 30 days. Both are designed for restoring into Jira, so reading a single issue's history from them takes tooling and patience.
Two consequences follow. A CSV-only archive answers what each issue looked like on export day, not how it got there. A backup on its own preserves the history but leaves you with a large archive that only Jira opens comfortably.
| Content | CSV export (all fields) | Site backup | REST API |
|---|---|---|---|
| Current field values | Yes | Yes | Yes |
| Comments | Yes, as columns | Yes | Yes, per issue |
| Changelog of status and field changes | No | Yes, inside the database export | Yes, per issue |
| Worklogs | Partly, as columns | Yes | Yes, per issue |
| Issue links | Yes, as columns | Yes | Yes |
| Remote links to other tools | Not as standard | Yes | Yes, per issue |
| Attachments | Links only | Optional file archive | Download per file |
| Development panel data | No | Not reliably | Not reliably; export from the code host |
| Marketplace app data | Varies by app | Varies by app | Varies by app |
Why the changelog is the part worth saving#
The Jira changelog is the part of issue history that records the work itself: every status transition, reassignment, priority change, sprint move, resolution and field edit, with the person and the time. Without it, an issue that was reopened after release, bounced between teams or escalated looks identical to one that went straight through.
Engineering leaders use changelogs to measure cycle time and find bottlenecks. Developers of coding and engineering AI look for the same signal: the sequence from report to diagnosis to fix to verification, ideally linked to code reviews and commits. A history of final states shows answers without the path that produced them.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
How to pull a complete issue history#
A complete pull combines a backup for safekeeping with an API extraction for use. Run it as a project with an owner, because large instances take time under rate limits and partial pulls are easy to miss.
Respect the published rate limits and honor retry responses. A pull that hammers the API gets throttled, and a throttled job that silently skips issues is worse than a slow one that finishes.
- Inventory projects, issue types, workflows, statuses and custom fields, noting which fields come from apps.
- Run a site backup with attachments and store it in company-controlled storage.
- Partition the API pull by project and created date so each batch is small and restartable.
- For each issue, pull fields, comments, the full changelog, worklogs, issue links and remote links.
- Download attachments into folders named by issue key and keep a manifest of file names and sizes.
- Export workflow and scheme definitions so status names can be interpreted later.
- Reconcile issue counts per project against Jira before anything at the source changes.
- Record user account IDs with role or team rather than personal details, to ease later de-identification.
What gets lost even with a careful export#
Some Jira history is lost even when every export runs correctly, because it was never stored on the issue or was removed before the export. Knowing the gaps lets you fill them from other systems or document them honestly.
Write the gaps into the archive's readme: which projects, date ranges and record types are incomplete, and why. An auditor, acquirer or future engineering lead will trust an archive with known, written gaps far more than one that claims to be complete.
| Gap | Why it happens | What to do |
|---|---|---|
| Deleted issues and comments | Deletion removes them from the database | Check older backups and audit logs; record the gap |
| Issues moved between projects | The key changes and old keys become redirects | Build a map of old and new keys from the changelog |
| Data held by apps | Time tracking, test management and other apps may store data outside standard fields | Export from each app with its vendor's tools |
| Development activity | Commits, branches and pull requests are displayed from the code host | Export repositories and pull requests with issue keys intact |
| Departed users | Accounts are deactivated and display names change | Map account IDs to roles before people leave |
| Automation history | Rule audit logs may be kept only for a limited period | Export rule definitions and recent audit logs on a schedule |
Illustrative: a vertical SaaS company keeps a decade of Jira#
Illustrative: a fictional fleet maintenance software company has run Jira since it was founded, first on Server and later on Cloud, with GitHub for code and Zendesk for support. Its CTO is asked to preserve engineering history before a reorganization merges several projects.
The first CSV export looks complete until an engineer notices that reopened bugs and escalations are invisible. The team adds a site backup, then an API pull of changelogs, worklogs, comments and remote links for every issue, with attachments filed by issue key. It also exports GitHub pull requests and Zendesk ticket references that mention Jira keys.
The result is a linked archive in which a customer ticket leads to a Jira bug, its transitions, the pull request that fixed it and the release that shipped it. The company uses it for internal cycle time analysis and later describes it, without sharing files, in a licensing fit check.
How SourceX assesses Jira history#
SourceX assesses Jira history with the SourceX Enterprise Data Value Framework, which puts weight on linkage and outcomes. Issue histories with changelogs, linked code reviews and resolved support tickets rank well above flat CSV exports of final states.
The fit check runs on a description of the archive: projects, years, record families and how history was exported. If a package proceeds, the SourceX five-step transaction runs from Supply through Delivery, the data stays in the company's storage until release, and Preparation removes personal details and secrets before anything is shared.
Frequently asked questions
Can a single Jira CSV export include every issue?
Not for a large instance. Atlassian supports exporting up to 10,000 work items at a time with the asynchronous Export CSV feature in Jira Cloud and recommends splitting larger exports into JQL batches, for example by date range. That makes CSV workable for small extracts but awkward as an archive, which is another reason to use the API for full history.
Does a Jira Service Management backup include customer data?
Yes. Service projects hold requests from customers, often with names, emails and attachments. Treat the backup and any export as containing personal data: restrict access, set a retention period, and remove identifying details before any reuse beyond your own operations.
How do we keep Jira linked to GitHub or GitLab history?
Issue keys are the link. Teams that put keys in branch names, commit messages and pull request titles can rebuild the connection from both exports. Export repositories and pull request discussions with messages intact, and never rewrite keys during cleanup.
Is Jira Data Center history easier to export?
In some ways. Direct database and file system access means nothing sits behind API limits, but the schema is complex and changes between versions. Keep a database backup and the attachments directory, and use the API or a documented tool to produce a readable archive.
Should we export workflow configuration as well?
Yes. Status names and transitions only make sense alongside the workflow that defined them, especially after workflows change over the years. Export workflow and scheme definitions, and keep a short note explaining what each status meant in practice.
What usually takes up the most space in a Jira archive?
Attachments, by a wide margin in most instances: screenshots, logs, recordings and design files added over years. Issue text, comments and changelogs are comparatively small. Estimate attachment volume early, decide whether every file type is needed, and keep the manifest so excluded files are documented rather than silently dropped.
Sources
- Jira Cloud's Backup manager (Administration > System > Import and Export) can include attachments, avatars and logos, offers 'Create Backup for Cloud' or 'Create backup for Server', 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 Backup and Restore lets admins back up Jira and Confluence data from admin.atlassian.com on demand or on a daily or weekly schedule, requires a Premium or Enterprise plan plus organization admin and app admin permissions, and stores backups in Atlassian-owned storage for 30 days, expiring on the 31st day. Source
- Atlassian states that exporting up to 10,000 work items using the asynchronous Export CSV feature from the Jira Cloud Issue Navigator is supported, and recommends splitting larger exports into JQL batches (for example by date range) of fewer than 10,000 work items each. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.