Migration Guide for the Risk Manager: from Server/DC to Cloud

Prior to using the Migration Assistant for the migration of risks, please familiarise yourself with the following:

https://support.atlassian.com/migration/docs/what-gets-migrated-with-the-jira-cloud-migration-assistant/

and

https://support.atlassian.com/migration/docs/compare-cloud-migration-methods/

Please try the migration first on your test environments to get more confidence on what you do!!!

Known Limitations:

1 - Severity and Probability field values will be migrated, but they will stay in a separate custom field. Thus the history is preserved, but from the point of migration new fields and values will be used.

2 - Jira links in some case will not be created (if the issue that is needed does not yet exist).

3 - Make sure all the usergroups and permission schemes will work after migraiton! Thus these needs to be reviewed.

 

Step by step guide:

  1. “Unlock” all the locked customfields from the database (locked fields will not be migrated).

For that you need to remove all “locks” from managedconfigurationitem table in Jira database.

First try to locate the table and see the content. Run SQL command:

SELECT * from managedconfigurationitem WHERE source ='plugin:com-softcomply-riskmanager-cloud';

Result should be:

In Jira Custom fields list all these fields are locked and managed by RM app:

 

In order to remove these remove the lines from the table by executing following SQL:

DELETE FROM managedconfigurationitem WHERE source ='plugin:com-softcomply-riskmanager-cloud';

Now you can check the table via UI. It should look like this (all fields created by RM app are manageable by the user):

 

  1. Run the migration assistant.

The Risk Manager App must be installed to the cloud environment before. Then all the fields that are migrated will have suffix (migrated). See the image below where we have 3 different fields (one created by migration assistant):

 

The migration just takes all the custom fields and “copies” them to your cloud instance.

NB! Make sure there are no errors. Also plan the order of projects to be migrated cause if some projects (e.g. mitigation actions) are not migrated, then the links could not be created.

 

  1. Configure the migrated project:

  • Review all permissions first - In order to add new columns to the table you need to have Jira Project Administrator permission.

  • Add all the migrated fields to the view/edit screens i.e. Harm (migrated), Cause (migrated), Severity (migrated), etc…

  • Enable the risk management on the migrated project from project settings → Enable Risk Management. Pick the closest risk model there is, pick correct issue types.

  • Pick the closest table template while activating risk management in the project.

  • NB! do not yet add the migrated fields to the table.

 

  1. Find out the ID-s of existing and newly created (migrated) customfields.

First create list of fields you wish to display in the table that you currently do not see. E.g. Harm (migrated), Severity (migrated), etc.

NB! Some fields might not have the suffix (migrated). If there are some custom fields you have created manually in your server (fields that are not created by our app). These you can just add to the table by clicking “Add new column” and select type “User created custom field”. Only the fields that are created by our app must be handled by SoftComply.

Thus find all these field names that you see on your Jira issue view, but do not see yet in table. For example after the fields are added to the screens you can see:

There are two “Hazardous Situation” fields. The last one was migrated and this is a value you would like to retain and use also in the future. Also this field has history already visible under Issue history.

 

A - In order to display this data in table you need to find out the names of all these fields (and with names we can find the id-s from the API).

 

Next lets find the ID-s for the fields:

In your browser please enter following address while you are logged in as global admin (only admin can see list of Jira custom fields:) :

https://your_host.atlassian.net/rest/api/latest/field

You should see long list of fields in Json structure like this:

... ,{ "id": "customfield_10049", "key": "com-softcomply-riskmanager-cloud__probability-final", "name": "Probability (Final)", "untranslatedName": "Probability (Final)", "custom": true, "orderable": true, "navigable": true, "searchable": true, "clauseNames": [ "cf[10049]", "Probability (Final)" ], "schema": { "type": "option2", "custom": "com.atlassian.plugins.atlassian-connect-plugin:com-softcomply-riskmanager-cloud__probability-final", "customId": 10049 } }, { "id": "customfield_10124", "key": "customfield_10124", "name": "Severity (migrated)", "untranslatedName": "Severity (migrated)", "custom": true, "orderable": true, "navigable": true, "searchable": true, "clauseNames": [ "cf[10124]", "Severity (migrated)", "Severity (migrated)[Dropdown]" ], "schema": { "type": "option", "custom": "com.atlassian.jira.plugin.system.customfieldtypes:select", "customId": 10124 } }, ...

There you can see the ID-s of fields of the fields you have. Its easy to find the text “migrated“ to jump to the fields. If you have time you can just extract the necessary ID-s. If you do not wish to do that save whole JSON data to text file and forward it to SoftComply.

 

 

 

What does SoftComply do:

  1. Will update the table configuration with new field id-s. Thus the table will display now in Cause column field “Cause (migrated)” instead of “Cause”.

  2. Will update the table templates fo you if you wish to keep also future project with this new field. Otherwise the new risk projects will always have in the table data from customfield_10123 and you have in the system 2 fields that are used.

 

When SoftComply has finished updating database your table should contain already new data!