Page Comparison

Streamlining your workflow: Migrating Jira Service Management projects from Server/Data Center to Cloud

In today's dynamic business landscape, organizations are continually seeking seek ways to enhance their project management processes. As part of this evolution, many are opting to migrate their Jira Service Management projects from Server or Data Center Centers to the Cloud. This transition brings numerous benefits, including improved scalability, enhanced collaboration, and seamless access to the latest features and updates.

...

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 in it.

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 exact same SLAs on the destination if not present already. In this case, the source and destination SLAs must have the same names and same 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 fields 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 you’re 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 need to create these SLA-type custom fields on the destination with the source field names to be able 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

...

However, if the migration is looking for other SLA-type custom fields, you’ll need to create your own SLAs with the source SLA-type fields' names 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, you need to go to the 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 different capitalization of the letters in the name. For example, if you have may use different letter capitalizations, which can affect mapping. For instance, 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 to each other. In this case, you either have to use the Customize mapping feature to map both fields to each other or to ." In 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

...