Efficient way to switch to JSM

[Brian Hennessey]

Hello everyone,

currently, we handle all our internal IT requests via Jira. We are thinking about moving everything in regard to our Internal IT to Jira Service Management. My questions, therefore, are:

• Is there a way to do this in an efficient and easy manner that doesn't result in data loss or manual adjustments?
• Or do I simply have to "move" all the issues and reassign them to the appropriate JSM issue type?
• Is there something else that I should be wary of? Or look out for?

I would welcome it if anyone that has already done something similar can give me some advice. Thank you very much.

Kind regards

Brian

[Alex Koxaras -Relational- · Accepted solution]

Hi @Brian Hennessey 

I would create a new JSM project and try to share settings with the existing project you have. This will result in having certain shared schemes, such as notification, screen, permission, issue type, workflow etc. This will be very handy, since you don't want to lose any data (data are stored in fields, and fields live within screens).

The check I would perform before moving any issue to the new JSM project would be:

• Check that issue type scheme is the same
• Check that screen scheme is the same
• Check that workflow scheme is the same
• Check that permission scheme is the same
• Check that notification scheme is the same
• Check that issue security scheme is the same
• Check that field configuration scheme is the same
• Check that all people are included in the new project
• Check that any automation applies to the new project as well
• Check that your custom fields which are included in your screens do not have any scope that restrain them to only your old project
• If you have any dashboards with gadgets, make sure to cross check the filters
• In addition I would create request types and associate them with the corresponding issue types

I think that's about it. BUT before doing any of the above, may I ask the reason behind moving to a JSM project? Are you going to add all your employees as customers? If yes, then you have to set up your JSM project as well.

Hope all the above helps.

Alex

[Brian Hennessey]

@Alex Koxaras -Relational- Thank you very much for your fast reply and the information you gave me on what I should look out for. 

BUT before doing any of the above, may I ask the reason behind moving to a JSM project? Are you going to add all your employees as customers? If yes, then you have to set up your JSM project as well.

• Our current way to handle internal IT issues does not work as well and is not as organized as we want it to be, so we're considering switching to JSM because it promises a more organized way (SLA's, Opsgenie, Knowledge Base, etc.).
• Yes, my idea was to add our employees as customers so they can actually track the issues as well and comment on them. I want to use the free JSM module with 3 agents. But what do you mean by "you have to set up your JSM project as well"? Could you clarify this?

[Alex Koxaras -Relational-]

Brian,

I believe that you are in the right direction, considering all the inputs you provided here. The reason I asked you, is simply because there was no apparent reason for you to move, and save all the trouble. However, as I said, you are correct in considering moving to a JSM project.

You can use the free plan to cover your needs, but make sure that the free plan has all that you need. Setting up a JSM project has to do with:

• Setting up Request types
• Creating SLAs and calendars
• Creating Organizations and allocating the user to these orgs
• Setting up the portal
• Setting up the email and consequently the request type to receive requests via email
• etc

[Brian Hennessey]

@Alex Koxaras -Relational-

that is exactly the point why I am asking because it could potentially take a lot of time to get everything just right with JSM. If it is worth it, we will see. I just wanted to make sure that all the variables are considered. Personally, I would prefer setting it up because, in the long run, it seems to be a better way of handling issues like that. 

Anyway, thank you very much, I think I got all the information I needed.

[Alex Koxaras -Relational-]

Glad to be of assistance!

[Nic Brough -Adaptavist-]

There is one small catch in what Alex has said.  When you are checking the permission scheme, you need to be aware that JSM projects handle users differently and the permissions for a Software or Work Management projects are usually not suitable for JSM projects.  You can end up with Jira complaining that there are errors in your permission scheme that make your JSM project non-functional.  It can correct them for you, but that means overwriting what you've set up.

So when you're checking the permissions are the same, what I would do is create a JSM project and apply its permission scheme to your existing development project - that way, you know you'll be migrating stuff that won't break your new project.

[Brian Hennessey]

@Nic Brough -Adaptavist-  Thank you! I will take that into consideration!