Migrate Jira issues (tasks + subtasks) to another instance using CSV

Anthony van Harten

Hi,

I'm trying to migrate a project that contains 9.000+ issues out of an instance for which I don't have admin rights, to another instance where I do have admin rights.

To do the export I'm using the builtin export functionality from the issue list screen, with the workaround to extract all issues above the first 1000 using these instructions:
https://confluence.atlassian.com/jirakb/increase-issue-limit-for-excel-exports-in-jira-cloud-779160811.html
This results in multiple CSV files each containing 1000 issues (both tasks and sub-tasks) including all comments, which is what I need.

However, I run into 2 problems:

• Concatenating these files (to do the import in one go) by hand is next to impossible because each file is generated with varying amounts of columns for some of the fields, like comments, attachments and versions.
  For example:
  If I generate an export of issue A that has 2 comments, the export-file will contain 2 comment-columns.
  If I do the same for issue B that has 23 comments, the export-file will contain 23 comment-columns.
  Simply combining these files (making sure only the first row contains header information) breaks the import because multiple fields are not in their expected places.
• If I don't concatenate the files and fall back to importing each file of 1000 issues one at a time, I get to the next problem, which is with sub-tasks. They are only recognized by the CSV importer if both task and its related sub-tasks are in the same import-file. If they are spread across import-files the sub-tasks are not recognized as such because the issue-id and parent-id (which the importer uses to map them together) of all issues are regenerated upon import of each file.

I've been fiddling around with this for a while now and I don't really know how to approach this.
Are there any tools (freeware or commercial) available that will either:

• concatenate the default export-files in a way the import-tool will recognize, or
• allow for migrating issues from one project to another across instances via other means?

I can request the admin on the originating instance to install plugin X or Y to make a proper export possible, but I would have to be sure that I get what I wish for :-)

Or is there some other option that I did not think of?

I'm aware of the export functionality in the admin-console, but this adds data to the export that we don't want in the new project.

Prince Nyeche - ELFAPP

Hi @Anthony van Harten 

Welcome to Community! This is quite a pickle but there's always a solution. Looking at your description, you've fiddled with a couple of approaches. So here's a little idea on the problems you've mentioned.

Firstly, on Jira, export is limited to 1K issues. Now the problem with that as you've noticed comes with sub_task issues. To go around this problem, you can either export all Standard Issue types separately and sub_task Issue type separately. That way you could do an import of the epics first (or other higher hierarchies), then Stories, bugs, task etc  and afterwards you perform an import of their respectively sub_task which comes with parent Id. Sub-task depends on the Parent id field to know which Parent it belongs to, so that is what is essential here and for stories, bugs, task require the Epic link field in order to match them to an Epic.

Secondly, you can install a Free Add-on called Jira Cloud for Sheets, on the Instance A which is a Jira add-on for Googlesheet that you can connect to your instance to grab all the field but I'm not certain this grabs the comment field. It's excel counterpart (Jira Cloud for excel) might have similar issue with the comment field but you can look into that option to see if comments can be included in a 9k export.

Thirdly, concatenating files of uneven columns and rows is somewhat very difficult but not entirely impossible. You can do this with Python's Pandas if you're familiar with Python, otherwise I'll suggest you look into the above suggestion.

Lastly, performing an entire export of the XML backup and separating the files is not an easy task as well when there are lots of data to filter out, so I wouldn't want to go with this option. So with the little ideas above, you can add that to your list of options to see which could easily work out for you.