Guidance on validating custom scripts at scale after Jira 11 upgrade

[suportejira_br_telefonica_com]

Hello everyone,

Did anyone face issues with libraries/classes being deprecated, replaced, or changed during the Jira Data Center upgrade from 10.3.9 → 11.3.6?

After our upgrade, we identified several impacts on scripts and customizations, especially related to changes such as:

• migration from javax.* to jakarta.*
• library updates (e.g. Jackson)
• changes in Atlassian APIs, such as the Search API

I’d also like to understand if anyone used any approach to identify these issues at scale, for example:

• broken scripts
• invalid imports
• impacted customizations
• failing listeners/post-functions

Atlassian Support suggested evaluating tools like Eclipse Transformer and OpenRewrite to help with script migration/adjustments.

Has anyone used these options in a similar scenario? Did they work well?

Thanks!

[garrett_lessard]

Hi @suportejira_br_telefonica_com 

Teams frequently run into these exact issues when upgrading Jira Data Center from 10.x to 11.x. The move from javax to jakarta, dependency updates like Jackson, and shifts in the search APIs are the usual culprit lines. This impact is almost always concentrated in custom apps, ScriptRunner or Groovy scripts, and any in-house Java code compiled against older Atlassian APIs.

Here is a practical way to find and fix these issues at scale, along with how Eclipse Transformer and OpenRewrite actually can be used in this scenario.

What breaks in 10.3.9 to 11.3.6 upgrades

The shift from javax.* to jakarta.* is the most disruptive change. It breaks servlet filters, JAX-RS REST resources, validation annotations, and dependency injection. You cannot just blindly find-and-replace the package names either; some APIs moved entirely, bundles changed, and OSGi wiring can fail even if your code compiles perfectly.

Library upgrades like Jackson bring changes to method signatures and transitive dependency versions, which can lead to classloading conflicts. If you shaded or embedded libraries inside a plugin, you will likely hit duplicate classes or split packages.

Atlassian search APIs are another common pain point. Deprecated internal classes have disappeared entirely, and query building or indexing services have evolved significantly between these platform versions.

For scripted customizations like ScriptRunner, JMWE, or Power Scripts, expect imports to fail, component lookups to break because the underlying service changed, and listeners to fail at runtime due to signature changes. Groovy scripts will often throw compilation errors right after the upgrade.

How to find issues at scale

Instead of hunting for bugs one by one, start with a full inventory. List all marketplace apps and their versions before and after the upgrade, noting which ones handle scripting or workflows. Map out all custom code, in-house plugins, and custom JARs, alongside every ScriptRunner script, listener, and scheduled job. This inventory becomes your migration backlog.

The fastest way to get a clear signal is log-driven discovery. After upgrading a staging environment, check the Jira application logs immediately for ClassNotFoundException, NoClassDefFoundError, NoSuchMethodError, OSGi bundle wiring errors, and Groovy compilation failures. This tells you exactly what fails at startup.

For static analysis on Java plugins, build against Jira 11.x dependencies in your CI pipeline and treat compilation errors as your first gate. You can use jdeps to detect references to removed packages. For Groovy scripts, export them and use ripgrep to scan for javax. imports or known removed packages.

Because listeners and post-functions only fail when triggered, run a scripted test plan in staging. Create issues, transition them through workflows, and watch the logs during these actions to catch runtime-only failures.

Eclipse Transformer vs OpenRewrite

Eclipse Transformer is great for mechanical refactoring of javax.* to jakarta.* in Java code and compiled artifacts. However, it does not understand Atlassian-specific API changes or semantic shifts like altered method signatures. For Groovy, it only works as a basic text transformer. Use it as a quick first pass to clear out the bulk of your import failures.

OpenRewrite handles large-scale, repeatable refactoring using recipes for framework migrations and dependency upgrades. It shines because you can run these rules across multiple repositories consistently and even write custom recipes for your own code patterns. The downside is that you still need Jira-specific knowledge for Atlassian API changes, and it is primarily focused on Java, making it less of a silver bullet for ScriptRunner Groovy scripts.

A practical fix strategy

Triage your fixes by failure mode. Address startup and OSGi failures first, then move to runtime failures like listeners, and handle latent scripts last.

Automate the easy part of the work. Use Transformer or OpenRewrite for the package name changes, and align your dependency management with Jira 11's provided libraries to avoid bundling conflicting versions. You will need to manually rewrite the Atlassian search API changes, as they usually require a structural redesign rather than a simple refactoring. Going forward, wrap these Jira APIs behind your own abstraction layer to make future upgrades less painful.

Finally, check your marketplace apps. Ensure the versions you use are explicitly compatible with Jira 11.3.6 and check the vendor migration guides. Some apps cache or compile scripts and require a clear reindex or recompile step after the upgrade.

To narrow this down, let me know if your scripts are mostly ScriptRunner Groovy or custom Java plugins, and whether they are stored in a Git repo or directly in Jira. It would also help to know which specific search APIs you are hitting.

Cheers,
Garrett Lessard Appfire Expert Services