Migrating from Server or Data Center to the Cloud
Who should read this page?
This document is for Jira administrators who are planning to migrate some, or all, of their projects from Jira Server or Jira Data Center to a Jira Cloud instance. It's specifically about the Risk Register app and explains how to include risk data in the data migration. Refer to the Atlassian Migration Centre for more general information about server-to-cloud migrations.
For conciseness, we'll hereafter refer to Jira Server and Jira Data Center collectively as 'the server'.
Why is this document necessary?
Atlassian produces an app called Jira Cloud Migration Assistant (JCMA), which you can install in your Jira Server or Jira Data Center instance via the Atlassian Marketplace. The Risk Register app augments the JCMA to include risk data along with the core data - projects, issues, users, workflows, and so on - that JCMA migrates natively.
This document will inform you about the operation of the Risk Register part of the automated migration and help you prepare for a smooth migration effort.
Support for automated migration of Risk Register data is provided by a combination of the JCMA and the Risk Register app. The minimum versions of those apps required for automated migration are:
JCMA version 1.6.5
Risk Register version 6.2.5
When you include Risk Register in your automated migration with JCMA, various risk-related data are bundled up and delivered to the target Cloud instance. Those data include risk registers, risk assessments, and the values assigned to Treatment and Realization custom fields. You'll need to prepare your Jira Cloud instance to receive the risk data before beginning the migration process.
Updates to Jira issues in the cloud
Risk Register uses data transferred from the server to perform updates on issues in the cloud. In so doing, it does not attempt to preserve the corresponding data that may already be present on those cloud issues. Those data are risk assessments (impact, probability, and risk level), Treatment values, and Realization values.
Since your data migrations will normally be for projects that don’t yet exist in the cloud, the overwriting of risk values is not normally a concern.
The migration will always create new risk registers in the cloud corresponding to server-side projects that are set up as risk registers, and which have been included in the data migration.
Risk model compatibility
It's important to understand that the Jira Cloud edition of the Risk Register app supports only one risk model applied globally on that instance. That differs from the Jira Server and Jira Data Center editions, which support multiple risk models. Any risk assessments included in your data migration will be mapped onto the global risk model in Jira Cloud as follows:
· Impact and probability values are assigned to corresponding values in the Jira Cloud risk model.
· Risk levels are set to calculated values in the Jira Cloud risk model.
An example best explains the concept of impact and probability value correspondence. Suppose you migrate issue RISK-123 from the server to the cloud. The impact assigned to RISK-123 is Medium. Let's determine the corresponding impact value for RISK-123 in Jira Cloud. First, we need to align the impact values from the relevant risk model in the server with the impact values from the (and-and-only-one) risk model in the cloud. Here's how that alignment might look:
You can see that we sort the impacts so that the most significant values are listed first. Medium is the third value in that list, so we assign RISK-123 the third impact value on the Cloud side, Moderate.
WARNING: If your risk model in Jira Cloud is smaller than the relevant risk model on the server, some information could be lost. For example, if your risk model on the server has five impact values, and the risk model on the cloud has only four impact values, any impacts assigned that fifth value on the server will be left unassigned in the cloud.
Before starting the automated migration process, we recommend changing the risk model in Jira Cloud to make it at least as large as any risk model in the server.
The Treatment and Realization custom fields
This section explains how the Risk Register app migrates the values of the Treatment field and the Realization field, which are installed by the app and which have a special field type, Risk Factor.
Because the Treatment and Realization fields have a special type, they are not included in the base migration performed by JCMA natively. Risk Register performs its own migration of those fields, alongside risk assessments.
Most customers won’t need to perform any preparation steps for the migration of Treatment and Realization values. If, however, an administrator has manually changed the options for those fields in the server, you may need to make some adjustments before starting the migration.
In the cloud, the available options for Treatment are these:
The migration process assigns Treatments to issues in the cloud according to the indexes of the values transferred from the server. So a Treatment value from the server that is the second available option in the server will be assigned the second available option in the cloud, ‘Avoid’, no matter what the text value of that option may be in the server.
WARNING: If you have more than four options for Treatment in the server data may be lost in the migration. Any issues assigned the fifth and higher values in the server will be left unassigned with respect to migrated issues in the cloud.
We recommend that you make the Treatment options in the server exactly the same as those in the cloud before beginning the data migration. In so doing, you may need to reassign some Treatment values in the server to make them fit into the four categories used by the cloud.
In the cloud, the available options for Realization are these:
The Risk Register app migrates Realization values in the same way as Treatment fields, so the same cautions apply.