Prior to using the Migration Assistant for the Risk Manager Plus, 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/

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:

Result should be:

Open

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

Open

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

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 can should 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 risk models and migrated project:

• Review all permissions first in Jira target project and Risk Manager Plus app. In order to run imports you need to have create issue permissions in target Jira project. In order to edit table templates and risk models you need to be Risk Manager Plus Administrator (you can add users into the role via Apps → Risk Manager Plus → Settings).

• Prepare all risk models and risk table templates you need to use in Jira projects when you enable risk management in Jira projects. Note - in cloud the models are global i.e. you can reuse same model in multiple Jira projects. In server each project had actually separate risk model, even when they seemed to be same (same titles and same descriptions, but different internal id-s).

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

  • The Severity, Probability and Detectability values will be no longer saved as custom fields, thus these field you can make read only and/or hide from the screens. Suggestion: make them visible in the beginning just to validate data content.

  • If you import everything from CSV, then the old issues we would suggest to keep in archived/read only project just for history. Then all the data is entered as new data from CSV file. Then all the risk characteristics are also imported and you can start from clean state.

• When you plan to use imported Jira issues, then you need to reset all the Severity, Probability and Detectability values yourself.

  • In that case you can map all the custom fields you migrated as columns in the new risk table template, except the risk characteristics! These are in cloud stored as forge storage objects and you need to initiate the values yourself manually. The old fields and the Jira issue history will be there for your history, but the new risk values will be stored into new place (Jira issue entity property).

• If you do not care about the risk values history and want less work while setting characteristics values you can just use CSV export and CSV import. Then you can import all the data (together with risk characteristics values) by using our import feature. NB! there is no “update issues” feature for the import, thus try it out first and in production run it once. It also means that during the import the links are not imported.

• As the last step enable the risk management on the migrated project (or new project) from Risk Manager menu on left project panel. Pick the risk model you have reviewed/prepared and pick correct issue types for your risks.