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

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

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; } } }

Efficient way to switch to JSM

Brian Hennessey_16l8cu

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

Accepted answers

Alex Koxaras -Relational-

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

All comments

Alex Koxaras -Relational-

Hi @Brian Hennessey

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

Hope all the above helps.

Alex

Brian Hennessey_16l8cu

@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_16l8cu

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

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-service-management-cloud

jira-service-management