Jira hierarchy import

Import Epics, Stories and Sub-tasks from Excel to Jira

Hierarchy imports are useful for backlog migration, implementation plans and client project structures prepared in Excel. They also need careful review because a wrong parent can put work in the wrong place. The app supports hierarchy setup where the workbook and Jira project configuration allow the intended relationships.

Try it for freeReview before importView product
Build hierarchy from Excel columns when the Jira project supports the intended structure.

Why hierarchy is hard in spreadsheets

Spreadsheet hierarchy is often obvious to a human reader but ambiguous to software. Blank cells may mean same value as above, indentation may not survive export, parent rows may be filtered out and repeated names can create duplicate paths. Jira configuration also matters: issue types, parent-child rules, required fields and permissions can differ by project.

How to prepare columns for issue type, parent, links or hierarchy data

Use explicit columns where possible. Helpful columns include Issue Type, Summary, Parent Key, Parent Row, Epic Name, Story, Sub-task, Linked Issue Key and any stable external ID used by your source workbook. The exact names are less important than consistency and reviewability.

Column patternExamplePurpose
Issue type per rowEpic, Story, Sub-taskTell Jira what kind of issue each row should become.
Parent keyPROJ-123Attach new work under an existing Jira parent when allowed.
Parent row referenceREQ-100 points to FEAT-20Connect rows inside the workbook before Jira keys exist.
Multiple hierarchy columnsEpic, Story, TaskUse separate levels when the workbook is structured that way.

Common example: Epic to Story to Sub-task

A migration lead may receive a workbook where each row includes Epic, Story and Sub-task columns. The app can use multi-column hierarchy setup so repeated values form parent paths, while validation catches missing middle levels, ambiguous references and unsupported parent relationships.

Review before import

Do not treat hierarchy import as a blind upload. Review the generated parent-child relationships, issue types, required fields, duplicate hierarchy paths and skipped rows before confirming. If the structure is uncertain, run a smaller import first or keep the initial import flat under a selected parent.

Practical checklist

Related guides

Import structured backlogs with review

Use the product workflow to validate hierarchy before Jira issues are created.