Migrate to classic but retain Epic Links

Andrew Beak

Hi,

I want to migrate to classic because I'm deeply dissatisfied with the "next-gen" product.  I don't think it's mature enough to be in the market and frankly if there were a convenient way to migrate away from Jira entirely I would do so.  There are better tools available than "next-gen" that are cheaper and faster than Jira.

Anyway, notwithstanding the motivation to migrate to Classic I have a problem with how Atlassian will throw away my Epics:

On the Atlassian manual page at https://confluence.atlassian.com/jirasoftwarecloud/migrate-between-next-gen-and-classic-projects-957974933.html they note that:

Jira moves your epics across if you map them to an epic issue type in your new project. But, you'll lose the relationship between your epics and their child issues. The child issues themselves will sill exist, but the links between them won't.

This is a huge problem for me.  Is there a way to work around this, or am I doomed to either staying stuck in "next gen" or migrating to a brand new platform?

 

Andy Heinzer

Hi Andrew,

Sorry to hear that you are not very happy with next-gen here.  I understand that you want to try to migrate your data into a Classic project, but our own documentation is telling you that the process to import this data will not preserve the epic links in place currently.  The documentation is correct, this is not something you can easily just convert. 

There are a couple of different problems with why this doesn't work.  In Classic projects, all epics have to have a custom field value in the Epic Name field.  All issues in that epic have a separate custom field called 'Epic Link' that reference the issue key of the epic itself.

In Next gen projects, none of that is true.  Those custom fields are not filled out at all in either case.  Instead there is only a parent field that references the issue ID value.  Making it more confusing is that subtasks also use this parent field to refer to their parent issue.   But we can't use the issueID itself in that field when trying to associate it with the epic, we really need to use either the issuekey (which can change upon a new import) Or we need to use the Epic Name (which is a kind of description of the epic, that doesn't exist in next-gen).

You can see in a classic kb there have been other users that have had this problem well before next-gen even existed, check out Cannot Import Epic Link from CSV due to Incorrect Format. It explains more about this limitation when trying to import epic links into a Classic project.

It might be possible to take a page from that KB to make this work.  I'd suggest that you first just export the epics into a CSV.   Then export all the issues (including epics) into a second CSV.  From there you can try to import the Epics CSV first, and create those issues.  Once that is done, we need to know what the epic issuekey is.  From there we could take that information and try to match up in the 2nd CSV all the issues in that epic, matching the parent value back to the epics themselves, and then updating the "Epic Link" of those issues to use that new issuekey of that epic.  Granted this is likely going to be a lot of data munging to the 2nd CSV to make this work.  Which is really unfortunate.  But so far I don't have a better work-around than this.

That said I created a next-gen request to try to track this specific problem and see if we can't find a better solution in the long term over in JSWCLOUD-18643.

Please let me know if you run into any problems with this suggested approach.

Andy