ScriptRunner App Footprint Analysis for Jira & Confluence Data Center

[u/Lonely-Parfait1947]

Hey folks,

migration projects can be a pain, especially when you need to decide what to do with all the 3rd party apps installed on Jira and Confluence Data Center.

Atlassian already provides migration assessment tooling and App Usage, and those cover a good part of the picture.

I wanted to dig a bit deeper into the actual footprint that apps leave behind in an instance.

So I built two ScriptRunner endpoints, one for Jira Data Center and one for Confluence Data Center.

For Jira, the report looks at things like app-provided custom fields, how many issues actually carry values in those fields, screen and screen scheme placements, workflow references and app modules.

For Confluence, it inventories app modules and measures actual macro usage, with current and archived spaces reported separately.

The basic question is:

If we're considering removing or migrating this app, what detectable footprint does it still have in the instance?

The endpoints generate self-contained HTML reports, with JSON and CSV output available as well.

They don't try to measure clicks, views or general runtime activity. The idea is to complement Atlassian's existing tooling with another view of the current configuration and content footprint.

I've put the scripts on GitHub in case they're useful for anyone else doing DC assessments, app rationalisation or migrations:

https://github.com/cfaysal/atlassian-dc-app-footprint

It's still evolving, so feedback is very welcome.

I'd especially be interested in hearing from people who have done larger Jira or Confluence DC migrations:

• What app artefacts have caused surprises during assessments?
• What else would you want a footprint analysis like this to detect?
• Are there areas I'm currently missing that would be worth adding?

Issues and PRs are welcome as well.

[u/Paininator]

From a perspective of someone who has done multiple large scale migrations, I see some value in the tool. I'm speaking from Jira point of view as confluence scriptrunner usage has been marginal in the migrations I have done. 

Frankly I would say that collecting most of the data the tool provides is already pretty trivial with either JCMA or otherwise straight from the instance. It is of course convenient to get all the info in one neat package. I can see the value in saving time there. If the output is neat enough I could also see this as a starting point in more throughout cleanup. Another tool that would read the CSV, and get rid of the items that are actually obsolete or something along those lines. 

IHMO the biggest pain point in any scriptrunner migration is figuring out which scripts actually need to be scripts in cloud and which can be handled with automation (or other oob features). Second is finding out alternative methods for functions that can not be done with scriptrunner cloud. Third is actually converting the scripts for cloud. 

I put the conversion last because nowadays you can get pretty decent results with AI and what is left for humans is testing and understanding the business function of each script. 

[u/Lonely-Parfait1947 → u/Paininator]

Thank you for the input.
These two were built for a highly regulated corp with not even a connection to the internet.

No JCMA/CCMA installed at all. Imagining doing these apps footprint analysis manually got me in a “ oh hell no” mood so i was diggin the crates of my scripts folders and set up these endpoints.

[u/Paininator → u/Lonely-Parfait1947]

That sounds like a completely reasonable usecase. The most regulated environments are always a bit pain to handle.