Jira Issue Type Hierarchy: Remapping Types After Cloud Migration

The migration plan ended clean and the issue counts match. Then you open an epic and the child stories sit in a flat pile, the parent link is empty, and nobody remembers which level each sub-task was meant to sit on. The issue types came across, the hierarchy around them did not line up the same way.

Issue type hierarchy is one of those migration details that looks fine in a report and feels broken in a backlog. This guide explains how the hierarchy is wired in Cloud, what JCMA does and does not move, and how to remap the layers in an order that avoids a second cleanup pass.

How Jira Cloud Organizes Issue Types

Jira sorts issue types into hierarchy levels. The default set places sub-tasks at the bottom, standard types such as Story, Task and Bug in the middle, and Epic at the top. Cloud Premium and Enterprise allow extra levels above Epic. The level decides what an issue is allowed to parent, a story can hold a sub-task, an epic can hold a story, and an issue sitting at the wrong level simply cannot form the link.

Issue types do not attach to a project one by one. An issue type scheme assigns a set of types to one or more projects, and the scheme also sets the default type and the order users see in the create dialog. Screens, workflows and field configurations attach to the type itself. That separation matters, because JCMA can move the types while leaving the scheme and the levels slightly out of step.

What JCMA Does With Issue Types and Hierarchy

Issue types are matched by name against the Cloud site. A type named Story on both sides is treated as the same type and reused, which is why most defaults land cleanly. Custom levels, scheme assignments and parent relationships are a different story.

Issue types match by name, but schemes do not

JCMA brings the types and the issue type schemes across, yet a scheme already in Cloud may assign a different default type or a different order for the same project. When the source and destination schemes disagree, users see the wrong default on create, or a type that quietly disappears from the picker.

Workaround: export the issue type scheme list from both sites before the cutover, compare default types and member sets project by project, then align the Cloud scheme to the source before users notice. Screens and workflows that reference a type by name are covered in the JCMA post-migration checklist.

Epic link and parent link can arrive empty

On older Data Center instances the epic to story relationship lives in the Epic Link field. Cloud leans on the Parent field and the hierarchy configuration instead. When the two do not map, epics and stories arrive as separate issues with no relationship, and the board shows a flat list.

Workaround: after the run, look for epics that have no children by checking the child list or the Parent field, then relink the pairs by hand. If Epic Link arrived as a duplicate custom field, clean that first, the merge guide covers merging duplicate custom fields safely.

Hierarchy levels are a single global setting

The hierarchy configuration lives at the site level, not inside a project. JCMA does not carry custom hierarchy levels across as a preference, so an instance that added a level above Epic on Data Center arrives with the Cloud default, and that type may fall outside the hierarchy entirely.

Workaround: rebuild the hierarchy under Issues, then Issue type hierarchy in Cloud to match the source before you remap schemes. Do it first, because the levels decide which parent links are even legal.

Re-runs leave duplicate fields that break the remap

A second or third migration run tags colliding custom fields with "(migrated)" and "(migrated 2)". Fields that carry issue relationships, such as a parent reference you added on Data Center, can end up split across two IDs. Any JQL that filters on the old ID then misses half the data, which makes the hierarchy look wrong even when the links themselves are fine.

Workaround: scan for "(migrated)" fields before you start remapping, merge each pair back into its original, then relink. The background on why JCMA creates duplicate fields explains the mechanism, and removing the (migrated) suffix is the step that follows the merge.

Remapping Issue Types After Migration, in Order

Work top down, because each step decides what the next one is allowed to do.

1. Rebuild the Cloud hierarchy levels so the same types sit at the same level as the source.
2. Align each issue type scheme, its default type, member set and display order.
3. Reattach screens, field configurations and workflows that reference the remapped types.
4. Clean out any "(migrated)" duplicate fields that sit on those types before touching data.
5. Relink epics and sub-tasks, then verify with a board that filters by parent.
6. Spot check the create dialog so each project offers the right default type.

Most of the pain here is not the hierarchy itself, it is the duplicate fields that form around it and quietly split the relationship data. If a test run already produced "(migrated)" fields, Migration Helper scans for them, matches each to its original, compares the schema, and merges in one click, filling the original only when it is empty so Cloud native data is never overwritten. It runs entirely on Forge, and teams of 50 or fewer users can scan and merge free.

Resources

• What Does JCMA Actually Migrate? A Field-by-Field Breakdown
• What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields
• How to Merge Duplicate Custom Fields Safely
• JCMA Post-Migration Checklist: What to Clean Up After Migrating
• Atlassian: What gets migrated with the Jira Cloud Migration Assistant

A clean hierarchy depends on clean fields underneath it. Migration Helper shows the affected issue count per pair before you act, merges the safe ones, and leaves conflicting schema for a manual look, so the relationship data stays whole. Install Migration Helper from the Atlassian Marketplace.