Open source: Assessing the real app footprint before a Jira / Confluence Cloud migration

[#1]

Hey Team,

One question that keeps coming up during Data Center to Cloud migrations is:

Do we actually still need all of these apps?

The installed apps list only gets you so far.

An app can have been installed for years and barely leave any footprint in the instance. Another one might look fairly insignificant at first, but then you find custom fields populated across thousands of issues, references in workflows and screens, or macros spread across a large part of Confluence.

That distinction matters quite a bit when you get to the cleanup and app assessment part of a migration.

I ended up building some ScriptRunner-based tooling around this and eventually turned it into an open-source repo:

Atlassian Data Center App Footprint

It currently covers Jira Data Center and Confluence Data Center.

For Jira it looks at things like app-provided custom fields, whether those fields actually contain data, contexts, screens, workflows and the projects/issues reached through that configuration.

For Confluence it looks at app-provided macros and modules, actual macro occurrences in content, affected spaces and also keeps native User Macros separate from Marketplace apps.

Archived data is handled separately as well. This turned out to be important in practice. An app can look quite heavily used until you realise that most of its footprint is sitting in archived projects or spaces.

The report is available as HTML, JSON and CSV, but one feature we've found particularly useful during an actual migration is the Confluence page export.

Instead of treating the assessment as a one-off report, we can use the generated page as a working document.

There is a Decision column where the migration team can add things like KEEP, REMOVE, REPLACE or just write whatever notes are needed.

When the assessment is run again later, the technical data gets refreshed, but the existing Decision cells are carried over unchanged.

So in practice you can:

run the assessment → make decisions → clean things up → run it again → see what changed

without losing the decisions already made by the team.

If an app disappears between runs, its previous decision isn't silently thrown away either. It is kept separately so you still have the record.

I was also quite careful about incomplete measurements.

Some scans can get expensive on larger instances, so there are configurable time budgets. If something could not be measured, the result says NOT MEASURED rather than quietly turning that into a nice-looking 0.

The same idea applies to the Confluence export. If the existing page cannot be read reliably, the script doesn't overwrite it with an empty Decision column. It stops instead.

This isn't meant as a replacement for JCMA, CCMA or Atlassian's App Usage functionality. There is definitely some overlap.

I see it as another piece of evidence during migration assessment and cleanup.

And importantly, a low footprint does not automatically mean an app can be removed. The scripts measure detectable configuration and content footprint, not whether somebody is actively using an app UI, calling its REST API or relying on some scheduled functionality.

We're already using this on a real customer Data Center environment as part of an actual migration/cleanup assessment, so a fair bit of what is in there came directly out of things we needed in practice rather than from a lab scenario.

The project is Apache 2.0 licensed.

I'd be interested in how others working on larger DC → Cloud migrations approach this.

What evidence do you normally want to see before deciding whether an app should be migrated, replaced, rebuilt using native Cloud functionality, or removed?

Hope this is useful to others working on similar migrations.
PRs, issues, and contributions are very welcome :)

cheers
cF

[Marcelo Montaño Sánchez]

Hi @C_Faysal _CFcon_ 

This is very interesting.

I'm currently working on a similar DC → Cloud migration assessment, where we're analyzing a fairly large custom app/plugin estate before deciding what should be rebuilt, replaced, sunset, or moved to a hybrid approach.

One of the challenges we've encountered is that the installed apps list doesn't tell the whole story. We've been looking at things such as custom fields, workflows, screens, REST integrations, external services, and ScriptRunner scripts to understand whether an app is actually being consumed and by whom.

That's why I particularly like the idea of treating the footprint as evidence rather than automatically using it as a migration decision.

One area I'm curious about is ScriptRunner dependencies. In some environments, an app may have little visible footprint in screens or workflows but still be actively consumed by ScriptRunner scripts, listeners, jobs, or external integrations.

Have you considered detecting those dependencies as part of the footprint analysis?

Marcelo 

[C_Faysal _CFcon_]

Hey @Marcelo Montaño Sánchez 

Thanks, and yes, that’s a very relevant distinction.

ScriptRunner is actually one of the reasons why we deliberately treat the output as evidence rather than as an automatic migration decision.

The current footprint analysis can collect the relevant ScriptRunner artefacts, but it does not yet try to semantically interpret Groovy code and reliably infer dependencies on other apps. I would be cautious about doing that with simple string matching, as those dependencies can be indirect, dynamic, or hidden behind helper classes or REST calls.

What we want to provide instead is enough context to make that next analysis step possible. For example, the ScriptRunner exports can be reviewed separately or fed into an LLM or code analysis workflow to identify references to app APIs, custom fields, services, REST endpoints, etc.

So I see ScriptRunner dependency detection more as a second analysis layer on top of the footprint data rather than something the footprint itself should blindly classify.

That said, exposing obvious references or dependency hints without turning them into migration decisions would definitely be an interesting extension.

cheers

cF

[umashri]

Hi @C_Faysal _CFcon_  , 

This idea is amazing does this dashboard help to find out legacy content that might cause a problem post migration to the cloud. For eg: legacy tables, legacy comments made on a confluence pages. This insight help to nurture the pre-migration checks even more better way. Or can this be added as a feature request in the project link which you have shared. 

[Jaume Guasch Gutsens]

This is an excellent tool that effectively complements JCMA and CCMA. The provided information is highly valuable and will certainly support our migration process. Thank you very much for sharing it.

[C_Faysal _CFcon_]

Thanks @Jaume Guasch Gutsens 

you’re so welcome

[C_Faysal _CFcon_]

@umashri 

Thanks, and yes, that would be a very useful direction.

The current scope is primarily app footprint and dependency analysis. It tries to answer questions such as: Which apps are actually being consumed, where are they referenced, and what evidence do we have before making a migration decision?

It does not currently perform a general Confluence content-readiness scan for native legacy content such as old content structures, unsupported macros, or potentially problematic storage-format elements.

I think that would fit well as a separate extension of the project, though. Something like a content migration risk / readiness analysis alongside the app footprint could provide additional pre-migration evidence.

One distinction I would make is that an old table or comment is not necessarily a migration problem simply because it is old. We would want to detect specific content patterns that are known to require attention during a Cloud migration rather than just flagging content by age.

Feel free to add it as a feature request in the repository. I think it is definitely worth exploring.

best regards