Moving to Jira Service Management

[Matthew Buchanan]

We currently have an on-prem Intranet server that I am in the process of moving everything on it to Confluence and Jira. 

On our intranet site, there are quite a few forms that I will be recreating in Jira Service Management Cloud and I was wondering if I had the ability to import previous form submissions into Jira Service Management Cloud. We do reporting on this data and having all of the data in one place would be much better than trying to put something together adhoc every time a report was needed.

Thanks!

[Angélica Luz · Accepted solution]

Hello @Matthew Buchanan,

Thank you for reaching out to Atlassian Community!

When it comes to importing data from other platforms, it’s possible to do this via CSV.

You can find the details on the documentation below:

• Import data from a CSV file

This method allows you to import the tickets from server to cloud, it won’t import the entire project. You can create the fields in Jira before importing or the CSV can also create the new fields. The limitations of this method can be found in this documentation: Jira Cloud CSV import.

If you have any other questions regarding this matter, please let us know.

Kind regards,
Angélica

[Matthew Buchanan]

Thank you @Angélica Luz ! I will take a look at this and let you know if I have any issues.

[Matthew Buchanan]

Thank you again for pointing me in the right direction. I was hoping you could help me clarify something. 

I see where I can import to a project, but how do I import to a specific request type? I assume it has something to do with the identifier in the URL string (it's different for each type of request type) but don't see where to indicate that in the import process.

Incidentally, I am using the CSV file import option.

Thanks again!

[Angélica Luz]

Hello @Matthew Buchanan,

When importing via CSV the request type is currently not supported. The importer uses a key par value that is not accessible via UI.

There is a feature request suggesting improvements for that:

• Provide a feature to import JSD Request Type custom field

There was also a bug related to this issue, but it was closed as “Won’t fix”:

• Can't import CSV generated from JIRA due to incorrect Customer Request Type format

Depending on how many tickets you are importing, you can make a bulk change and then change the request type of the tickets. If all of them are of the same type, that would be the best option.

Now, if you are importing too many tickets of different request types, the workaround would be to get these keys via database and this only our support can do. In this case, since you are using a free site, it’s not possible to create a ticket, but you can start a trial of Service Management Standard or Premium and create a ticket on support.atlassian.com/contact and mention the bug I linked above. After resolving the issue, you can change your subscription back to Free.

[Matthew Buchanan]

Thank you again for your help and explanation.

I will review the two links that you have provided. I understand that since I am on the free plan that some features may not be available to me; however, with the option of creating multiple types of requests under a project being available regardless of the type of plan, I don't understand why this wouldn't be supported under the UI.

The issue that I have with importing the tickets is that even with mapping to the correct fields and then updating to the correct service request type, I am losing information.

[Earl McCutcheon]

Hello @Matthew Buchanan ,

The primary limitation comes down to CSV export functionality for reporting purposes vs exports for migration purposes,  as the primary use case of CSV exports is generating reports in external systems the human-readable component is more desirable, and in current iterations, there is no option to collect the hash values in the CSV.  When using the CSV import option the portal Key option does not come through in the CSV export in the hashed value that ties the request type to the portal for backend operations. 

This happens because when the VpOrigin custom field used on the back end is to be filled in the newly created issue, using VpOriginCFType to create an instance of VpOrigin from a string containing just the request type will fail - this behavior is defined in com.atlassian.servicedesk.internal.customfields.origin.VpOriginManagerImpl#stringValueToVpOrigin: the correct value should be in the format of portalKey/requestTypeName.

covered in the example in the workaround in the Server request https://jira.atlassian.com/browse/JSDSERVER-1335 For example, "Get IT Help" in project TST will need to be replaced as "tst/get-it-help"  however on the backend the custom request type is represented and stored as a hash value for the unique identifier example: "tst/bc4b6686-1b4a-4f26-84d3-ecf184bafdd9". So the front-end user-readable values are rendered for reporting purposes in CSV exports but an import requires the non-human readable hash value.  If there is no portal key in the string (which is the case, since it would make import fail if the project key is different; yet it is not exported to the CSV, so we only have request type name) VpOprigin instance will be null and the issues won't be imported.

Ultimately when migrating from server to cloud using a site import option as covered in "Use Jira Site Import to migrate from server to cloud" will convey all the data for the request types as a direct data import however there are limitations in partial data import for combining multiple instances or project imports currently covered in more detail in "Migrate projects from one Jira Cloud site to another" and "How to migrate a project from Jira Server to Jira Cloud"  and "What gets migrated with the Jira Cloud Migration Assistant" 

But since you are migrating from a Server instance you can use the SQL noted in the workaround in the request https://jira.atlassian.com/browse/JSDSERVER-1335 in your database to get the hash values from the system backend to use in the CSV for the import to the new system, however, you will need to line up those values with the new value on the cloud back end and convert the exported values to match the import values on the cloud side.

I created the following Support request to get things started, noting that you will need to access the request and select the option to allow support to access the data before we can run the query to get the values:

• https://getsupport.atlassian.com/servicedesk/customer/portal/23/JST-684238

Regards,
Earl