How are we realistically supposed to create CSV files to update cloud sites?

[Jean Dupree]

I have a pre-migration "needs attention" summary that has 38 rows which state "If you require this custom field, re-create it in your cloud site and use a csv import to update the issues post migration."

After that, I literally have hundreds of thousands of rows which state "If you require this field value, use a csv import to update the issues post migration. "

Is there a shortcut or some method to gather all of this info?

Seriously, how are we supposed to manually parse this data and hand craft a CSV from this? 

How is THIS better than site import???????

[Krista Stellar · Accepted solution]

I hear you about the frustrations of using the JCMA and it's limitations. I am from a solution partner team and we are encountering the same situation you are describing.

I'm sure you have already read this, but just in case, please see the instructions at the bottom of the page talking about what the JCMA doesn't migrate: https://support.atlassian.com/migration/docs/what-gets-migrated-with-the-jira-cloud-migration-assistant/

It will be tedious to migrate the data missing from the custom fields but perhaps not as gnarly as you may currently be thinking.

You will have to manually create the custom fields in the cloud; in your case it sounds like there are 38 of them? If so, yeah, that won't be much fun at all. Once it is done, it's done.

Once the fields exist in the cloud instance, then you will use the CSV export from server to get the data in existing issues from server to the cloud. You don't need to parse the CSV to include only affected issues, so you could select all the issues in a project, or your entire instance if all projects are affected. You will need to parse the CSV to remove a bunch of columns as you only need issue key, issue summary and the custom fields.

The import CSV action will only update the issues with the data in the CSV - so if a row has custom field values those will get updated. If a row doesn't have custom field values nothing gets updated.

One last thing to check - if you believe a custom field *should* be able to migrate with the JCMA then have a look at this bug report as there is a workaround for some cases where custom fields end up blocked by the JCMA: https://confluence.atlassian.com/cloudkb/jcma-doesn-t-migrate-supported-custom-fields-1129690600.html

And lastly, I highly recommend you contact the support team. Raise a migration support request and get help that way.

Best of luck!

[Jean Dupree]

Thank you @Krista Stellar - I hope you'll forgive me for asking a dumb question, but are you saying that ultimately I only need to be concerned with the top 38 rows?  Basically I will just do a search for each field?

Here's the catch though - Jira has limits on CSV export.  How can I export all of them?

This is where a step-by-step document would be REALLY helpful.  Its strange that there is so much handholding in some documentation (NOT A COMPLAINT - SPOON FEED ME EVERYTHING) but at other times it seems like we're left to fend for ourselves in a burning building that's somehow also sinking to the bottom of the Marianna trench as we're being interrogated by Jack Bauer telling us that we're running out of time.

[Derek White]

I regularly do something similar to get Tempo Account custom fields migrated over.

Here are my instructions for creating the CSV, you will have to alter them a bit for your use-case.

1. Perform issue search for Account is not EMPTY ORDER BY key ASC and note issue count.
   • Count: <record count here>
2. Modify Jira settings to allow the export of a large number of issues.
   1. Admin (gear) → System → General Configuration → Advanced Settings
   2. Set jira.search.views.max.limit to a number greater than the issue count and note previous value.
      • Previous: <record prev value here>
   3. Set jira.search.views.default.max to the same as ...max.limit and note previous value.
      • Previous: <record prev value here>
3. Return to previous JQL search.
4. If not in List View, switch to it.
5. Modify columns to show Key and Account only.
6. Export to CSV (Current fields) and download.
7. Reset settings to previous values, in the same order they were modified previously.

HTH!

[Krista Stellar]

Kudos to @Derek White for those detailed instructions! I had not yet encountered the need to adjust the settings to export a large number of issues so this is GREAT information.

@Jean Dupree your comment is hilarious and the TRUTH. So much attention to detail in some places and a complete void in others. Your question is a great one and I'm glad you raised it. Did Derek's message answer your question about the searching for the top 38 rows?

Based upon Derek's approach you could create one query per custom field (38 queries) or a single query with each condition joined as an OR (e.g. custom-field-1 is not empty or custom-field-2 is not empty). I had suggested you select all issues in a project or list of projects and don't worry if they have values for the custom fields (or not). The scope of your query is up to you. If your query includes issues that do not need to be updated - they have no value for the custom field - then the import to cloud will have no real effect. For this reason I hadn't suggested using a query that would narrow down your search results. Essentially you have options for how to go about this part of the puzzle.

Good luck!

[Ralf Becker · Accepted solution]

Yep. And not everyone is a data engineer and has the tools and the knowledge to do, what a migration tool could easily perform. 

[Jean Dupree]

Are there any articles out there or tips on how to do this? I feel like I need to live with data loss.