How to Export Jira Issue History to Excel or CSV

Current fields or change history?

Decide first what the spreadsheet must answer. “What is the status of these work items now?” needs current fields. “Who changed the status, when, and from what?” needs history. One work item has one current status but can have many status changes:

A current-fields export shows ENGS-5 once. A change table shows it three times. That difference is the whole point of any jira export issue history task.

1. Define the work items

Go to Filters→Search work items and build the set with Basic search or JQL. Keep two things apart: which work items (“these 20 requests”) and which changes (“changes made in June”).

Write down the search or JQL, the number of results, the date you ran it, the period and the fields you care about. Without that note, a manual jira export history file is just a spreadsheet nobody can check.

Check: you can say exactly which work items are in scope before you copy any history.

2. What Jira’s Export gives you

On the search results, open ••• and choose Export.

1 2 3 Enlarge Enlarge screenshot

Choose visible fields when the search columns already show what you need; choose all fields for the wider set of current work-item fields the export offers. Atlassian notes that an all-fields CSV can include comments, but comments are not field-change history. Atlassian: Export issues from Jira Cloud in CSV format

If you came here for jira export to excel, export jira to excel or a jira excel export, the Excel CSV options are the native answer for current values. Changing the file format does not turn current values into past events, and neither does saving the jira csv export as .xlsx.

Why an export is not a history table

A field that is empty today may not always have been empty. In an earlier check, the Organizations field of a test request was set and then cleared. The export would show it empty; History shows both changes:

Enlarge Enlarge screenshot

Check: if the question contains “who changed”, “previous value” or “when did it change”, the standard export is not enough on its own.

3. Build the change table

Open a work item, scroll to Activity, open Show: Comments and choose History. Each field change shows who made it, the old and new values and the time.

1 2 Enlarge Enlarge screenshot

Copy each relevant change into one row:

Copy the time exactly as Jira shows it; a relative time such as “3 years ago” is not a date. If you copied only some events, call the file a manual extract, not a full export. If Jira does not show the actor or a value, write “unknown” rather than guessing.

Reading History in more depth — the relative times, automation as the actor, the audit log — is covered in How to View Jira Issue History: Status, Assignee and Field Changes.

Check: actor, field, old value and new value in each row come from the same History entry.

4. Narrow the items with JQL

JQL history operators can cut the number of work items you open:

project = ENGS AND status CHANGED FROM "Waiting for support" TO "Resolved" DURING ("2023-06-01", "2023-06-30")

On the test site this returned six work items. That is a list of items, not six spreadsheet rows: you still open each one and copy its History. CHANGED and WAS work for Assignee, Fix Version, Priority, Reporter, Resolution and Status. For a custom field or the due date, Jira answers “History searches do not support the … field”, and you read each item. Atlassian: JQL operators

How much manual work is it?

Three work items with one change each: three History views, three rows. Easy. Forty work items with about three relevant changes each: forty History views and about 120 rows to copy and check. The native method still works; the cost is the opening and copying.

Native export or an app?

Choose by the output you need, not by the name of a product category.

If you are looking at a jira excel plugin, confirm it exports past events, not just current fields in another file format. Before you rely on any issue history for jira app, open a sample: one row should name the work item, time, actor, field, old value and new value. A jira reporting app covers many reporting needs, so check that change history is really part of its data. When you compare jira reporting plugins, check custom fields, permissions, the date range and whether gaps in the data are visible. Teams with a developer can also read history through the Jira API, but that is an engineering project, not the manual workflow here.

Check before you share

Whatever produced the table, check one known event against Jira: open the work item, go to History, find the change and compare the field, old value, new value and actor with your row. Keep the scope note with the file. For a jira issue history report, one row per change is far easier to audit than one row per work item with several changes squeezed in.

If someone asks for a jira export ticket history, agree what “history” means first: here it is field changes, not comments, work logs or the admin audit log. The same goes for issue history for jira in general: it is the changes you see in Activity→History.

Before you finish the export

• The work-item scope matches the question, and the period is written separately.
• Current fields are not presented as past events.
• Every copied row comes from a History entry, with the time as Jira shows it.
• JQL was used only to find items, not as the record of changes.
• A partial file is labelled as a manual extract.
• At least one known event matches the final table.

Common questions

If you need this table often, Issue History Export – Excel & CSV for Jira exports one row per field change across many work items, custom fields included. It is free for teams of up to 10 users.