How can I migrate a Jira issue to a Jira Service management issue?

[Cristina Vasla]

Hello team,

How can I migrate a Jira issue to a Jira Service Management issue? E.g. export csv and import csv, "conversion" tool (like "Move" etc.). I understand that some fields will be lost and not everything can be mapped.

Thank you in advance for your support

[Trudy Claspill]

Hello @Cristina Vasla 

Welcome to the Atlassian community.

I have a few clarifying questions?

1. Why do you want to migrate the issue? What problem are you trying to solve? This will help me provide a solution that will solve the underlying problem.

2. In your mind what does "migrate" mean? A Jira Project/Space can be either Software, Business or Service. To have the issue data for an issue in a Software (or Business) project appear in an issue within a Service project means the data exists in that Service project. Do you want the original issue to stop existing in the source/Software project?

3. Are you trying to change to Type of the issue; i.e. from being a Story to be a different Type that is optionally associated with a Request Type?

4. Does the issue in the Service project need to be visible through the Customer Portal?

5. Is the source project Team-managed or Company-managed? Same question for the destination Service project. You can get that information by clicking the ellipsis button next to the Project name in the navigation panel on the left. The bottom two lines in the pop-up will say something like:
Software space
Company-manated

6. What issue do you need to retain when the issue is in the Service project? Do you need the issue history? Do you need the comments? Do you need Work Logs?

7. Do you need to do this once, for multiple issues at once, or repeatedly? Does this need to occur on an automated basis based on some conditions?

If you want the issue to stop existing in the Source project you can use the native Move Issue function, or use the CSV export/manipulate the date/CSV import option and delete the source issue at the end, or use the Clone Issue function. This all depends on your level of access (end user or admin) and permissions in the source and destination projects.

If you want the issue to continue existing in the source project than the available options are manually recreating the issue in the destination project, using the CSV export/import methods, or using the Clone Issue option.

Each method has various limitations as to what data can be included. When you provide answers  to the questions I asked I will be able to provide more targeted advice about the best solution.

[Cristina Vasla]

Hello @Trudy Claspill ,

Thanks for the reply. 

1. Why do you want to migrate the issue? What problem are you trying to solve? This will help me provide a solution that will solve the underlying problem.

-> We are at the end of an implementation, where we used a company-managed JIRA project. Inside this project, when we started the hypercare, we used a dedicated custom issue type "Incident" so that the post-project team ramped up in parallele. We used the same JIRA project for the project team and post-project support team, just for transparency purposes. No we want to cut-off and only use JSM for the operational support. We have approx. 100 "Incidents" that we need now to move to JSM and officially close the JIRA project.

2. In your mind what does "migrate" mean? A Jira Project/Space can be either Software, Business or Service. To have the issue data for an issue in a Software (or Business) project appear in an issue within a Service project means the data exists in that Service project. Do you want the original issue to stop existing in the source/Software project?

->"migrate" means using a mapping tool, similar to "move functionality" or import/export csv to convert the JIRA "Incident" to a JSM ticket, even is some fields will be lost. We want to map the Reporter, the description, the attachments and existing comments and also labels. We have also custom fields like "external ticketing system". It does not matter is the "incident" will stop existing in the JIRA project and only exist in JSM.

3. Are you trying to change to Type of the issue; i.e. from being a Story to be a different Type that is optionally associated with a Request Type?

-> the issue types will be for sure different JSM vs JIRA

4. Does the issue in the Service project need to be visible through the Customer Portal?

->Not sure what you mean by customer portal. The tickets need to be visible to the users which originally created the JIRA issue. Yes, they need to be visible in the JSM UI is the list of each user, like they created it.

5. Is the source project Team-managed or Company-managed? Same question for the destination Service project. You can get that information by clicking the ellipsis button next to the Project name in the navigation panel on the left. The bottom two lines in the pop-up will say something like:

-> already answered at point 1 for JIRA Company managed, for JSM Company managed. Both Cloud
Software space
Company-manated

6. What issue do you need to retain when the issue is in the Service project? Do you need the issue history? Do you need the comments? Do you need Work Logs?

