Jira Data Export: The 10,000 Item Ceiling
Jira Cloud exports up to 10,000 work items at a time, and that ceiling is fixed. Any backlog larger than that leaves in batches, assembled by you.
Exit score: 22 / 30
How hard Jira Cloud makes it to leave with your data intact, scored against 6 criteria from the vendor's own published documentation. How we score.
| Criterion | Score | What the documentation says |
|---|---|---|
| Self-service | 5/5 | Export runs from the Issue Navigator inside the product. No support request and no administrator involvement is documented for the standard CSV export. |
| Format openness | 4/5 | CSV, which is open and universally readable. One point deducted because a flat table is a poor fit for Jira issues, which carry threaded comments, linked issues and change history that a single row cannot hold. |
| Completeness | 3/5 | The export article covers the mechanism and the limit rather than the field list, so whether comments, attachments and full change history travel is not established on this page. |
| Not paywalled | 4/5 | No plan-tier restriction on CSV export is stated. One point deducted because the documented workaround for large exports leans on Google Sheets or Excel integrations, which are not equally available to every team. |
| Documentation clarity | 4/5 | Atlassian states the ceiling outright and publishes a dedicated article on exceeding it, with named workarounds. That is more transparency than most vendors offer about their own limits. |
| Caps and expiry | 2/5 | A hard, non-configurable ceiling: up to "10,000 work items using the asynchronous Export CSV feature from the Issue Navigator". Larger datasets must be split into batches by hand. |
What comes out
- Up to 10,000 work items per CSV export from the Issue Navigator.
- Any slice you can express as a JQL query - which is the mechanism that makes batching possible.
- Larger datasets, if you split them into batches under the ceiling and reassemble them yourself.
- Issue data through Google Sheets or Excel integrations, documented as the alternative route for big exports.
What stays behind
- Everything past the 10,000th work item in any single export.
- Structure - a CSV cannot represent issue links, epics and sub-tasks as relationships, only as reference columns.
- Anything the export article does not enumerate: comments, attachments and change history are not addressed either way.
- Board, sprint and workflow configuration, which are not part of an issue export.
Atlassian owns two products in this section, and both bound the export rather than the account. Trello caps at the 1,000 most recent actions on a board. Jira Cloud caps at 10,000 work items per CSV export.
Ten thousand is a far more generous number, and for most teams it is simply never reached. But it is a hard edge rather than a soft one, and the teams that hit it are the ones with the most to lose.
The ceiling, and what it is not
Jira Cloud supports exporting up to 10,000 work items using the asynchronous Export CSV feature from the Issue Navigator.
Two things make this better than it first sounds.
It is a limit per export, not per account. Nothing prevents you taking your 47,000 issues out — it just takes five exports rather than one.
And Atlassian publishes the limit rather than letting you discover it. There is a dedicated article on exceeding 10,000 items, naming the workarounds: the Google Sheets or Excel integrations, or splitting the query with JQL. A vendor that documents how to work around its own constraint is behaving well, and it is why this scores 4 on documentation rather than 2.
What makes it worse than it sounds is that the ceiling is not configurable. There is no admin setting, no support request, no enterprise unlock. Batching is the answer, and batching is manual.
Batching without losing rows
This is the part that goes wrong, and it goes wrong quietly.
The obvious way to split a large backlog is by date — everything created before 2024, everything after. The problem is that any query relative to now shifts between exports. Run batch one on Tuesday and batch two on Thursday and a fortnight of issues can fall into both, or neither.
Split on something that cannot move. Fixed date ranges with explicit endpoints, project keys, or issue key ranges. Then do the arithmetic afterwards: add the row counts from every file and check the total against a single JQL count of everything you meant to take. If those two numbers disagree, you have a gap, and finding it now is far cheaper than finding it in a year.
Nothing in the product does this check for you.
The format is the deeper limitation
The 10,000 ceiling gets the attention. The flat file matters more.
A Jira issue is not a row. It is a small graph: it belongs to an epic, it links to other issues as blocks or duplicates, it holds sub-tasks, it carries a threaded comment history and a complete audit trail of every field change.
A CSV can hold one row per issue and columns of values. Relationships survive only as reference columns — an epic key here, a parent ID there — which means the receiving system has to reconstruct the graph from identifiers, if it can at all.
So the honest expectation for a Jira migration is that issues travel and the structure between them is rebuilt. That is a project, not an import, and teams that budget for the second usually discover the first.
What we could not establish
Atlassian's export articles address the mechanism and the limit rather than the field list. So the questions that decide how much you actually keep — do comments come, do attachments come as files or links, does the change history travel — are not answered by the source.
We have left them unscored and listed them above rather than guessing. The practical response is the same as everywhere on this site: run one small export and look inside the file. A single JQL query limited to twenty issues answers all three questions in about five minutes.
Do it while you are happy with Jira, not while you are leaving it.
Configuration is not in the box
Worth stating plainly because it surprises people: an issue export contains issues.
Your workflows, your board configurations, your sprint history, your custom field definitions, your automation rules and your permission schemes are not in a CSV of work items. For a team that has spent two years shaping Jira around how it actually delivers, that configuration is the investment, and none of it travels through this route.
If you are migrating rather than archiving, write the important parts down before you go. A screenshot of each board and a list of custom fields costs an hour and saves a fortnight of reconstruction from memory.
The verdict
22 out of 30. A capable export with an honest, documented, inconvenient ceiling.
Most teams will never touch 10,000 items and will find this a straightforward exit: click, wait, receive a readable file. Large or long-running instances will find it a manual assembly job with no built-in verification, and that is where mistakes get made.
Compared with its Atlassian sibling, Jira comes out considerably better — Trello's ceiling is 1,000 actions and silently truncates board history, which is covered in the Trello exit report. Between the two there is a consistent house style worth noticing: Atlassian bounds the export, and tells you it has.
Before you cancel
- Count your issues first with a JQL query - if you are near or over 10,000, plan for batches before you start.
- Split by a stable field rather than by date created, so a batch cannot shift underneath you between exports.
- Use JQL ranges that cannot overlap, and check the row counts add up to your total afterwards.
- Run a single small export first and inspect it for comments, attachments and history before trusting the format.
- Export attachments separately if they matter - a CSV cell holds a reference, not a file.
- Record your workflows, boards and custom field definitions by hand; issue exports do not carry configuration.
What we could not verify
- Whether comments are included in the Jira Cloud CSV export, and whether all of them or a capped number.
- Whether attachments are exported as files or as URLs pointing back at Jira.
- Whether the full change history of an issue travels, or only current field values.
- Whether the 10,000 ceiling applies per export or per query in other export routes such as the API.
These are open questions, not criticisms. Where a vendor does not publish an answer we leave it unscored rather than guessing, and the score is calculated only from what is documented.
Questions people ask
What is the Jira export limit?
Jira Cloud supports exporting up to 10,000 work items using the asynchronous Export CSV feature from the Issue Navigator. Atlassian does not document a way to raise it - instead it publishes workarounds: use the Google Sheets or Excel integrations, or split the export into batches using JQL queries that each stay under the ceiling.
How do you export more than 10,000 issues from Jira?
By batching. Write JQL queries that each return fewer than 10,000 work items, export each one, then reassemble the files. The important discipline is choosing a split field that cannot shift between exports - a stable identifier or a closed date range rather than anything relative to today.
Does a Jira CSV export include comments and attachments?
Atlassian's export documentation addresses the mechanism and the limit rather than the field list, so we could not establish this from the source. Run one small export and inspect it before you rely on the answer - and note that a CSV cell can only ever hold a link to an attachment, not the file itself.
Is the Jira 1,000-issue limit the same thing?
No, and it is worth separating them. The 1,000-issue figure appears in Atlassian documentation about filter exports in Jira Server, a different product. The Cloud ceiling documented for the asynchronous CSV export from the Issue Navigator is 10,000 work items.
Can you export Jira as JSON?
Not through the documented Issue Navigator export, which produces CSV. That matters because Jira models relationships - epics, sub-tasks, issue links, threaded comments - that a flat table represents only as reference columns, leaving the structure to be rebuilt wherever you land.
Where this information comes from
Product details change often. Each item below links to the primary source we checked, so you can confirm anything that matters to your decision.
Vendors change their export tooling without announcing it. If something here no longer matches what you see in the product, tell us and we will re-check it.