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?

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

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

[Dave Mathijs]

Hi @Michele Ghirxi

Possible workaround:

1. Create "KEYB" software space
2. Move "KEYA" work items to "KEYB" software space
3. Delete "KEYA" software space and delete from trash immediately (so the "KEYA" space key can be re-used)
4. Create new service space with space key "KEYA"
5. 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)?

[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