Jira Service Management — Migration Reference

Jira Service Management — Migration Support Overview

Role in migrations

• Staff (HD): supported as both (source and target).
• Company (HD): supported as both (source and target).
• Contact (HD): supported as both (source and target).
• Ticket (HD): supported as both (source and target).
• Category (KB): supported as both (source and target).
• Folder (KB): supported as both (source and target).
• Article (KB): supported as both (source and target).

Field-level support migrating FROM Jira Service Management (Ticket)

Field-level support migrating TO Jira Service Management (Ticket)

Field-level support migrating FROM Jira Service Management (Company)

Field-level support migrating TO Jira Service Management (Company)

Field-level support migrating FROM Jira Service Management (Contact)

Field-level support migrating TO Jira Service Management (Contact)

Field-level support migrating FROM Jira Service Management (Article)

Field-level support migrating TO Jira Service Management (Article)

Migration options available for Jira Service Management

• Update cross-links between articles - applies to: both (Article)
• Migrate linked issues - applies to: source (Ticket)
• Migrate the newest records first - applies to: source (Ticket)
• Select records for Demo - applies to: source (Ticket), source (Article)
• Migrate records associated with tickets - applies to: source (Company), source (Contact)
• Migrate time entries - applies to: both (Ticket)
• Inline images in tickets - applies to: source (Ticket)
• Skip ticket attachments - applies to: source (Ticket)
• Add a new tag to tickets - applies to: target (Ticket)

Jira Service Management — Setup & How-To Guide

For more information: https://help-desk-migration.com/help/jira-service-management-migration-guides/ , https://help-desk-migration.com/help/jira-service-management-data-migration-checklist/

How to Migrate Classic to Next-Gen project in Jira Service Management?

Jira Service Management introduced Next-Gen projects, but they don't support the direct import of JSON or CSV files. At the moment, Help Desk Migration can only migrate records to Classic projects.

However, if you still wish to migrate to a Next-Gen project using Help Desk Migration, you can follow this workaround: First, import your data to a Classic project, then migrate data between Classic and Next-Gen projects using a free solution from Jira Service Management.

To enable this process, ensure you have the "Make bulk changes" global permission granted by a Jira admin. Here's how:

1. Click "Settings" and navigate to "Global Permissions" under the "System" section.
2. Scroll to the bottom of the page, choose "Make bulk changes" permission, and grant it to the necessary user group. Click "Add."

Now, with the required permissions, you can proceed to move migrated issues to the necessary Next-Gen project:

1. Click the Filters and select All issues.
2. Click the Project filter button and choose the project you want to migrate from.
3. Then, in the top-right corner, select more (three-dot sign) and Bulk change all. The system will open the Bulk Operation wizard.
4. Go through the wizard, choose the issues that you want to move and click Next.
5. Click Move Issues and then Next again.
6. The “Select Projects and Issue Types” screen will appear. Here, you have to choose the destination project to move the records there. You’ll also have to pick the type of each issue in the destination project. Click Next when you’re ready.
7. The next step is “Map status for Target Project,” where you need to choose the destination status for each issue from the old project.
8. The last step is reviewing the summary of all the issues prepared for migrating to the next-gen project. When you’re done reviewing, click Confirm.

What to remember when migrating from Classic to Next-Gen projects:

There are a few things to consider when you migrate from Classic to Next-Gen project. They are technically quite different, so keep in mind these peculiarities:

• Active sprints (sprints in progress) won’t migrate to the next-gen projects. However, the issues in the active sprints will move to the backlog of the destination project.
• Epic links between the issues won’t exist in the next-gen project.
• Custom fields must be recreated manually after the migration in your next-gen project.
• Story points estimation will be lost. However, you can still use them in the next-gen project by enabling the Estimation feature.
• The data for your Velocity report won’t be saved, so the report will show that no points were completed before.
• Reporting history will also be lost in the migration process.
• Project and issue keys will change as you move to the new project because they cannot be reused. The links from your old keys will also be redirected when you migrate using the Jira migration wizard.

How to Create a Classic Project/Company-managed Project