-> comments are NICE TO HAVE. Description and attachments mandatory, no work logs, no history needed, NICE TO HAVE the creation date to be in the past, like in the original ticket.

7. Do you need to do this once, for multiple issues at once, or repeatedly? Does this need to occur on an automated basis based on some conditions?

-> one time task for the tickets open approx. 100. No automation needed.

[Cristina Vasla]

Hello @Trudy Claspill ,

Ref to 

"If you want the issue to stop existing in the Source project you can use the native Move Issue function, or use the CSV export/manipulate the date/CSV import option and delete the source issue at the end, or use the Clone Issue function. This all depends on your level of access (end user or admin) and permissions in the source and destination projects.

If you want the issue to continue existing in the source project than the available options are manually recreating the issue in the destination project, using the CSV export/import methods, or using the Clone Issue option."

-> Could you please give me more datails about the permissions needed in both tools JIRA and JSM so that the projects are recognizable in the Move function? Currently in JIRA no JSM project is visible when we are in the "Move" functionally screens.

Thank you

[Trudy Claspill]

Hello @Cristina Vasla 

It looks like you got some answers from @Arkadiusz Wroblewski . I will reiterate and add to it.

For the person executing the Move:

In the source Software project you must have the Move Issue permission.

In the destination Service project you must have the Create Issue permission.

In both projects you must have the Browse Projects permission.

If you want to move multiple issues at once you must have the Global Permission for Make Bulk Changes.

Additionally since you are trying to move to a Service project it is advisable for you to have the JSM Application Role of "User (agent)".

With regard to mapping fields, during a Move process you do not have the option to dynamically map fields. Jira will try retain the data in the same fields. The fields you want to retain must be included in the issue type in the JSM project to which you want to move your Software issue. If you used custom fields in your Software issue and you want to keep that data, the same custom fields will need to be added to your Service issue type.

You will be prompted to map Status values. You will be shown the Status values used in the workflow(s) for the issues in the Software project and given the option to select the appropriate value to use as a replacement in the Service project for the issue type to which you are moving. It will present similar to this:

-> comments are NICE TO HAVE. Description and attachments mandatory, no work logs, no history needed, NICE TO HAVE the creation date to be in the past, like in the original ticket.

The Move process will automatically include comments. Attachments will move with the issue automatically. Description will move if the Description field is included in the destination project's issue type. History will move automatically. Timestamps for Created and Resolved will not be changed by the move.

You said you weren't sure what I meant by the customer portal. One of the features of a Service project is that you can identify people who are Customers and allow them to submit and interact with Requests/Issues through a UI specifically for customers. This UI offers them limited access to the data in the Request/issue. You can designate users as only Customers (not users of the Jira product with access to Software projects, and not users of the JSM UI like Agents with access to all the data in the Request/issue). A user that is only a Customer does not consume a billable license for Jira/JSM. If you are not familiar with the Customer Portal feature you may want to read up on it.

What is a portal? 

And here is the AI summary from Gemini:

The Customer Portal in Jira Service Management (JSM) Cloud is a simplified, user-facing help center where your clients, employees, or end-users can submit requests, track ticket progress, and find answers using self-service knowledge base articles. [1, 2, 3, 4, 5]

It acts as a buffer between your internal team and external users. Key features include:

• Request Submission: Customers select a specific request type (e.g., "Report an IT Issue" or "Request Software") and fill out intuitive, simplified forms tailored to their needs.
• Request Tracking: Users can view the status of their active tickets, add comments, and communicate directly with service agents.
• Self-Service Knowledge Base: It connects to Confluence to surface helpful articles, allowing users to troubleshoot problems before submitting a ticket.
• "Portal-Only" Customers: Users who submit tickets do not require a full Jira/Atlassian license; they interact via cost-free customer accounts. [15, 16]

To see how you can set up or adjust your instance, check out the official About the Portal and Help Center guide.

AI responses may include mistakes.

[1] https://support.atlassian.com/jira-service-management-cloud/docs/about-the-portal-and-help-center/

