On this page:
|
Streamlining your workflow: Migrating Jira Service Management projects from Server/Data Center to Cloud
In today's dynamic business landscape, organizations are continually seek seeking 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 Center 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.
...
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.
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.
...
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 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 must need to create these SLA-type custom fields on the destination with the source field names to be able to accomplish the migration.
...
However, if the migration is looking for other SLA-type custom fields, you must you’ll need to create your own SLAs with the names of 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.
...
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 capitalization of 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 to each other. 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.
...
Jira Service Management configuration | Migration with Cloud Migration Tool | ||||||||
|---|---|---|---|---|---|---|---|---|---|
Service Management project basics |
| ||||||||
Organizations |
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 |
| ||||||||
Portal groups |
CurrentlyFor now, we support creating the creation of request-type groups but not updating themthe update. | ||||||||
Portal settings |
| ||||||||
SLAs |
Not available due to restrictions by Atlassian’s APIs. | ||||||||
Queues |
| ||||||||
Calendars |
| ||||||||
Email requests |
| ||||||||
Forms |
| ||||||||
Satisfaction settings |
| ||||||||
Access settings |
| ||||||||
Customer permissions |
| ||||||||
Customer notifications |
| ||||||||
Attachment security |
| ||||||||
Sender names |
| ||||||||
Templates (Premium Jira Cloud Only) |
| ||||||||
Language settings |
| ||||||||
Knowledge base |
| ||||||||
Knowledge base labels |
| ||||||||
Knowledge base enabled request types |
| ||||||||
Reports |
| ||||||||
Widgets |
| ||||||||
Automation rules |
|
...