Import Jira Issues from Excel

Save as CSV first, and check what that changes

Neither of Jira's import tools reads .xlsx. The file has to be a CSV, so the first step for anyone starting from a spreadsheet is File > Save As > CSV, and that step is where values quietly change: Excel reformats long numbers into scientific notation, drops leading zeros from anything it thinks is numeric, and rewrites dates into whatever locale format the machine doing the export is set to. None of that throws an error. It shows up later as an issue with the wrong due date or a ticket ID that lost its leading zero.

Two importers, not one

Jira Cloud has two separate paths for getting a CSV into a project, and which one you can reach depends on your permissions, not on what you're trying to do.

• The bulk create wizard (available to any user with create-issue and bulk-change permission on the project) creates new work items only. Without extra permission granted by an admin, it caps at 250 rows per file, and it can't map a parent-child or epic relationship, so a CSV with subtasks needs the other path.
• External System Import, under Jira Settings > System > External System Import > CSV, is administrator-only. It handles larger files, Atlassian's own guidance suggests keeping files under roughly 1,500 rows and splitting bigger ones, and it can update an existing issue instead of creating a duplicate when the CSV includes a matching issue key column.

If you're not a Jira admin and need more than 250 rows or a hierarchy, the practical options are asking an admin to run the import or splitting the file into batches that fit the wizard you can already reach.

What Validate actually checks

Both importers have a step called Validate before the final import screen, and it's easy to read that as a dry run. It isn't one. Validate confirms the file parses, that a Summary column is mapped, and that the column-to-field mapping makes sense structurally. It does not confirm that every value in every row will resolve: a status that doesn't exist in the target project's workflow, a user who isn't a member of the project, or a priority name spelled slightly differently than the field's actual options all pass Validate and then fail, issue by issue, once the import is running. You find out which rows failed from the results log after the fact, and there's no bulk undo for the ones that succeeded. Fixing a bad batch means deleting the created issues by hand.

If the goal is updating, not creating

Everything above is about getting new issues into Jira. Changing the value of a field on issues that already exist is a different job with its own failure modes around option values and field access. See bulk updating Jira issues from an Excel spreadsheet for that case specifically.

Coming from an export

A common reason to import is that the spreadsheet started as a Jira export in the first place, edited, and now needs to go back in. See exporting Jira issues to Excel with a JQL filter for the export side of that round trip.