[2] https://confluence.atlassian.com/spaces/SERVICEDESKSERVER/pages/939926277/Configuring+the+customer+portal

[3] https://support.atlassian.com/jira-service-management-cloud/docs/brand-your-portal/

[4] https://confluence.atlassian.com/servicemanagementserver/using-the-help-center-939926561.html

[5] https://community.atlassian.com/forums/Jira-Service-Management/Jira-Service-Management-Customer-Dashboard/qaq-p/2663943

[15] https://www.reddit.com/r/jira/comments/1roq46p/jsm_customer_portal_access_and_branding/

[16] https://community.atlassian.com/forums/Jira-questions/JSM-Public-board/qaq-p/1544648

If the users that are the Reporters of the issues already have Jira Software access, if you give them Browse Projects permission in the Service they will minimally be able to see the issues within the native Jira/JSM UI. If they need to interact with the issue more, then their level of interaction needs to be determined to decide what type of role they need (collaborator, agent, or customer), and what additional permissions or setup will be required for them to interact with the issues.

[Cristina Vasla]

Thank you @Trudy Claspill . We made it.

[Arkadiusz Wroblewski]

Hello and Welcome to the Community @Cristina Vasla 

Using the native Move function is much better than CSV export/import because it preserves the issue history. Go to More actions (...) > Move on the issue, select your JSM project, and follow the wizard to map your fields and statuses.

If you have many issues, you can use bulk move, but test with one first. Most importantly, remember to set the Customer Request Type after the move; if it's left empty, the ticket won't be visible to customers on the portal. Just ensure you have the required move and create permissions in both projects before starting.

Best,

Arkadiusz🤠

[Cristina Vasla]

Hello @Arkadiusz Wroblewski , Thank you for the reply. Move function does not work between the 2 different products: JIRA vs JIRA Service Management with the current permissions. Could you please give me more tips about the permissions needed?

[Arkadiusz Wroblewski]

@Cristina Vasla 

Move work items and Create work items project permissions and for Bulk move, Bulk Actions Permission.

I do not want to sound ignorant, but for things like moving tickets from one project to another, it is usually best to work together with your Jira admin.

This almost always involves project configuration, permissions, workflows, issue types, fields, and sometimes automation rules. You really want an admin to have a look at it.

[Cristina Vasla]

Hi @Arkadiusz Wroblewski , Thank you for the reply. I am working with the Admin. It's just we do not see the JSM projects in JIRA, I am talking about these specific permissions. I have the general rights to make bulk actions but between JIRA projects and not JIRA -> JSM. Is this possible in your knowledge? Thank you

[Arkadiusz Wroblewski]

@Cristina Vasla 

Then it is fairly simple: the user performing the action needs the required access and, depending on the project type, agent permissions for the specific project.

There is also a difference between “I cannot move tickets” and “I cannot see anything”.

The golden rule for cross-project actions is: you need access to both projects involved. Without access to both sides, moving or viewing the tickets correctly will not work.

We don´t know your Permission settings. You must first take care with your admin that you have acces to destination project at all.

[Arkadiusz Wroblewski]

@Cristina Vasla 

@Trudy Claspill  Talready gave you some great advice here. Her company if I'm not wrong specializes in migrations, so her insights are definitely a huge help and will guide you.

I'm short on time today to write a deeply complex breakdown, but Trudy covered the essentials beautifully anyway.

The most important thing to keep in mind is that these kinds of actions always involve cross-project permissions and schemes. Because those configurations are highly unique to every single Jira instance and business need, we can only highlight general blockers, the exact implementation details are something you and your Jira Admin will need to figure out together.

Best,
Arkadiusz 🤠 ☀️

[Cristina Vasla]

Thank you, @Arkadiusz Wroblewski , we made it.

[Arkadiusz Wroblewski]

@Cristina Vasla 

Yay 😊. That's great.

If you find time to share, could you also tell us what the solution was if other community members had the same problem?

And don't forget to accept @Trudy Claspill  answer later if it helped you, as she provided the most detailed assistance

Arkadiusz 🤠