Alternative to Jira Service Management

[Ish]

We are planning to decommission JIRA Service Management (JSM) because it is no longer meeting our requirements.

Is there any way to implement same functionalities provided by JSM ? Can we do that in JIRA?

Any leads would be much appreciated. 

[StephanieC]

So, if its helpful... we are planning to create JSW projects/issue types/workflows and a few custom fields (that we should have done originally) and screen schemes to mimic the JSM projects, using Issue types to replace the Request types, then migrate the issues using bulk move.

We have successfully migrated our smallest Service Desk Project to an existing project just by bulk moving the issues to very similar issue types. This project had originally been partially migrated OFF of JSW to JSM, so it was pretty straightforward to "move it back".  

One of the most important things in data migrations is field mapping. Most of the system fields will map automagically when you do the bulk move by issue type, but you will need to create a mapping document to be sure you have a place for all of the custom fields to go, ensure your screen schemes support the fields you need when/where you need them, and to ensure your workflows match (enough) so that future use of the project makes sense. 

We created a Migration plan that for each of our 6 service desk projects listed each request type, what workflow/issue type & Request type it WAS, what workflow/issue type it WILL BE, then noted any fields that need to be created and the screens where they should appear. 

We preferred moving the issues to exporting/importing for auditing and time logging reasons (we connect to Tempo). 

Since the team who built it never leveraged the SLAs or tagged KBAs correctly, and our VOC shows that our users dislike the portal (they want to create & manage tickets the same way the do for other JIRA projects), we personally arent losing much. You can leverage Sprint boards and/or JIRA dashboards for "Queues" and planning, so we dont see that feature as lost either. Our ERMO dept ok'd using Issue level security for sensitive issues and a locked down permission scheme for our on-off boarding project so it works for us. 

Again, we are small and have very little support in-house so this move made it so our "JIRA Champs" only have to know how to support/ configure JSW. If you need SLAs and have the staff to support KBAs and JSM in general, it is a great tool. 

If @Nic Brough -Adaptavist- (my personal Atlassian Hero) has any other helpful hints we'd love to hear them :-)

[Ish]

This is exactly what I did. Exported the issues from JSM, created a mapping document, and exported the issues to JSQ. And, did all the required things we needed. It is working fine for last two years.

[Nic Brough -Adaptavist-]

I'm not sure I can add anything to this @StephanieC - what you've done here is exactly what I would do!

Analysis of what you need, build that as an empty shell, compare it to what you have already, and work out how to map the old data structure to the new one when items are moved from old to new structures.

[StephanieC]

We are looking to do the same, as data analyzed across the last 6 years shows that we never took the time to fully implement SLAs & KBAs and the instance was not optimally configured (we have 108 request types for a company of 158 people) !! :-0 Unfortunately, we dont currently follow the ITSM model, and it would be a pretty large effort to do so for us.

On top of that, our JSM support person left the company and we have a limited support staff  - and no budget to hire in this economy... so the idea is put the projects in JIRA SW (so Atlassian support doesnt have to know/ support JSM) and lock down as/if needed with Permissions and Issue security. 

We are planning to leverage Scrum boards and/or JIRA Dashboards in place of the queues, and will retain the Confluence spaces associated with the JSM projects 

That said, my main question is what it looks like when we uninstall JSM - I assume we lose the OOB Request & issue types / JSM fields, etc.

So if we build the new projects then move all of the historic tickets to them, do we first have to re-create any fields we will "lose" during the uninstall so we can map the field data to the new JSW projects? 

[Ish]

You can follow the below steps:

• Import your current issues to an excel spreadsheet. 
• Remove the unwanted fields, if required.
• Create a new project on the JIRA software with the same workflow and fields as JSM project.
• Upload the downloaded issues to the newly created JIRA project using the bulk import issues functionality.

[Nic Brough -Adaptavist-]

No, the whole point of JSM is that it is an extra layer of functionality on top of Jira.

The first question has to be what are you looking for here?  What are your requirements that JSM is not meeting?

[Ish]

We want users to view queues which is not possible until we grant them an agent license.

[Nic Brough -Adaptavist-]

Why would you want a customer to see a queue?

[Ish]

Because that is our requirement. The customers are our colleagues.

[Nic Brough -Adaptavist-]

Then they're not customers or your requirements are not for queues.  

I'm sorry, but you need to make up your mind if you want a service desk or not.

[StephanieC]

@ish - Do they want to see the status or the tickets in their entirety? There are several ways you can expose some aspects of the tickets without granting a license (i.e. Permission Scheme for one). It would probably be helpful for you to understand WHAT exactly they need and WHY they want to see it before making a blanket change. 

[Ish]

This was decommissioned long ago.