How to Export More Than 1,000 Jira Issues to Excel

Jira Cloud exports up to 10,000 work items natively in one CSV. Beyond that, split your search into non-overlapping JQL batches and merge the files — or use an export app to skip the batching and get real XLSX, change history, and scheduled delivery.

Good news: Jira Cloud is not stuck at the old 1,000-issue export limit anymore.

As of 2026, Jira Cloud supports native exports of up to 10,000 work items from the Issue Navigator using its asynchronous CSV export. That is a big improvement over the old 1,000-row ceiling. But there are still catches:

• It is CSV, not a rich native Excel workbook.
• Big “all fields” exports can be slow and chunky.
• You will need to batch exports for more than 10,000 issues.
• You still have to merge the files yourself.
• Native Jira export cannot be scheduled, and it does not include full change history.

So the short answer is:

If you have fewer than 10,000 Jira issues and just need a quick one-off CSV, Jira’s built-in export is enough. If you care about repeatability, cleaner XLSX files, saved field setups, live preview, issue history, or delivery automation, an export app can still be worth it below 10,000. And if you have more than 10,000, either split the export with JQL and merge the CSV files, or use an app to avoid the batch-and-stitch routine entirely.

Now let’s do the actual thing.

First: “Excel export” usually means “Excel CSV”

Jira’s native export option is called Export Excel CSV. That wording is doing a little dance.

It means Jira gives you a CSV file that Microsoft Excel can open. It does not mean Jira is generating a proper .xlsx workbook with multiple sheets, preserved data types, formulas, styling, pivots, or any of the other Excel goodness people usually picture when they say “Excel file”.

For many teams, CSV is fine. Excel opens it, you can filter it, and nobody has to think too hard. Lovely.

But it matters when:

• Dates come through in awkward formats.
• Multi-value fields expand in weird ways.
• You want separate sheets.
• You need formulas, formatting, or stable field types.
• You are sending the file to someone who will absolutely break it and then ask you why you broke it.

This guide covers the native CSV-to-Excel route first, because it is free and built in. We will get to the nicer options after that.

One small scope note: this article is mainly about Jira Cloud. Jira Data Center and older Jira Server guidance still documents a 1,000-issue native CSV export limit by default, with batching, REST pagination, or admin configuration changes as workarounds. So: Cloud gets the newer 10,000-work-item export; Data Center users should assume 1,000 unless their admin has changed the relevant limits.

How to export Jira issues to Excel CSV

For a standard Jira Cloud export:

1. Go to Filters > View all work items.
2. Build or open the JQL search you want to export.
3. Check the result count.
4. Select the More actions menu.
5. Choose Export.
6. Pick one of the Excel CSV options:
   • Export Excel CSV (all fields)
   • Export Excel CSV (current fields)
   • Export Excel CSV (filter fields), if you are using a saved filter with configured columns
7. Open the downloaded CSV in Excel.

If your export is under 10,000 issues and this is a one-time CSV, this is probably the simplest route. Do not over-engineer a sandwich.

That said, pick your fields carefully. Atlassian specifically recommends selecting only the fields you need, because “all fields” exports can be slower and harder to work with. If your Jira site has years of custom fields, comments, links, and historical odds-and-ends, exporting everything can produce the kind of CSV file that makes Excel stare into the middle distance.

What if you have more than 10,000 Jira issues?

Then you need to batch the export.

The cleanest current workaround is to split your JQL into smaller searches where each search returns fewer than 10,000 issues. Export each batch separately, then merge the CSV files in Excel, Power Query, Google Sheets, Python, or whatever tool you use when a spreadsheet becomes furniture.

The important part is that your batches must not overlap.

Bad batching:

project = ABC AND status = Done
project = ABC AND status in (Done, Closed)

That second query includes the first one. Duplicate city.

Better batching:

project = ABC AND created >= "2026-01-01" AND created < "2026-04-01" ORDER BY created ASC
project = ABC AND created >= "2026-04-01" AND created < "2026-07-01" ORDER BY created ASC
project = ABC AND created >= "2026-07-01" AND created < "2026-10-01" ORDER BY created ASC
project = ABC AND created >= "2026-10-01" AND created < "2027-01-01" ORDER BY created ASC

Each date range is separate. No issue should appear in two files.

A practical batching method

Here is the calm, non-heroic way to do it.

1. Start with the full query

For example:

project = ABC ORDER BY created ASC

Run it in Jira’s Issue Navigator and note the total number of results.

If it is 9,400, you are done. Export once. Go enjoy a tiny victory.

If it is 47,000, keep going.

2. Choose a field to split by

Good batching fields are stable and easy to reason about:

• created
• updated
• resolved
• project
• issuetype
• status

Date ranges are usually the least annoying option because they are naturally ordered and easy to make non-overlapping.

3. Create batches under 10,000 issues

Try a date range:

project = ABC AND created >= "2026-01-01" AND created < "2026-04-01" ORDER BY created ASC

If Jira says that returns 6,200 issues, great.

If it returns 14,500, split it again:

project = ABC AND created >= "2026-01-01" AND created < "2026-02-15" ORDER BY created ASC
project = ABC AND created >= "2026-02-15" AND created < "2026-04-01" ORDER BY created ASC

The trick is not cleverness. The trick is patience and no overlap.

4. Export each batch

For every batch:

1. Run the JQL.
2. Confirm the count is under 10,000.
3. Export using Export Excel CSV.
4. Name the file clearly.

Use boring filenames. Future-you deserves mercy:

jira-abc-created-2026-01-01-to-2026-02-15.csv
jira-abc-created-2026-02-15-to-2026-04-01.csv

5. Merge the CSV files

If the files have the same columns, you can combine them in Excel with Power Query:

