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

Migration from Server to Cloud. Find the Add-ons really used.

Leo Epstein

Hello,

The Atlassian guys from advocates@am.atlassian.com cannot help and suggest "to ask the online Community". That's why I am asking here.

We have a lot of licensed JIRA and Confluence Add-ons on our servers.

If we migrate to Cloud, we would like to license only those Add-ons, which our users really need and use.

Is it possible to find out the following? And if so, how?

1. Who of our users has used a JIRA or Confluence Add-on during this year.

2. Which Add-ons have not been used in this year at all.

Regards

Leo

Accepted answers

Jack Brickey

AFAIK there is no system level tracking of usage. You would need to look at each addon and see if they have usage stats. I expect few do. Depending on the app you might be able to ferret out some data via JQL searches but that will be a stretch I suspect.

All comments

Jack Brickey

Walter Buggenhout

Hi @Leo Epstein,

I'm afraid @Jack Brickey is right on this matter. I'd like to add that not all apps manipulate data - so tracking usage of those could be a question of asking users how they are using them.

Since this is about migration, there's some things you could do to narrow down on the task at hand too:

First of all list all the apps currently installed (you probably have done so already);
Check which ones don't have a Cloud version available (they may pose you totally different problems)
For the ones remaining, check which ones do add custom fields, perform data imports, are front and center of your reporting, ... For those you will most likely be able to check fairly easily when they were last used.

Then you will probably end up with a few open mysteries. If you're not sure, ask your users about them. Getting their feedback may be really helpful in understanding what they do with them, why they are(n't) important and get their buy in if you were to decide to kick some stuff out. Or improve in other areas ...

Leo Epstein

Hi Walter,

Thanks for your quick and kind reply.

Do you know or can you imagine, why the "Customer Advocates" and "Senior Customer Advocates" and "Cloud Migrations Managers" from Atlassian could not give any answer to these two easy questions and just suggested "to ask the online Community"?

Regards, Leo

Leo Epstein

Hi Jack,

Thank you very much!

Regards, Leo

Walter Buggenhout

Hi @Leo Epstein,

Like most of us here on the Community, I am not working for Atlassian, but with Atlassian. So allow me not to speak on behalf of Atlassian with regards to the matter.

At the same time - when speaking about Apps you are referring to a huge ecosystem. The Atlassian Marketplace is host to several thousands of different apps built by several hundreds of different companies. Here, on the Community platform you'll see many people who actually use all these products together or like myself implement them for other customers as well. There's a good chance you'll find many people out here with lots more experience with Atlassian products and Marketplace apps combined that Atlassian itself.

So - looking at it through the glass that's half full - it's rather a matter of pointing you towards the best chance of a valuable answer. In my view, pointing you towards the Community is way better than leaving you out there with a simple "we don't know".

So we all try our best to fill in gaps that may exist here and there. I know that usually goes quite fast as well. And I hope you've had some helpful input as well :-)

kr,

Walter

Nic Brough -Adaptavist-

My instinct is to explain @Jack Brickey 's answer with a bit more tech detail, as well as echo @Walter Buggenhout 's suggestion that you will probably want to look at each app separately.

The problem here is actually that apps have a lot of flexibility and power. This is a good thing on the most part, because it means apps can be built to do some really useful things, but a consequence is that there are a lot of very different entry points to them.

To track usage, you need to identify and log the usage of the entry points. But every one of those is unique to the app in use, although some can be grouped (for example, many apps provide workflow functions - same entry point for each type of function).

But a lot of apps provide many functions and in different ways, and it's easy to build one that is very hard to track usage of.

One example would be an app I wrote for a client which I know I could track - it had a bundle of project reports, field types and workflow functions. To track

workflow functions - I'd search the workflow xml for my app's class name
reports - I'd have to parse the server logs for people hitting the urls
field types - I'd need to read the list of custom fields and check if any of them are of a type I'd written for

And then you'd need to cross-reference that with at least project config, but maybe also activity.

So, from three relatively simple additions to Jira, you can see there are already three totally different and potentially complex ways to identify usage. There are actually hundreds, each of which would need its own dedicated code to id...

Thorsten Letschert _Decadis AG_

Hi @Leo Epstein ,

when you're interested in the usage of 3rd party apps within your workflows, I'd like to recommend Admin Toolbox for Jira (https://marketplace.atlassian.com/apps/1214246/admin-toolbox-for-jira?hosting=server&tab=overview) and it's built-in workflow report (https://apps.decadis.net/pages/viewpage.action?pageId=13076594) - besides many other useful features for administrators. However, this 'only' helps for workflow-related apps that provide additional conditions, validators, and post functions.

Disclaimer: I'm part of the team behind the aforementioned app.

Cheers
Thorsten

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira-software

jira-software-server

migration-customer-care