Export Jira issues to CSV without losing the parts that matter

Open your Jira CSV export in a spreadsheet and scroll right until you reach the assignee. You will find two columns, not one. Assignee holds something like Priya Raghunathan. Assignee Id holds something like 712020:8f3c1a9e-.... Same person, two representations, and picking the wrong one is the difference between an import that assigns 300 stories correctly and an import that assigns none of them. Jira's own CSV importer refuses the readable one: Atlassian's guidance is blunt that Jira "cannot parse or resolve Display names in the CSV to email addresses or AAID", so you have to map the account ID.

That single detail is the texture of this whole job. Pulling the file out of Jira takes about nine seconds. What takes the Friday afternoon is the twenty small mismatches between the file Jira hands you and the shape your next tool expects. This is a guide to those mismatches, whatever you are moving to.

How do you export Jira issues to CSV?

Start with a search, not a project. The export acts on whatever result set you are looking at, so the JQL you write is the real control surface. From a project you can use the List view; from anywhere you can go to Filters, then Search work items, and build the query there. Either way the export lives behind the ••• More actions menu, under Export.

The names you will see in Jira Cloud are Export Excel CSV (all fields), Export Excel CSV (current fields), and, when you are looking at a saved filter, Export Excel CSV (filter fields). The word Excel is a historical wart. All three give you a CSV.

Choose deliberately between the first two, because they are not the same file. Current fields exports the columns you have configured in the navigator, which means you can decide the shape of the file before you export it. All fields exports everything Jira knows, which on a mature project means several hundred columns, a much slower export, and a file that is genuinely awkward to open. Atlassian's own performance guidance is to pick only the fields you need.

There is one reason to reach for all fields anyway: it is the only way to get comments out. More on that shortly.

The ceiling, and the smaller ceiling underneath it

Jira Cloud's asynchronous CSV export from the issue navigator handles up to 10,000 work items. That number is newer than most migration guides on the internet: it was 1,000 until March 2025, which is why so much advice still assumes a thousand-row wall.

Underneath the 10,000 there is still a 1,000. If you need to go past ten thousand, Atlassian's documented workaround is to batch with a pager/start URL parameter, and each of those batches is capped at 1,000 items. The limits on API-based exports were not raised at all. And if you are on Data Center rather than Cloud, filter exports have long defaulted to 1,000 rows, so check before you assume you got everything.

Which brings up the mistake worth avoiding: count your rows. Not the summary Jira showed you, the actual rows in the file. A silently truncated export is the failure mode that survives all the way to the new tool and only surfaces three weeks later when someone asks where a story went. If you need multiple files, split them by JQL you can reason about, such as one project or one date range at a time, rather than by paging offsets. Atlassian specifically warns against mixing UI exports with API batch exports, because you end up with duplicates or gaps.

The columns that will surprise you

Four things about the file's shape catch people out, and all four are worth knowing before you start mapping.

Custom fields arrive wrapped in their own label. Story points are not in a column called Story Points, they are in Custom field (Story Points). Worse, which custom field depends on how the project was created: company-managed projects estimate with Story Points, team-managed projects estimate with Story point estimate, and the two are genuinely different fields. If you are exporting a mix of project types, you are exporting two different points columns, and a mapping that only knows about one of them will quietly drop half your estimates.

Multi-value fields do not become comma-separated lists. They become repeated columns with identical headers. An issue that has passed through nine sprints produces nine Sprint columns, and the header row is as wide as the busiest issue in your result set demands. The same happens to components and labels. This breaks any parser that builds a dictionary keyed on header name, because the last column silently wins and eight sprints vanish. It also breaks spreadsheet templates, which is a long-standing complaint in Atlassian's own community.

Comments follow that same pattern, taken to an extreme. With all fields selected, each comment is mapped into a different Comment column in chronological order. So yes, your comments are technically in the file. They are also in a ragged tail of dozens of identically named columns, bundled with author and timestamp inside each cell, and there is essentially no destination tool that will read that into a threaded discussion. Be realistic about it: what you have exported is an archive, not a migration.

Attachments do not come out at all, only their URLs. Jira Cloud does not natively support downloading attachment files in bulk. If those files matter, that is a separate job with the API, and it is not a Friday afternoon job.

The parent link is a moving target

