nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Migrating a Jira Software project to a Jira Service Management Project

Michele Ghirxi

Hi,

We have a scenario where we'd like to change an existing project from a Jira Software one, to a Jira Service Management project. This is not doable in Jira Cloud, as far as I am aware, the only way forward is to create a new JSM project and the migrate the data from the old project into the new one.

However, one of the issues we encountered when doing this, specifically when using the bulk move, is that the tickets do not maintain their original ticket numbers after move. So for example, KEYA-123 turns into KEYB-213 after move. This isn't ideal for us, we'd like to keep the key order as it's used for reports and so on.

Have any of you been in this situation before, and how have you tackled it?

Accepted answers

Michele Ghirxi

It seems that in order to maintain the KEY order, you'd either have to use a CSV Import which comes with other issues or else make use of a third party marketplace add-on.

All comments

Viswanathan Ramachandran

Hi @Michele Ghirxi

This is by design and is expected behaviour. Just for your references, you can rename the keys (old project to something else and new project to your expected) but the migrated issues will still keep their new numbers.

If you like to retain the Jira software project, you can create a new custom field referencing the old key with matching new numbers. For large number of issues, a custom python script can do this.

Dave Mathijs

Hi @Michele Ghirxi

Possible workaround:

Create "KEYB" software space
Move "KEYA" work items to "KEYB" software space
Delete "KEYA" software space and delete from trash immediately (so the "KEYA" space key can be re-used)
Create new service space with space key "KEYA"
Move work items from software space "KEYB" to service space "KEYA".

However, the order sequence of the work items would still not be guaranteed, i.e. old work item KEYA-24 (in the software space) would not necessarily be the same work item with new KEYA-24 work item key (in the service space).

Furthermore, how are you handling work item hierarchy (f.e. Epic/Standard Work Types/Sub-task Work types vs. the "flat" hierarchy in a service space)?

zoltanersek _outpostlabs_dev_

Unfortunately, issue numbers are allocated from the destination project's sequence, so there's no supported way to preserve KEYA-123 as KEYB-123 during a move.

One thing I'd add is to think about who actually consumes those issue keys. If they're referenced in reports or external systems, it can be worth introducing an "Original Issue Key" field before the migration and populating it as part of the move. That gives you a stable reference for historical reporting and integrations without relying on the new key.

Also worth noting: Jira maintains redirects from old issue keys to new ones after a move, so existing links and bookmarks generally continue to work. It's mainly reports, exports, and external references that need planning.

Michele Ghirxi

Hi @Dave Mathijs ,

Thanks for your feedback. We are actually aware of how to keep the same key name, mostly my issue was with maintaining the KEY order for the tickets we migrate.

Unless I misunderstood your question, the work item hierarchy is the same for us across all of the projects, be it a software or service desk space.

Dave Mathijs

In a Jira Software space, you usually have a 3-level work type hierarchy (check the work type scheme of your space):

1. Epic (is the parent of)

2. Standard work types like Task, Story or Bug (is the parent of)

3. Sub-task work types like Sub-task or custom created sub-task work types

In a Jira Service space, you usually have a 1-level (or 2-level) work item hierarchy:

1. Service request, Incident, Problem, Change and/or other standard work types

2. (Optionally) Sub-task work types like Sub-task or custom created sub-task work types

Michele Ghirxi

It seems that in order to maintain the KEY order, you'd either have to use a CSV Import which comes with other issues or else make use of a third party marketplace add-on.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

jira-service-management-cloud