Skip to end of banner
Go to start of banner

Migrate Service Management projects to the Cloud

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

On this page:

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

In today's dynamic business landscape, organizations continually 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 Centers to the Cloud. This transition brings numerous benefits, including improved scalability, enhanced collaboration, and seamless access to the latest features and updates.

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 to:

  • 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.

Problem

You can only migrate project configuration and data to an existing destination project if it has no issues. If the destination project contains issues, Cloud Migration Tool will report an error in the Analyze changes page. Also, because of this error, you won't be able to continue the migration.

Solution

The solution is to transform the source project in the migration to either create it as new or map it to a project without issues in the destination. To achieve that, change the project name and key or use the Customize mapping option to create the project as new or to map it to a project without issues in the destination.

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:

Managed custom field isn’t found on the destination. See our KB article for more information.

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.

CMT-create-custom-SLA.png

Case-sensitivity by SLA-type field names

You can also hit the error “Managed custom field isn’t found on the destination“ if the source and destination SLA fields have different capitalizations for the letters in the name. For example, if you have a source SLA field called Time to resolution and a destination field called 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 create a new destination SLA with the exact name and capitalization matching the source field.

Supported Service Management configuration

Jira Service Management configuration

Migration with Cloud Migration Tool

Service Management project basics

AVAILABLE

Organizations

PARTIALLY

Organization membership isn’t migrated. If a source organization has 2 users, the same organization migrated to the destination will have 0 users.

Request types

AVAILABLE

Portal groups

PARTIALLY

Currently, we support creating request-type groups but not updating them.

Portal settings

FUTURE

SLAs

FUTURE

Queues

PARTIALLY

Currently, we support creating queues but not updating or deleting them.

Calendars

AVAILABLE

Email requests

FUTURE

Forms

FUTURE

Satisfaction settings

FUTURE

Access settings

FUTURE

Customer permissions

FUTURE

Customer notifications

FUTURE

Attachment security

FUTURE

Sender names

FUTURE

Templates (Premium Jira Cloud Only)

FUTURE

Language settings

FUTURE

Knowledge base

FUTURE

Knowledge base labels

FUTURE

Knowledge base enabled request types

FUTURE

Reports

FUTURE

Widgets

FUTURE

Automation rules

FUTURE

  • No labels