Migrating issue data to Jira Service Management

When migrating data to issues in Jira Service Management, it is recommended to add a custom field to the Issue table to store the value of the record identifier field from the source platform. In the following example, a custom field Source ID has been added. If you already have a custom field for this purpose then you may use that. The field must also be added to the following screens in your Jira project:

• Jira Service Management: Incident Create Issue Screen
• Jira Service Management: Problem Create Issue Screen
• Jira Service Management: Change Create Issue Screen

If issues will be updated as well as created in your project, you will need to add the field to the View/Edit screens as well.

For all forms being migrated to the Issue table in Jira, add a mapping from the field on the target used to uniquely identify the record to the Source ID field.

To facilitate updates to existing issues in Jira, select the Source ID field in the Key Mapping tab and click Add >> to specify the mapping on this field. 

Note that the name of the Target Field on your Jira environment may differ from the one shown above.

Also note that it is recommended to set this to No Key Mappings if only migrating new issues as there is a performance hit when using Key Mappings.

In the field mappings, update the values in the Value Mapping of the Request Type field for the Issue table to match the request types on your Jira environment.

Also set the mapping for the Impact, Priority and Urgency fields using the Value Mapping type.

Ensure that the Project Key value is set for any Issue table mappings, either from a project variable in a Simple mapping type or hard coded in an Assignment mapping type.

When migrating child records such as comments, work logs and tasks, ensure that the Source Filtering is configured with the Filter by Inclusion to only migrate for those parents also migrated. 

See this article for more details.

In those same child record migration configurations, you can use the Source ID custom field from the parent Issue in any Lookup Query used with the Issue table. 

In this example, we can lookup the Issue Id of the Issue to relate the comment to it.

Various issue types are based on the Issue table but have fields specific to the type of issue the mapping is being configured for. Ensure these fields are added as appropriate. For example, when migrating change requests, you can add mappings for the Change reason, Change risk, Change type, Change start date and Change completion date amongst others.

If you are migrating into the Components field on the Issue or Request form, you must ensure that a component with the same name already exists in your Jira Service Management environment. This is especially true when migrating service requests and migrating the request items into the Request form.

When migrating to the Issue table within Jira Service Management, the Status and date fields will not represent the original source values. The status will be "Open" and the date fields will be populated with the date and time of migration. To overcome this, you should create mappings into the (virtual) table Issue Export. This is not a table in Jira but when you run a migration into this table in Precision Bridge, the original status and dates will be exported into a JSON format file that can then be imported into Jira to correct the status and date fields.

The JSON file can also include comments and work logs to ensure these also include the correct date and time of the original comment or work log using the GENERATE_JSM_NOTES_ARRAY function.

It is also recommended that the values set for the Status field in the Target Data Value of the Value Mapping be verified as these values are configurable in Jira.

The JSON file should be imported into Jira via the External System Import wizard located within the Settings > System section of Jira.