1. Put all batch CSV files in one folder.
2. In Excel, go to Data > Get Data > From File > From Folder.
3. Select the folder.
4. Combine and load the files.
5. Check the row count against your original Jira result count.

That final count check is not optional. It is the spreadsheet equivalent of checking that you still have your passport before leaving the airport.

What about the old 1,000-issue URL trick?

You may still find older articles that tell you to edit the export URL with tempMax=1000 and pager/start=1000.

That workaround existed, and Atlassian still has documentation explaining the mechanics, but Atlassian now marks the URL-parameter workaround as deprecated as of March 2026. The current recommended native route for very large exports is to split the results with JQL into batches under 10,000 and merge the files manually.

So if an old forum post says “just change the URL”, treat it like advice from a map printed before the bridge was built. Interesting, maybe useful historically, but not where you start today.

Can you use Google Sheets or Microsoft Excel directly?

Sometimes, yes.

Jira Cloud also has options to open search results in Google Sheets or Microsoft Excel from above the search results. Atlassian’s Jira Cloud for Sheets documentation says the add-on should work with queries up to 10,000 work items, though that can vary depending on the amount and complexity of data.

For more than 10,000, the =JIRA() function can paginate results into separate ranges. For example, one formula can return the first 10,000 rows and another can start at 10,000 for the next batch.

This can be handy if your final destination is Google Sheets anyway. It is less lovely if your actual requirement is “send Finance an Excel file every Monday morning without me touching anything.” In that case, you are still doing orchestration by hand.

Can you use the Jira REST API?

Yes, but now we are in “some assembly required” territory.

The Jira REST API supports paginated searches. That means you can fetch a page of issues, then fetch the next page, then keep going until you have the full dataset. For technical teams, this is often the most flexible option.

But there are trade-offs:

• You need authentication and API tokens.
• You need to handle pagination correctly.
• You need to choose fields and normalize the output.
• You need to turn JSON into CSV or XLSX.
• You need to maintain the script when Atlassian changes API behavior.

That is perfectly reasonable for engineering teams. It is a bit much for “I just need this spreadsheet for the quarterly review.”

The native method is fine when…

Use Jira’s built-in export when:

• You are exporting fewer than 10,000 issues.
• You only need a one-off file.
• CSV is acceptable.
• You do not need issue history.
• You do not need scheduled delivery.
• You do not need to reuse the same field setup later.
• You are happy choosing fields and cleaning up the file yourself.

Basically: simple job, simple tool.

No shame in that. The best export is the one that is done.

An export app can still help under 10,000 issues

The issue count is only one part of the decision. A 3,000-issue export can still be annoying if you have to rebuild it every Friday, reselect the same fields, tidy date formats, send it to three people, and then explain why the “Excel export” is actually a CSV.

An export app can be useful below 10,000 issues when you want:

• A saved export configuration you can run again.
• A live preview before downloading the file.
• Real .xlsx output instead of CSV.
• More predictable dates, numbers, and field formatting.
• The same columns in the same order every time.
• Issue change history included in the export.
• Scheduled delivery by email, SFTP, API, or webhook.
• Less “wait, which fields did I export last time?” energy.

So the better rule is: use native Jira for quick manual CSV exports; use an export app when the export itself is becoming a workflow.

The native method gets painful when…

You probably want a more robust export tool when:

• You regularly export more than 10,000 issues.
• You need proper .xlsx files, not only CSV.
• You need full issue change history.
• You need Jira Service Management Assets data.
• You send the same export every day, week, or month.
• You need the file delivered to email, SFTP, an API, or a webhook.
• You are merging batch files often enough that it has become part of your personality.

That is where manual export stops being “a quick workaround” and becomes process debt wearing a little spreadsheet hat.

How Advanced Export handles large Jira exports

Advanced Export is built for the point where Jira’s native export starts to feel like arts and crafts.

Instead of manually batching CSV files, you can configure an export from a filter, JQL query, or board, choose the fields you need, preview the result, and export to XLSX, CSV, or JSON. It also supports complete change history, which native Jira exports do not give you as a tidy spreadsheet.

The bigger difference is automation:

• Send scheduled exports by email.
• Upload files to SFTP.
• Share a download link.
• Deliver through API or webhook.
• Include the same fields every time.
• Stop rebuilding the same spreadsheet with your actual human hands.

This is not necessary for every team. If you need one plain CSV under 10,000 issues once, use Jira. Done.

But if your Jira export is part of a recurring reporting workflow, Advanced Export removes the boring parts: batching, merging, formatting, remembering, and quietly resenting the whole operation.

Quick decision guide

Situation	Best option
Under 10,000 issues, one-time CSV	Native Jira Excel CSV export
Under 10,000 issues, recurring or polished XLSX export	Advanced Jira Export
Over 10,000 issues, one-time export	Split with JQL batches and merge CSV files
Google Sheets is the destination	Jira Cloud for Sheets or =JIRA() pagination
Technical team needs raw data	Jira REST API pagination
Recurring Excel/CSV/JSON export	Advanced Jira Export
Need issue change history in rows	Export app
Need scheduled email, SFTP, API, or webhook delivery	Export app

Reduce the risk in large Jira exports

If this is a one-time export, Jira’s native CSV export may be enough.

But once you start splitting Jira results into batches and stitching CSV files together manually, the problem is not just that it is annoying. It is also easier to miss data, duplicate rows, merge files with different columns, or send someone an export you cannot reliably recreate later.

Advanced Export is built for teams that need Jira exports to be repeatable, not hand-assembled. You can export from JQL, filters, or boards; preview the result before downloading; include issue change history; and deliver XLSX, CSV, or JSON by email, SFTP, API, or webhook.

Try Advanced Jira Export on the Atlassian Marketplace