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 about the Risk Register app specifically 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 a free 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 describes how you can use the JCMA to migrate your Risk Register data to the cloud. It does not provide a user guide for JCMA itself; for that, refer to the JCMA documentation.

Compatibility

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 server-side apps required for automated migration are:

  • JCMA version 1.6.5

  • Risk Register version 6.2.5

Overview

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 models, risk registers, risk assessments, and values assigned to the Treatment and Realization custom fields. You'll need to prepare your Jira Cloud instance to receive the risk data before beginning the migration process. The rest of this document describes how to do that.

Updates to Jira issues in the cloud

Risk Register transfers data from the server and updates issues in the cloud with those data. In so doing, it does not preserve corresponding data that may already be present on those cloud issues; it overwrites them. 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 data is not normally a concern. In fact, this would only ever be an issue if you migrated a project from the server to the cloud, updated some risk data in the cloud, and then migrated the project from the server to the cloud again.

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.

Migration is project-based

The JCMA lets you nominate which projects are migrated across to the cloud. It’s important to understand that only Risk Register data pertaining to projects included in your migration will be transferred to the Cloud. If you add Project A to your migration, then only Project A’s risk data will be transferred. If you don’t include any projects in your migration, then no Risk Register data will be transferred. This enables larger installations to migrate their data incrementally.

Risk model migration

Both the server edition and Cloud editions of Risk Register support the use of multiple risk models. Risk models are automatically migrated by the JCMA when you have Risk Register installed.

Risk model inclusion in migrations

A risk model in the server will be migrated to the Cloud automatically if that risk model is explicitly associated with a project that is included in the migration, or if it is the default risk model and one of the projects in the migration is implicitly associated with the default risk model by virtue of not being explicitly associated with a risk model.

The naming of migrated risk models

Migrated risk models are given unique names on the Cloud side, according to the following rules:

  1. The string “ (migrated)” is appended to the name of the server-side risk model; for example: “Standard Risk Model” becomes “Standard Risk Model (migrated)”.

  2. If the risk model name from 1. is already assigned to an existing risk model in the Cloud, then a second candidate name is constructed by appending “ (migrated 2)” to the name of the server-side risk model.

  3. If the risk model name from 2. is already assigned to an existing risk model in the Cloud, then more candidate names are generated by incrementing the numeral until an unused name is found. In other words, candidates are generated by appending “ (migrated 3)”, and then “ (migrated 4)”, and so on.

The assignment of migrated risk models to projects

Since there can be only one default risk model in the Jira Cloud instance - it is created automatically when you install Risk Register on the cloud - any server-side default risk model included in the migration will become a non-default risk model on the Cloud side. It won’t be assigned to any projects.

Any non-default risk model on the server-side will be created as a non-default risk model on the Cloud side and will be assigned to projects as follows:

  • It will only be assigned to projects that were migrated from the same server in this migration or in any migrations completed within the last 2 years.

  • It will not be assigned to projects that are already assigned to other risk models in the Cloud instance. Only one risk model can be assigned explicitly to a project.

    Example: Suppose My Risk Model is assigned to Project A on the server, and My Other Risk Model on the cloud side is already assigned to Project A, then My Risk Model will be migrated to the cloud but will not be assigned to Project A.

Any risk-model-to-project assignment that cannot be migrated according to the above rules will be ignored; that is, the migrated risk model won’t be assigned to the project. Such a case won’t be reported as an error and won’t cause the migration to fail. We recommend you double-check the assignment of risk models to projects after the migration, just to be on the safe side.

Risk model collisions

A collision occurs when a risk model that was migrated by a previous migration is included in a subsequent migration attempt. In such cases, the following rules are applied:

  • If the previously-migrated risk model has not been changed on the Cloud side since it was migrated (it remains at version 1), then the risk model is not re-migrated on the subsequent attempt. Migrated risk assessments will reference the previously-migrated risk model.

  • If the previously-migrated risk model has been changed on the Cloud side since it was migrated, then a new risk model will be created on the Cloud side upon the subsequent attempt. Migrated risk assessments will reference that newly-migrated risk model. The name of the new risk model will be constructed as explained under The naming of migrated risk models (above).

The migration of risk assessments

Risk assessments are simply the combined impact, probability, and risk level values assigned to risk issues. Risk assessments are automatically migrated if they are attached to issues in projects that are included in a migration.

The migration of risk assessments proceeds in two phases:

  • Risk assessments are attached to migrated issues and are linked to their migrated risk models.

  • Migrated risk assessments undergo harmonization.

If a server-side risk model could not be migrated for some reason, then any risk assessments based on that risk model won’t be migrated. Errors will be reported in the error log for those cases, and the migration will be marked as having failed.

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:

  • Accept

  • Avoid

  • Mitigate

  • Transfer

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:

  • Not realized

  • Realized

The Risk Register app migrates Realization values in the same way as Treatment fields, so the same cautions apply.