How to move customers from Jira (core/sw) to Jira Service Management

[Normann P. Nielsen (Netic)]

Vi have for +15 years had customers as tennants in our Jira Instance (Server -> Data Center) - all users licensed, with some "hacks" to hide buggy stuff and fields that does not support "tennancy".

Today we are a hybrid with about 10 customers on Jira (core/sw) and they are using many of the features as sub-tasks, linking, filter/dashboard etc.. Rest are moved to JSM. But these Jira (core/sw) users are relatively high issue volume users with a tight bond to our company.

Now we are moving towards cloud and are looking into getting the rest to JSM - but that would currently be pulling a lot of features away - with sub-tasks and linking to 2 most important.. 

So, any ideas how to mitigate this and add some of these and other features into their JSM experience, and make the transition a success. We are still in the very first process and are not fully familiar with the difference between Data Center JSM and Cloud JSM.

Good and factual recommendations regarding apps/solving of links and sub-tasks are more than welcome.

[Trudy Claspill]

Hello @Normann P. Nielsen (Netic) 

Can you tell us a bit about why you are considering shifting your customers to Jira Service Management when they have been using Jira Core/Software? That will help us give you more relevant advice and recommendations.

Also, do you have any experience with migrating Jira information from a Data Center environment to a Cloud environment?

Do you use third party plugins in your Data Center environment? If so, and if the features provided are important, you will need to investigate if those same apps are supported for the Cloud environment and for the JSM product, and check if the same features are available in the Cloud app. Due to the architectural differences, app vendors are not always able to provide the same features in the Cloud environment as they can provided in the Data Center environment.

You may want to consider engaging an Atlassian Solution Partner that specializes in Cloud Migrations and ITSM implementations to help you figure out the best path forward for your and your customers. There is a directory of Atlassian Solution Partners located here

https://partnerdirectory.atlassian.com/

Disclosure: I work for Praecipio, and we are an Atlassian Platinum Solution Partner operating in the Americas. If you are interested in exploring working with a Partner please visit our website and fill out the Contact Us form, and one of our team will reach out to discuss your needs.

[Normann P. Nielsen (Netic)]

Hi @Trudy Claspill 

"Can you tell us a bit about why you are considering shifting your customers to Jira Service Management when they have been using Jira Core/Software? That will help us give you more relevant advice and recommendations.":

1. Running a hydrid (on DC) is quite confusing for the rest of my "crew" + 150 people - and the whole "when can a customer see a ticket" - fields for JSW, Request Participants and Organisations and Request Types.

2. Creating tickets from the Jira side and have control over the above requires several automations to set these things, because people dont get it - and hence dont set fields.. (I know Atlassian recommends that the way is via the portal - but that is stupid for real jira users - and the cloud have improvements for that, luckilly)

3. Economics for licenses - many of our customer does not pay for the licenses and that is quite expensive with 25 Apps on top... (its a legacy thing, some have been with us + 10 years)

4. Economics for apps - we have several Apps for things like SLA and "field hide" and "worklog hide" that mey be dropped if all customers are on JSM.

5. Targeted and self-service - when the customers create via JSW, its not like creating Requests via the portal, where Request Types are more targeted/narrowed down, theay have many fields and the precision is often lacking.

We have done several mitigations via Clone Apps and scripts and Confluence documentation to support this. 

6. We are not sure that JSW (also in cloud) is 100% tennant proff; out customer does not like to see parts of other customer - and "bugs" like that "change reporter" permission give access to the whole user directory has to be mitigated, same for other fields that for some reason cant be "scoped down" to display project values only. The possibilities in cloud are nok like Data Center where CSS and Scriptrunner fragtments etc etc aer available.

Also, do you have any experience with migrating Jira information from a Data Center environment to a Cloud environment?

Ive done a few small as partner. We are starting currently and we use the next year for Jira DC -> Jira Cloud. Confluence is almost in cloud, but the whole migration system is emtremely buggy and the partner "efforts" and migration paths are... weellll, flaky (problably also due to architechtual issues). Our Jira is highly complex and customized with +100 groovy scripts, 200 automations etc etc.

Do you use third party plugins in your Data Center environment? If so, and if the features provided are important, you will need to investigate if those same apps are supported for the Cloud environment and for the JSM product, and check if the same features are available in the Cloud app. Due to the architectural differences, app vendors are not always able to provide the same features in the Cloud environment as they can provided in the Data Center environment.

Around 25 Apps :-(

"You may want to consider engaging an Atlassian Solution Partner that specializes in Cloud Migrations and ITSM implementations to help you figure out the best path forward for your and your customers. There is a directory of Atlassian Solution Partners located here"

Yes, I have been a partner for +10 years and are in contact with one.

BR,

Normann