How to Migrate a JSD project to a Jira Software Project?

[Amanda Kostik]

We are working on converting several projects that are jira service desk projects into the jira software type projects. We understand there are certain features and functionality available in JSD not available in the core jira software. Here is some of the insight we are already aware of:

• JSD is a regular Jira project with "extras" on the top
• The extras are called agents 
• When the agent license is removed, the project will still be there, but the top part is where the request types, queues, etc are located
• To change from JSD to software, you can change the dropdown in the Jira project but the request types, etc will not change. They will still be associated to the top layer (agents) which you no longer have access to. The project would lose the left side bar.
•  If the project is using JEMH instead of the JSD email, it should be ok to switch the project type. However, if they are using the JSD, we will not be able to switch. 
• It is a bad idea to switch the project type since the previous project configurations will be in the database and we do not know how the project will behave.
• Best practice would be to create a new software project with a new pkey.
• Export issues, workflows, etc (request types are JSD but everything else is Jira)
• Import the exported issues

What is the best method to use for migrating the data from one project type to another as cohesively as possible?

[Nic Brough -Adaptavist- · Accepted solution]

It's not quite like that.  You're not far off, but I think of it a little differently to this.

A Jira project of any type is a collection of issues and configurations for how they work.

A JSD project sits on top of a project and provides functions such as the portal, queues, SLAs, requests, the email channel, and the customer interface.

An Agent is a Jira account that is able to work on the issues in the project (non-Agent Jira users can only see and comment on issues)

If you change the project type to Jira Work Management or Jira Software, all that extra JSD functionality goes away (the data is retained, but not of any use to you.  The issues themselves are unchanged.  But you won't be able to get to the Requests anymore, nor create new ones.

If you are using the email channel, yes, that will stop working, and you will need to consider a replacement, either an email handler or an app like JEMH

1. It might not be a bad idea to change the project type - if you really don't want the JSD functions anymore, then there's no harm in the change.  You may need to tinker with workflows and automations though, if customers were able to do things like approvals or closing requests.
2. The second best option is not export/import - you create your new JSW/JS project, configured how you want,  Then you can move the issues into it from the old project. 
3. Export/import is going to lose you even more data than a move would

Both move and export/import are going to destroy your request data, you won't see it re-appear if you flipped the new project to JSD to have a quick look, unlike your first option

[Amanda Kostik]

Hi there! Thank you for such a fast answer! We did do some exploring and discovered that moving the issues does pretty much exactly what we want! The only issue is that we are hoping to keep the project name and key the same. We tested with creating a new project with a placeholder name, moving the issues, and renaming the old project to something else, and changing the old project key to something else. We were hoping this would allow us to change the placeholder name and key on the new project to what it originally was pre-move. However, the system keeps insisting the project key is already in use. Is there a way around this?

[Madalina Mutihac]

Hi Amanda,

Unfortunately that is not possible. Reuse of existing project keys is not supported even if the project was deleted or the key renamed, as the reference to that key is still kept in the database (allowing you to redirect tickets automatically when searching for old keys). 

It is indeed inconvenient.