1. In the heading, click on Projects > Create Projects.
2. In the left sidebar, choose Software Development.
3. Then pick up Kanban or Scrum or Bug tracking template.
4. Click on Use Template.
5. Then select a Company-managed project.
6. Fill in the name of the project and click on Create project.

How to import Contacts to Jira Service Management?

To migrate contacts to Jira Service Management, you must have the Public Signup setting enabled. If you're using Service Management for customer support, you might already have this setting enabled. However, if you're using Jira Service Management for internal support, follow the instructions below to double-check/enable this setting.

To enable Public Signup, follow this path:

1. Log in as a user with the Jira Administrator global permission.
2. At the upper right corner, choose Jira settings; Products; Configuration.
3. Find the Customer Permissions section and enable the setting.

You or a service desk project administrator can then open a service desk at the project level:

1. Go to Projects and click on the project to which you want to migrate the data.
2. On the left sidebar, choose Project settings > Customer permissions.
3. Select Anyone on the web and click Save.

How to generate the API token for cloud-hosted Jira Service Management?

You will need an API token to migrate from or to a cloud-hosted version of Jira Service Management. Use your Admin password if you’re migrating from a self-hosted Jira Service Management.

Creating an API token

1. Go to > https://id.atlassian.com/manage-profile/security/api-tokens > and click Create API token.
2. Give your token a clear and memorable name and click "Create".
3. Copy the token to the clipboard and put it in someplace safe. You > won’t be able to view or copy this token again. So make sure you > have it saved.

Revoking your API key

Once the migration ends, you can revoke access by clicking the "Revoke" button next to the corresponding API key.

Important: Do not revoke the API token when the migration is in progress. Doing so will stop the data import and export. You'll have to re-authorize and restart the migration from the very beginning.

How to obtain Atlassian Cloud Password?

Two types of passwords can be used to access Atlassian products: Google password and Atlassian Cloud password.

Using your email to create an account, you also create a password that allows signing in to Atlassian, i.e., the Atlassian Cloud password. You can use this password when setting up a migration from/to Jira Service Management.

However, if you sign in to Jira Service Management with your Google account, Atlassian uses the email and password to authenticate your Google account. You don't need to create a separate password to access Jira Service Management. In this case, you cannot set up a migration unless you obtain the Atlassian Cloud Password or use an API token instead.

To obtain your Atlassian Cloud password, follow these steps:

1. Log out of Jira Service Management. Go to the sign-in page and click "Can't log in."
2. Enter the email to your Jira Service Management to request a recovery email.
3. Once you receive the email, click on Reset Password.
4. Create your password.

How to calculate customers in Jira Service Management?

Jira stores your customers in separate projects so that you can count their number within a project.

1. Select your Jira Service Management project from the Projects dropdown menu.
2. Go to Customers from the sidebar menu.
3. Scroll down to the bottom right corner to find the total number of customers.
4. If you have organizations set up, select one from the list to view the number of customers within that organization.
5. In the bottom right corner, you'll see the number of customers associated with the selected organization.

How to calculate tickets in Jira Service Management?

To calculate the number of tickets in Jira Service Management, follow these steps:

1. Click on the search bar at the top right and choose Issues next to the Go to All option.
2. Use the left side filters to narrow your search and find specific tickets.
3. After applying the desired filters, view the number of filtered tickets displayed at the top right corner.
4. You can refine your search by adding project, type, status, or assignee criteria. Click "+More" and select the additional criteria you wish to apply.

How to calculate articles in Jira Service Management?

To calculate the number of articles in Jira Service Management (in Confluence), follow these steps:

1. Use the "Switch to" menu in the top left corner and select "Confluence."
2. Click the search bar at the top right and choose the Advanced search option.
3. Use filters such as space, type, and other criteria to narrow down your search for articles.
4. Once you've applied the desired filters, observe the number of filtered articles displayed beneath the search bar.

How to add users to a project in Jira Service Management?

1. Go to Settings > User management.
2. In the upper right corner, click Invite users.
3. In the pop-up window, provide up to 10 email addresses of the users you want to migrate. Set their roles and permissions, add them to groups, and customize invitations if needed. Then, click Invite * users.