If your stories sit under epics, this is the field to check first, because Atlassian has been consolidating it. Historically a child issue pointed at its epic through Epic Link, and issues above epic level used Parent Link. Both are being replaced by a single Parent field, with existing values migrated across, and the older field values are deprecated in the REST API and in issue history changelogs.

Practically, that means you cannot assume which column your hierarchy is hiding in. Look for it. Depending on your project type and how recently your instance was updated, the epic relationship may be expressed as a parent issue key, as an epic name, or both. Whatever your destination tool reads, verify that the specific column it wants actually has values in your rows, rather than trusting that "epics came across" because the concept exists on both sides.

What is actually worth carrying over

Here is the opinionated part, and it is the advice we would give someone moving to any tool, including one that is not ours.

Carry the backlog, not the archive. Titles, descriptions, statuses, points, assignees, and the epic each story belongs to. That set is enough to run your next sprint on day one, and it is the set that CSV represents faithfully. Everything else, comments, history, transitions, worklogs, changelogs, is real data that a CSV represents badly and that your new tool almost certainly cannot store in the same shape anyway.

The instinct to bring all of it is understandable and mostly wrong. Migrating discussion threads is where these projects turn from an afternoon into a fortnight, and the honest concession is that this is a genuine loss, not a non-issue: occasionally you really do want to know why a decision was made in March. The cheaper answer is to keep the old instance readable for a quarter. Downgrade it, park it, export the all-fields CSV as a cold archive, and stop paying for it when you are confident. Do not cancel on the same afternoon you migrate anyway; our founder found that unwinding a Jira subscription took over two and a half months and around twenty emails, so the clock is not as tight as it feels.

And if you are moving specifically to get out of a tool's gravity well, make the exit shape part of the decision this time. It is the same question we raised about roadmaps welded to GitHub: the export you can get on your way out is a feature, and it is much easier to check before you commit than after.

Insist on a dry run before anything is created

The single most useful property of an importer is that it will tell you what it is about to do and let you change your mind. Whatever you are importing into, look for that step. If a tool goes straight from file upload to created records, upload a ten-row slice of your export first.

Scrumpy's importer is the half of this article where we can be concrete, since we wrote it. You pick Jira as the source format, choose the target team, and upload the CSV. Delimiter is detected automatically, comma or semicolon, which matters more than it sounds: a European Excel install will happily save you a semicolon-delimited file and a stricter parser will read the whole thing as one column.

Nothing is created yet. You get a preview showing how many rows will import, how many are duplicates, how many are being filtered out, and the total row count. Any Jira status it does not recognise is listed with the number of stories behind it and a dropdown to send it to one of your board's statuses or to skip those stories entirely, and an unmapped status is skipped rather than guessed. It lists the epics it would create so you can catch a bad epic column before it becomes forty junk epics. It lists assignees it could not match to a Scrumpy user, parks those stories on you, and backfills the real assignee if you invite the person and re-run the file. And there is a per-story checkbox list, because "import all of it" is rarely what anyone means.

Duplicates are detected on the Jira issue key, so re-running the same file does not double your backlog. That one property is what makes the whole thing safe to iterate on, which is what you want on a Friday.

Now the honest limits, since a migration guide that only lists strengths is useless. Scrumpy's importer does not bring comments, attachments, or issue history, for the reasons above. It does not recreate your sprints; stories land in the backlog and you plan the next sprint yourself, which we think is the right default when you are changing tools anyway. Rows whose issue type is Epic or Sub-task are skipped, and epics are built from the epic name found on the story rows instead. Story points are rounded to whole numbers, and a zero is treated as not yet estimated. If you optionally paste your Jira base URL, each imported story keeps a deep link back to the original issue, which turns out to be the pragmatic answer to the comment-history problem: click through when you actually need it.

The export is the easy half

Somewhere around the third re-export, when you have your JQL right and your columns trimmed and you finally understand which points field your projects use, this stops feeling like a data problem and starts feeling like an editorial one. You are not really moving a database. You are deciding which parts of four years of accumulated backlog deserve to exist in the new place.

That is a good afternoon's work, and worth doing awake rather than at 6pm on a Friday. Trim the file first, run the preview twice, and start the next sprint clean. If your reason for leaving was that the tool had grown heavier than the process it was managing, we have written about why that happens and what it costs, and the side-by-side comparison if you want to see where Scrumpy lands before you spend the afternoon.