Helping the public sector to grow towards digital independence is a topic close to our hearts. That's why we enjoy building the Wiblio platform for Berlin's public libraries based on open source software, engaging in a European open social ecosystem and rooting for our friends at Eurosky.

There is a new challenge on the horizon: Atlassian is sunsetting the popular project management solution Data Center in March 2029, trying to push their customers to migrate to the cloud offering. While Data Center could be self-hosted, Cloud cuts down on customers' digital sovereignty by moving their data onto servers owned and operated by Atlassian. So migrating where and how is a big decision…

In this post we investigate an important aspect that might go under the radar: migrating the ScriptRunner extension, which defines the experience of Jira Data Center customers and represents a big part of their setup.

What is it?

The ScriptRunner plugin by Adaptavist provides Jira Data Center users with a mechanism to run Groovy scripts to customize their Jira instance. The scripts can have full access to the system and are only constrained by the privileges of the user who runs them.

As you can imagine, over time companies have accumulated many scripts to adapt their Jira Data Center instance to their needs. It holds their well-established workflows and may even hold the company together process-wise. But what are they actually "customizing" and how?

How can I use it?

In general, you can write Groovy scripts inline within Jira Data Center. ScriptRunner provides various fields where you can insert your code. Additionally, you can use the Script Editor to define and organize scripts in a central place and reuse them across Jira.

We can classify the features offered by ScriptRunner:

1. On-demand scripts

   You can trigger scripts to run as a one-off action. A popular example is to update the status of all tickets belonging to a specific parent ticket at once.

2. Event-driven scripts

   With ScriptRunner, you can set up listeners that run scripts when specific events occur. You could, for instance, automatically add a user as watcher to tickets created in a project.

3. Scheduled scripts

   You can run scripts in regular intervals. A classic example is to change the status of all tickets that have been open for a configured timespan.

4. Script fields

   Script fields are a powerful feature that allows you to add fields that follow custom logic you define in a script. A basic use case is a field that shows the total time an issue has been in the status In Progress.

5. Custom REST endpoints

   ScriptRunner for Jira Data Center allows you to define new REST endpoints and attach a script to them. This could, for instance, be a new endpoint that an external system calls to inform Jira about events happening in that system. The script could then automatically create corresponding tickets in Jira.

6. UI modifications

   There are multiple ways to customize Jira's UI with ScriptRunner. You can use Behaviours to modify the logic of existing fields in Jira, for example making a field read-only depending on the role of the user. Apart from Behaviours, you can define and display new elements in the UI with Script Fragments. This gives you the power to completely customize your experience in Jira Data Center.

With this broad variety of possibilities to customize and shape the experience of Jira Data Center for a team, it can become quite hard to even distinguish between what is "Vanilla Jira" and ScriptRunner-enhanced Jira. The integration is everywhere, and users are trained to work with their specific "flavor" of Jira.

Migration

With Jira Data Center's end of life looming, migrating away is no longer optional, and for many teams ScriptRunner is the part of that move they're most worried about. Years of business logic live in its scripts and configuration, and it's not obvious upfront how much of that survives a move to a different platform, or what it would even take to find out. Before any of that can be answered, teams first need to get a handle on what's actually there.

ScriptRunner is not just a collection of self-contained scripts. Its content is also stored in Jira itself, with cross-references to ScriptRunner-provided functionality and to customizations made by the users themselves. So we're dealing with quite a web of customizations around Jira Data Center.

Access to the Data

ScriptRunner is proprietary, closed source software, so users are vendor-locked into it. It offers a Script Registry as one centralized location for users to manage their scripts: search scripts, perform static checks, see deprecation warnings and things like that. Here, users also have the ability to export all of their scripts and configuration. This can be used to move the setup to a different instance or as a potential escape to an entirely new system.

The export bundles everything ScriptRunner knows about an instance into a single .zip file. The actual .groovy sources from the script roots are included, but so is all of the surrounding configuration: Jobs, Listeners, Fields, Behaviours, UI Fragments, REST Endpoints, Resources, and Workflow functions each come out as their own .json files. Saved JQL filters that rely on a ScriptRunner JQL function are exported too. Custom field definitions get their own file as well, tucked into an Instance Information folder, with enough detail (name, type, ID) to reconstruct the field landscape elsewhere.

What makes the export genuinely useful for migration planning, rather than just a backup, is a .csv file summarizing every configured script and JQL filter in one table. For each entry it lists an ID, its type (Job, Listener, Behaviour, and so on), its name, how many custom scripts are associated with it, which projects it's mapped to, and when it last ran. That last-run column in particular is a handy way to tell which scripts are still doing real work and which have quietly gone stale.

This list gives a good centralized overview of how and where ScriptRunner shaped the Jira Data Center instance at hand. It shows which features of ScriptRunner are important for the team's established workflows and gives a good starting point to plan a migration strategy.

Architecture

At its core, ScriptRunner for Jira Data Center behaves a bit like a REPL bolted directly onto the running instance: scripts execute in the very same JVM process as Jira itself. Scripts have direct access to Jira's internal Java APIs, which in practice means near-total control over the running system. A script can act as any user, fully bypass Jira's own authentication checks and reach deep into internals to manipulate core functionality.

That power comes at a cost: as scripts share Jira's process, a bug in one of them can impact, degrade or even take down the entire instance. There is no sandbox around ScriptRunner on Jira Data Center. The only safeguard is procedural: be careful about who is allowed to write or install scripts in the first place…

This in-process model is hard to imagine being made available for a cloud product, such as Jira Cloud. Cloud product instances are usually shared by multiple tenants. Giving add-on code similar unrestricted same-process access would mean one tenant's bug or a bad actor could potentially affect everybody else on that infrastructure. Therefore it's very unlikely that teams will find the exact same architecture they are used to from Jira Data Center at any cloud product.

While being super empowering for its users in the first place, this unique architecture of ScriptRunner within Jira Data Center becomes a challenge when planning to migrate to a different product or platform. It may very likely be necessary to approach things completely differently on other platforms. There will be gains in stability, reliability and security of course, but it also makes the migration process more labor-intensive.

Example: Jira Cloud

Jira Cloud is a good example of how different things have to work once that in-process privilege is off the table. ScriptRunner is also available as an extension for Jira Cloud. However, there it is running as its own externally hosted service, rather than living inside of Jira itself. So scripts can no longer directly access Jira internals via its Java API. Instead, every interaction needs to go through Jira's public REST API, scoped down to a defined and documented set of permissions. With that interaction model, it's also no longer possible to bypass authentication: requests are always authenticated and authorized based on which user or add-on actually triggered them. As a side effect, the synchronous, in-process event handlers that Data Center scripts may rely on aren't possible any more either. Instead, scripts in Cloud need to operate based on an asynchronous, webhook-driven model.

That architectural gap is wide enough that Adaptavist can only offer a migration suite, rather than a direct converter. There is no 1:1 porting from Data Center to Cloud and the migration process has to be monitored and reviewed by experts from the team.

Conclusion

ScriptRunner is a powerful tool and plays a vital role in how people use and have used Jira Data Center over the years. With the end of life of Jira Data Center, the teams running those highly customized instances should not be left alone or forced to trash their fine-tuned workflows.

It makes sense to support them in porting their setup to a new platform and age. This also yields the chance to review, rethink and modernize things on the go. Maybe this is even better and more sustainable in the long run, compared to a direct conversion of their setup from one system to the other.