Each user must accept the invitation sent to their email to activate their profile in Jira. The invitation will expire seven days after it is sent.

How to invite service desk users to projects in Jira

Now that you’ve created all the necessary user profiles, you can invite them to the corresponding Projects. To do this, follow these steps:

1. Go to Settings > Projects to see your existing Jira Projects list.
2. Click on the necessary Project and go to Project settings: People.
3. Click Add people and input the info of the necessary users to invite to them this project. For all Classic Jira Service Management projects, you must choose the Service Desk Team role to enable the users to manage this project.

How to make the email visible

1. Go to https://id.atlassian.com/manage-profile/profile-and-visibility.
2. Scroll to the bottom of the page and locate the Contact section. Select Anyone to make your email publicly visible.

Atlassian will automatically save the changes.

How to remove users from Projects

If you've added the wrong user to a Project, you can remove them by following these steps:

1. Go to the necessary Project and choose Project settings in the left sidebar.
2. Go to the People section. Find the user you want to remove from this Project and click Remove next to their name.

How to deactivate users in Jira Service Management

To deactivate users in Jira Service Management, follow these steps:

1. Go to Settings > User Management. Click on the user account you want to deactivate.
2. Switch the Has access on site toggle to deactivate the user. You will receive a notification confirming that the account has been deactivated in the lower-left corner.

By deactivating a user, their account becomes unusable until it's activated again. This action also frees up their license spot, making it available for another user.

How to bulk update request types in Jira Service Management?

Jira Service Management has Request types and Issue types. Issue type is what your team picks up to work on issues internally. When migrating to Jira Service Management, you can choose a default issue type that will be applied to all issues. And during the mapping step, you can set the Request Type for the Issues type you have chosen.

To bulk update request types in Jira Service Management, follow these steps:

1. Go to Jira Service Management and use the required filters to produce a list of issues. You can filter based on various criteria to narrow down the issue list you want to update.
2. Click the "More options" button, then select "Bulk change all issue(s)." Note that Jira Service Management allows updating up to 1000 issues per one bulk operation.
3. Choose the issues you want to perform the bulk operation on. If there are many issues, scroll to the bottom of the page and click "Next." Select the "Edit issues" operation and click "Next".
4. Find the "Change Request type" option and select the necessary type from the dropdown menu.
5. Select a value for any required fields for this operation. You can also decide whether to send email notifications about this change.

Review your bulk operation and confirm when you are satisfied with the changes.

How to search migrated objects in Jira Service Management?

To search for migrated objects in Jira Service Management, follow these steps:

Step 1. Open Jira Service Management, then the project to which you migrated data.

Step 2. Click on "Filters" and then select "Advanced issue search".

Step 3. Remove any existing commands in the search bar and replace them with the following JQL query: "ImportedId[Number]" = "ticket id." Replace "ticket id" with the ID number of the imported ticket and hit "Search."

Step 4. To search for multiple tickets at once, use the following command: "ImportedId[Number]" in ("ticket id," "ticket id").

How to search customers/organizations in Jira Service Management

Step 1. Log into your Jira Service Management account and open the project where you migrated data.

Step 2. In the left sidebar, navigate to "CHANNELS & PEOPLE > Customers."

Step 3. Use the search bar to find the customer's name or email or the organization's name.

What is “HTTP Error 410: Gone” in Jira Service Management?

HTTP Error 410: Gone in Jira Service Management occurs during data transfer when the Migration Wizard attempts to create tickets in the target platform. This error typically arises due to certain technical configurations within the Data Center application.

Causes of HTTP Error 410: Gone:

• Node Switching: Data Center applications expect API requests to be directed to the same node during data movement. If requests are routed to different nodes, HTTP Error 410: Gone may occur.
• Lack of Sticky Sessions: Sticky sessions, which link a session to the same node, are not employed, and the Data Center application has multiple API nodes. This can result in subsequent API calls being sent to the wrong node.

To address the HTTP Error 410: Gone, the load balancer in the Data Center application must be configured appropriately. Follow these steps:

• Remove Unnecessary Nodes: Remove all dedicated API nodes from the cluster except one, ensuring all API calls are directed to the same node.
• Temporarily Shut Down Nodes: Temporarily shut down API nodes to render them inaccessible.

Following these steps, the load balancer will cease sending new connections to the removed nodes while allowing existing connections to complete. For detailed instructions, refer to the Jira documentation.

Migrating Articles to/from Jira (Confluence)

Jira's Knowledge Base is called Jira Confluence and is technically a separate product — it can be migrated to as long as there's at least one Service Management project (even an empty one) to connect through.

Migrating from Jira

All spaces are read and treated as categories. Each space (category) gets a single folder named "All Pages ([Space Name])," into which all articles (pages) within that space are read.

Migrating to Jira

• Categories are created as Spaces.
• Folders are added as a tag on the article.
• Articles are created as Pages.

By default, a separate space is created for each category, but migrating into a single space is possible as a custom migration.

When an article is created on Jira, a Page is created first (with the title), and the body is added afterward. If the article fails partway through creation, a page with just the title (no body) may end up being created on Jira.

The original article author doesn't migrate — the author is set to whoever set up the migration. Migrating the original author into the body is possible as a custom migration.

Also available as custom migrations:

• Folder as a parent Page, with articles as child Pages.
• A full three-level structure (Category, Folder, Article) as Pages with corresponding parent-child relationships.

If the target already has an article with the same title, (2) is appended to the end of the title during migration. This happens even for a custom migration into a separate space, if an article with the same title exists anywhere across other spaces. Restricting the duplicate-title search to only the space being migrated into is possible as a custom migration, to avoid this issue.

How to view articles and attachments in Jira Service Management after the data migration?

Go to Confluence to view and inspect your migrated knowledge base articles. You can explore attachments associated with each article by following these steps:

1. Open any article within Confluence.
2. Click the 'Three dots' icon in the upper right corner and choose the 'Attachments' feature from the drop-down list.
3. Carefully examine each attachment, paying attention to creators, creation dates, and comments to ensure a seamless migration.

Jira Service Management Migration Limitations

1. There are two types of projects in Jira – Classic and Next-gen. Our tool only migrates to Classic projects. 
2. By default, you can only set one issue type per migration applied to all issues. If you want to transfer multiple issue types, dive your data migration into parts. Then migrate tickets of every ticket type separately.
   When JSM is the source, tickets migrate from all issue types within the project. When JSM is the target, tickets migrate into a single issue type within the project, since each issue type can have a different set of fields and migrating into multiple types would cause failures.
3. You can move organizations to Jira Service Management by default, but they won't link to tickets.
4. Jira’s API doesn't support the import of custom fields for organizational entities directly. However, there's a workaround. However, you can migrate organizations in a separate data migration via CSV file. Jira will then automatically update the custom field data for the existing companies. For the companies not currently in the system, Jira will populate the custom fields with the data from your imported CSV file.
5. Do not deactivate end-users because our tool won't migrate their cases.
6. If a contact has a private email in Jira SM, our tool automatically creates a new contact; Migration Wizard adds +1 to the original email address.
7. If a contact is deleted in Jira Service Management, the Migration Wizards creates a new contact by adding +1 to the original email. Notice that Jira Service Management reserves the original email for 30 days after deletion. During this period, our tool cannot set up a contact with the same email address
8. Migration is performed from and to a single Jira project per migration.
9. Only one migration per Jira account can run at a time — running two migrations simultaneously (even into different projects) will cause a conflict and fail.
10. Request Type migrates by default — without it, tickets won't be visible to end customers.
11. Contacts can be returned via the API as deleted if they don't have portal (site) access.
12. The Resolution field must be mapped, or all tickets will migrate as Unresolved. Note: the Resolved Date field will be populated with the source's update date, not the actual ticket closing date.
13. App integrations (e.g., Jira Software, Shopify, etc.) should be disabled before migrating to Jira.
14. Agents may appear on the mapping with a example.com address instead of their real company domain. This happens because their email is hidden and not returned via the API ("emailAddress": ""), so the agent's name plus @example.com is shown instead. Agents are matched by ID, so this display quirk doesn't affect the migration itself