How to export your Jira projects to CSV

Jira offers two CSV exports that look almost identical in the menu and return materially different files. Pick the wrong one and you will discover the gap after the import has already failed, usually with comments or story points missing. Here is the whole process, the limits that bite, and a field-level reference for what actually lands in the file.

The two exports, and why the difference matters

Both live under the same Export dropdown in the issue navigator:

• Export CSV (current fields) — only the columns currently visible in your view. Fast, small, and usually incomplete.
• Export CSV (all fields) — every field on every work item, including comments. Atlassian notes this can significantly slow the export and produce files that are awkward to open.

The decisive detail: comments only appear in the all-fields export. If your migration needs discussion history, current fields will silently drop it and you will not notice until you are looking at an imported backlog with no context on any ticket.

Exporting from the issue navigator

1. Open Filters → View all work items.
2. Narrow to what you want with JQL. Scoping to one project is project = ABC.
3. Click Export in the top right.
4. Choose Export CSV (all fields) unless you have a specific reason not to.

Atlassian has renamed “issues” to “work items” across Jira Cloud, so recent documentation and menu labels use the newer term even where older guides and the JQL itself still say issue.

The 10,000-row ceiling

Exports from the issue navigator cap at 10,000 work items, raised from the long-standing 1,000 limit in March 2025. Many older blog posts and Stack Overflow answers still quote 1,000, which is why so much advice recommends elaborate workarounds you no longer need.

The cap applies to the UI export only — it does not constrain the REST API. If you genuinely exceed 10,000 items, Atlassian’s own recommendation is to split the result set with JQL and stitch the files together afterwards:

project = ABC AND created >= "2024-01-01" AND created < "2025-01-01"
project = ABC AND created >= "2025-01-01" AND created < "2026-01-01"

Split on created rather than status or work type. Status changes between exports, so a status-based split can drop or duplicate items that move while you are working.

What is actually inside the file

Jira’s CSV format has several conventions that break naive parsers and spreadsheet formulas. These are the ones that cost real time.

Multi-value fields repeat the column header

Labels, components, fix versions and attachments do not use a delimited list inside one cell. Each value gets its own column, and every one of those columns carries the same header:

WorkType, Summary, FixVersion, FixVersion, FixVersion, Component, Component
bug, "First work item", v1, , , Component1,

A work item with eleven labels produces eleven Labels columns, and the file’s column count is set by whichever item has the most. This is why loading a Jira CSV into pandas or a spreadsheet with a strict header parser tends to fail or silently keep only the last column of each name.

Comments are one column each, with metadata inline

Each comment occupies its own repeated Comment column, with author and timestamp packed into the cell as a semicolon-delimited string:

"01/01/2012 10:10;<atlassian-account-id>; Comment text"

The author is an Atlassian account ID, not a name or email. Turning those into human-readable authors requires a separate lookup against the user directory — budget for it if comment attribution matters to you.

Time tracking is in seconds

Original estimate, remaining estimate and time spent all export as raw seconds. A three-day estimate arrives as 86400 if your team’s working day is eight hours and Jira is configured accordingly — check your own time-tracking settings before converting, because the day length is configurable.

Attachments are URLs, not files

The attachments column contains links back to Jira, not the binaries themselves:

"https://your-site.atlassian.net/secure/attachment/12345/diagram.png"

Those URLs stop resolving the moment you close the Jira instance. If attachments matter, download them while the account is still live — a CSV alone is not a backup of them.

Parent items must precede their children

Hierarchy is expressed through Work item ID and Parent columns, and Atlassian is explicit that parent work items must appear before their subtasks in the file. If you sort the CSV before re-importing it anywhere, you can break the hierarchy without any error message.

Pre-flight checklist

• Export all fields if you need comments — you cannot add them later.
• Scope with JQL first, so you are not exporting years of closed work.
• Download attachments separately while the Jira account is still active.
• Do not re-sort the file if anything downstream reads the parent hierarchy.
• Open it in a text editor first, not Excel, which mangles long IDs into scientific notation.

If you are importing into Sprint Guage

Worth being direct about the gap. Our importer reads a Jira CSV and brings across work item titles, types, priorities and story points. It does not preserve your original issue keys, and it does not import comments, attachments, sprint history, or reporter and assignee mapping.

That has a practical consequence for this guide: if Sprint Guage is your destination, the all-fields export mostly buys you a slower export and a larger file for data we will not read. Current fields is enough, provided your visible columns include summary, work type, priority and story points.

For a large migration it is worth talking to us first so we can size the gap honestly rather than after you have committed to a cutover date.