Page Comparison

...

Configuration Manager Cloud Migration Tool automates and streamlines the migration process, ensuring a smooth transition while preserving important configurations and data.

Migrate Jira Service Management projects

Currently, the Cloud Migration Tool handles the migration of request types and organizations when it migrates service management projects (service projects). It's important to note that this marks the initial stage in the full migration of Jira Service Management projects. Over time, we plan to add support for migrating the remaining Service Management configuration elements.

How service management projects are migrated

Cloud Migration Tool is able tocan:

• add a source service project as a new one to the destination site, and

• migrate a source service project’s configuration and issues to an existing destination service project without issues.

The Analyze Changes document explains how Cloud Migration Tool migrates and reports projects. The information there applies to Jira Software and Service Management projects.

Create destination SLAs when migrating service requests

If the service management projects you’re migrating contain requests with SLAs, you’ll have to create the same SLAs on the destination if not present already. In this case, the source and destination SLAs must have the same names and configuration. Otherwise, the requests won’t be migrated correctly.

SLA-type custom fields

Cloud Migration Tool can’t migrate SLA-type custom fields due to restrictions with the creation of locked fields imposed by Atlassian’s APIs. Because of that, during the migration, you’ll get the following error message informing you there’s a problem with migrating a specific SLA-type custom field:

The screenshot below shows the error for SLA-type custom fields in the Analyze changes phase of migrations.

...

Create SLA-type custom fields in the destination

SLA-type custom fields are created by Jira Service Management automatically when you add an SLA to a service project. Alternatively, you can manually create them by adding an SLA in Project settings > SLAs. However, you cannot directly create these custom fields from the Custom Fields list in Jira. Learn more about creating custom fields.

Each service project comes with a set of default SLAs and their corresponding SLA-type custom fields already created.

When migrating service projects referring to SLA-type custom fields, you need to have the same custom fields in the destination as well. If the destination Jira Cloud site doesn’t contain these custom fields, you’ll see the error “Managed custom field isn’t found on the destination“. Then, you must create these SLA-type custom fields on the destination with the source field names to accomplish the migration.

To resolve the error, create the missing SLA-type custom fields by:

• creating a sample service project or

• creating SLAs in your destination project matching the missing SLA-type custom fields

In the first case, Jira Service Management will automatically create the following SLA-type custom fields: Time to close after resolution, Time to resolution, Time to first response,and Time to review normal change. If the migration is giving you errors about any of these fields, then you can use the sample service project creation option to work around the problem.

However, if the migration is looking for other SLA-type custom fields, you must create your SLAs with the names of the source SLA-type fields in the destination. This will automatically create the corresponding SLA-type custom fields.

To create new SLAs in an existing service project on the destination, go to Project settings > SLAs and type a new SLA name, as shown in the screenshot below. Afterward, your Jira Cloud site will have a custom field with that name.

...

Case-sensitivity by SLA-type field names

You can also hit the error “Managed custom field isn’t found on the destination“ if the The source and destination SLA fields have may use different capitalizations for the letters in the nameletter capitalizations, which can affect mapping. For exampleinstance, if you have a source SLA field called "Time to resolution and " won't match a destination field called SLA labeled "TIME TO RESOLUTION, they won’t be mapped." In this case, you either have to use the Customize mapping feature to map both fields to each other or to such cases, the Cloud Migration Tool will not map these SLAs. Instead, it will create a new destination SLA with that exactly matches the exact name and capitalization matching of the source field.

Supported Service Management configuration