Another use case: Our team has requested a change in the datatype of a field, because it has a better UI for their workflow (from Checkbox to Multi-Select). I cannot change the field datatype (a separate functionality gap, IMO), but I can create a new field with the new datatype. Obviously if creating a new field, I would like to populate it with the old field's data and delete the old field, so that users aren't having to search across two fields to find relevant historical issues or include two fields in filters, etc. However, to populate the new field with the old field's data will require updating thousands of closed historic tickets that otherwise haven't been touched in years, which is its own data pollution – I don't wish to make these appear to be active/recently active tickets. So, we abandon the whole project and stick with the datatype that has bad UI, because migrating the data would create an even worse user experience. 

Importing and post-importing old projects and custom fields from a Server instance to Cloud.

It is not always possible to import all the issues when they do not exist and therefore would be created during the import preserving the "Updated date" (as, at least, someone witnessed in one of the linked issues).

Sometimes, you need to add, tweak, fix data. If you imported several thousands issues already, and you have all the project environment set, maybe even in production already — it is not possible to just delete the project, and start it all over again.

As it was said in... sorry... 23/Jun/0013 1:27 AM, "I don't think we are going to fix this issue ... Circumventing it would require serious hacks and operating directly on DB".

Perhaps. Yet we also have some handcraft to prepare the data for import operating directly on DB and having a small chunk of our time spent just in vain is not a comfortable user experience.
There isn't even a hint under the "Updated date" mapping that it will not work. Like a hint under the "Comment body" which reminds to concatenate date + author + comment into one.

I don't know the architecture of the Cloud Jira to be honest. But wouldn't it be possible to trigger the "Update issue" event after the import actions on that issue, passing datetime from CSV as an argument to the event handler?

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

When migrating from Server to Cloud not all custom fields are supported because of new Cloud API. So we need to re-migrate them by using of CSV.

But we don't want to touch the 'Updated Date' of more than 100K issues because of this inability.

Please find the solution to bring custom fields values without updating updated date 🙏

With kind regards
Slava

The External System Import has been removed from JIRA Cloud.

Only importing from CSV and JSON are currently supported. Please refer to below KB for details on how to import from CSV:

• https://confluence.atlassian.com/adminjiracloud/importing-data-from-csv-776636762.html

Difficulty aside, this is a needed fix. There are problems with importing custom fields with the importer, so it makes sense to import them with csv - except for this problem. Losing information about last modification date is not a good option.

I don't think we are going to fix this issue. CSV import supports "updating" and "Date Updated" is automatically set to "now" by JIRA when doing the update. Circumventing it would require serious hacks and operating directly on DB, which would make JIM more fragile.