Impact of hierarchy level removal?
Asked by Joanna Zembrowska:

We have 3+ levels in Jira Portfolio:

* Idea
  * Scope
    * ++Business Epic++
      * Epic
        * ...

We'd like to **remove** Business Epic from this hierarchy.

If we do that, would Epics that had Business Epic as Parent Link automatically be attached to correct Scopes?

Or should we first do some manual changes before removing the level?


Answers:
author: Earl McCutcheon
body: Hi Joanna,

You will not be able to remap the epic to the scope initiative level while the business epic level is still present, so you're going to have to remove the hierarchy first then go back with the manual changes as the hierarchy will not automatically remap the the next level when you drop the Business Epic hierarchy level.

When you remove the Business Epic hierarchy the parent link on the epics will not show any association present, and all previously mapped Epics will show up as "No Scope" (scope being the next level up) in the parent link field from portfolio, and there would be no referance point to rearrange the data, so it is a good idea to add a unique identifier to the issues acting as an anchor for teh manual changes, and this will be a bit manually intensive but overall there should not be an overwhelming amount of initiative level issue types and should progress pretty quickly.

A good approach here is to flag all the various grouping of Issues in the Business Epic and epics levels that are going to be affected with a label relating to the hierarchy remap for quick referance option to use as a validation point post modification. [Perform Bulk edits](https://confluence.atlassian.com/jiracorecloud/editing-multiple-issues-at-the-same-time-902498099.html) to update the values. You can use the issue key that your mapping the epic too, something like the following if the issue keys were in SCOPE-X ranges "scope_1_remap", scope_2_remap", etc... for each scope association that will need to take place for the epics.

Lets say for exe that you have 2 issues at the scope level SCOPE-1 and SCOPE-2. both have 10 nested Business epics in the key range "BE-1" to "BE-20" each of those BE's has an additional 5 epics nested.

As the first step identify and label the Epic in the BE 1 to 20 range for each of the scope grandparent issue nested in that chain that need to be linked to Scope as the parent link with:

```
issuekey in childIssuesOf("SCOPE-1") and issuetype = "Epic"
```

Bulk edit these issues and add label "scope_1_remap" then do this again for SCOPE-2 and "scope_remap_2", etc... for each scope association that needs to occur. This gives you that unique identifier to validate off of after the hierarchy is removed

Next decide what your doing with the "Business epic" issues, i.e. are you moving them to become an epic or are you deleting them or are you just ignoring them, whatever the choice its a good idea to flag them with a label as well for that quick referance point, back to how it was configured previously.

The JQL to identify these would be either modifying the issuetype from the query above like this:

```
issuekey in childIssuesOf("SCOPE-1") and issuetype = "Business Epic"
```

OR you can also pull directly from the parent link field with to get the same set of issues (Shorter query and deals with one hierarchy not everything below the noted issue that the previous query is calling on):

```
"Parent Link" in ("SCOPE-1")
```

I'm just adding the optional JQL as a referance point as portfolio JQL could come in handy for you later for other projects, additional details on available Portfolio JQL can be found [HERE](https://confluence.atlassian.com/jiraportfoliocloud/searching-for-portfolio-for-jira-custom-fields-in-jql-941619014.html) and [HERE](https://confluence.atlassian.com/jiraportfolioserver/searching-for-issues-using-portfolio-details-940678957.html)

Repeat as necessary to get the Business Epics flagged with a referance point label to use as needed based on your demission.

At this point you can remove the Hierarchy and you will have a maintained referance to the previous layout with the labels set on the issues (You can also add the hierarchy back at any point and all the mappings will still be there in the DB for any issue that has not had the Parent link field modified manually, once you modify the field the mappings are gone with no recovery option other than manual association based on those labels).

Now you can go back to the issue navigator and use your labels for the remap. using:

```
labels in "scope_1_remap"
```

[Make sure the Parent link field is added to your edit screen](https://confluence.atlassian.com/jiraportfoliocloud/showing-portfolio-custom-fields-in-jira-software-856708725.html), and Bulk edit the issues setting the parent link field to SCOPE-1, repeat for each epic to scope remap chain and you should be all set after you recalculate the plan, you can also switch to list view in the issue navigator and add in the parent link and labels fields to you columns to do an additional once over on the data to verify everything lines up before you recalculate.

Regards,  
Earl

comments: author: Joanna Zembrowska
body: Thank you for the help! Although as we have Jira in Cloud and not on server some of the JQLs don't seem to run, but we'll manage anyway.

Just to doublecheck - will we just lose Parent Link from Epics to BE, or will BE issues be removed entirely?


author: Earl McCutcheon
body: Hi Joanna,

When you remove the BE "Business Epic" initiative hierarchy, the issues will still be there but as a standard issue type in the hierarchy now, (so considered at the story level below the epic level) just no longer considered an initiative. Unless you want to get rid of them because you're no longer using the type, and manually remove the issues, which you could do by removing the issue type from the projects issue type scheme and converting the existing BE issue to another type.

Regards,  
Earl


Tags: advanced-roadmaps

hierarchy