Hello!

We’re looking to improve the import experience in Jira and are keen to understand how our community is using the Jira Import Module (JIM). If you’ve used JIM to migrate/move data into Jira recently, we’d love to hear about your experience. Please take a few minutes to fill out this survey. Your feedback will help us learn how we can improve your experience in importing data.

Survey link - https://forms.gle/NYNkmS92r96z42QV9

Thanks!

Prashanth M
Product Manager, Jira Platform

We are bulk importing 1000+ issues at a time, this bug has a negative impact on mission-critical global work item tracking.

Still in absolute disbelief that this has been known about since Dec of 2018. Do we have an update on this bug yet? Can we get this moved from Gathering Impact to actually fixing it? I have a migration of a platform of over 18k users with over 2.5 million issues. Due to timing, and bugs in JCMA preventing use of that tool, CSV import is absolutely critical to us being able to migrate to the cloud. I can't stress enough the importance of this feature - when we signed up for the cloud, this was something so basic in the tool, we didn't think we needed to test it out. 

I just encountered this and had to spend hours doing data cleanup looking back at issue history, one by one for a over 20 issues. Thankfully this was a small project, however I've in the past done CSV imports on data center to the magnitude of 10k+ issues at a time. This could have killed our data in the cloud. Echoing above, this is not a minor issue - this is a show stopper issue if we want to import users from other tools down the road. This is painful - we need a CSV solution to include in our tool box for getting both tactical and strategic ways of getting data into Jira.

I believe this is more than a minor severity. Since there is no warning that this is occurring and it is so difficult to roll back. My team reported this issue because not only did the import ignore the Project Key on the import, it also reached into other projects outside the one that was selected by the admin during import to match an issue that had been moved.

Example:

Using your CSV example above, if the SCRUM- project had an issue 379 that was moved to another project and became KANBAN-234, when this import was done not only did it go update KANBAN-234 as if it were still SCRUM-379, it changed the issue to SCRUM-234. Keeping the number from the new project and pulling it back into the SCRUM project. Which also overwrote the original SCRUM-234 issue which we can now no longer find.

It was sheer luck that we even discovered this because when it happened in our project it was issue #1 so it stood out. It is possible that there are others that we are not aware of.

It will be a problem if the full issue key is not checked before the update is done via Export System Import.  It can be accidently updating the incorrect project.  An other enhancement is suggested (JRACLOUD-75185) to add a validation process in the external system import in case the project selected on the screen is different from the full issue key in the file.  Please consider.  It will be very difficult for us to undo if the update is done incorrectly.