"This project is done. Retire it, but keep a copy of everything in case someone asks." Simple until you look for the export button. Jira Cloud has none for a project, the site backup is all-or-nothing, and proving what a project contained the day you archived it is on you. A single-project export is one of the longest-standing asks on the tracker (JRACLOUD-34307, over a thousand votes).
What the issue-search CSV export drops
The fastest path is a JQL search for project = KEY exported to CSV. It gives you one
row per issue with fields, and not much else. Comments come across thin or not at all, the
changelog is absent, worklogs are absent, links are flattened, and attachments are names without
the files. As a record of the project it is a summary, not a backup.
The DIY approach: extract per issue through the REST API
- Page the project's issues with
POST /rest/api/3/search/jqlordered by created date, expanding the changelog on each page. - Enrich each issue with its comments
(
GET /rest/api/3/issue/{key}/comment) and worklogs (GET /rest/api/3/issue/{key}/worklog). - Read links off
issuelinksand attachment metadata offattachment; the binaries are separate authenticated downloads. - Write a manifest alongside the data: project, issue count, timestamp, the field list, and whether anything was cut short. Without it, nobody can later say the backup was complete.
Done carefully this is a genuinely complete record. The cost is the pagination, the per-issue calls, the normalization into something storable, and doing it the same way every time.
Archive versus trash, before you retire anything
Archiving keeps a project restorable from the Jira archive, and it is a Premium and Enterprise feature. Trashing moves the project to the recycle bin, recoverable for 60 days and then deleted permanently by Jira. Either way, the right order is export, verify the export covers the live project, and only then retire it, with the export as the audit trail of what was retired.
A ready-made option: Project Export & Backup
Project Export & Backup automates the method above. Pick a project, choose CSV (one row per issue) or JSON (structured, re-import friendly), and it pages the issues, expands each changelog, gathers comments and worklogs, and streams the file to your browser with a manifest. Every export is recorded in a history. On top sits an opt-in, heavily guarded decommission: it only offers to archive or trash a project with a complete export from the last 7 days, preview is the default, you type the project key to confirm, and it re-checks the live issue count against the backup before acting. Attachments are exported as URLs and metadata, not binaries, and each run is bounded and flagged as truncated if a project exceeds the cap.
Key facts
- Native options: a filtered CSV of fields, or a whole-site backup. Nothing in between.
- A complete record needs: fields, comments, worklogs, changelog, links, attachment references, and a manifest that says it is complete.
- Retire in this order: export, verify, archive (Premium) or trash (60-day recovery).
- Scopes: read for the export; two write scopes used only by the opt-in decommission path.
Related reading: How to keep Jira audit logs past the retention window and what deactivated users leave behind in Jira.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@llmgraph.ai.