News from the product desk: Migrating ScriptRunner for Jira Data Center to OpenProject

Many organisations moving from Jira Data Center to OpenProject ask the same question: what happens to our ScriptRunner scripts? There is no short answer. ScriptRunner is not one feature but a whole toolbox, and each part of it deserves its own answer. In this post, I share our current standpoint on how to migrate ScriptRunner, and why I believe most of what ScriptRunner does belongs in the core product rather than in a plugin or script.

Further, I argue that the whole life cycle of a script, from its development, over testing and distributing to its maintenance is so complex that it deserves more than a Web form for pasting in some scripts. You can look at the broader ScriptRunner ecosystem that they try to replicate all the tools that are available in a standard software development environment, from logging, to testing and distribution. I don’t believe that OpenProject should entail all the tools for software development. We should rather focus on extending OpenProject’s core functionality.

To challenge that belief, I ran a small product experiment: I built an OpenProject plugin that lets you paste Ruby scripts into a web form, just like Groovy scripts in ScriptRunner. What I learned from it was quite revealing and supports my initial suspicion.

Why organisations are leaving Jira Data Center

Atlassian calls the on-premises edition of Jira “Data Center”, and it is being phased out step by step. Since March 30, 2026, new customers can no longer buy it. From March 30, 2028, existing customers can no longer buy expansions, upgrades or new apps. On March 28, 2029, Data Center subscriptions and all Marketplace apps running on them expire and become read-only. (The Register)

Atlassian tells its Data Center customers to move to Atlassian Cloud. That leaves many organisations stranded. Some work in highly regulated industries such as finance, defense or the public sector, where somebody else’s cloud is not an option. Others simply want to keep full ownership of their data and avoid lock-in to a single vendor.

This is why organisations from all over the world approach us to migrate from Jira Data Center to OpenProject on-premises. Moving projects, issues, users and attachments from Jira to OpenProject is a pretty clear task. Migrating ScriptRunner is a different beast, and in many client conversations it comes up, sooner or later.

ScriptRunner is a toolbox, not a feature

Many organisations that use Jira also use ScriptRunner for Jira. It lets them change Jira’s standard behaviour to fit their specific use cases. These use cases can typically be divided into:

• Specific workflows, adapted to how a team or department really works.
• Integrations with the rest of the IT landscape, such as procurement or invoicing systems.

In both cases ScriptRunner allows developing a solution that works without running another system. ScriptRunner plugs into Jira via Jira’s plugin concept and extends its core functionality, so Jira can be “bent” to cover extended use cases and productivity optimisations.

There is no single ScriptRunner feature. It is a set of tools that extend Jira in many dimensions, for example:

• On-demand scripts: one-off runs from the script console, for example a bulk status update.
• Event-driven scripts: listeners that react to events, for example adding watchers when a ticket is created.
• Scheduled scripts: jobs that run at intervals, for example closing stale tickets.
• Workflow extensions: custom conditions, validators and post functions on transitions.
• Script fields: fields whose values are calculated by custom logic.
• UI modifications: behaviours that show, hide or require fields on forms, and script fragments that add UI elements.
• Search: Enhanced Search with extra JQL functions.
• Custom REST endpoints: interfaces for integrating external systems.

When migrating to OpenProject, we have to look at each of those dimensions individually. Some are already covered by OpenProject’s core, some are on our roadmap, and some are better solved in a different way.

This is true no matter where you migrate to. Even when migrating to Atlassian’s own cloud, the migration is not simple. On Data Center, scripts run inside Jira’s JVM with unrestricted access to Jira’s Java API. In Jira Cloud, scripts run outside Jira and talk to it through the REST API, with permission scopes and asynchronous webhooks instead of synchronous event handlers. There is no 1:1 porting. Every migration means rethinking your scripts, so it is worth asking which of them should exist as scripts at all.

The real cost of scripts

Scripts are powerful, but that power comes at a price. It shows in three areas: security, maintenance and day-to-day operations.

Security

ScriptRunner scripts have full access to the Java Virtual Machine (JVM) that Jira runs in, and consequently also to its database. Effectively, these scripts extend Jira with more code. In my opinion, administrators should treat that code as real software, because it can introduce security holes. That code needs to be developed, versioned, reviewed, and tested like any other code in production.

From a security standpoint, I would call ScriptRunner code injection by design. Code injection is a whole category of security bugs. Security researchers are paid well for finding ways to inject malicious code into web applications like Jira or OpenProject. ScriptRunner opens that door on purpose: anyone with the right admin permissions can run arbitrary code on a Jira server. I find that surprising for enterprise software, and I wonder how this passes security audits.

And sure, I understand the attractiveness of ScriptRunner. With one single plugin you can enable Jira Admins to develop and deploy solutions yourself, instead of contracting plugin developers. That allows for organizational shortcuts. The admin simply installs the ScriptRunner plugin and becomes independent from all other enterprisey software provisioning processes and protocols. It shortcuts the bureaucratic monster. Is that a good idea? I believe that this is a risky patch for an organizational problem.

Maintenance

With every major Jira release, administrators cannot be sure that their scripts will keep working. When internal APIs or data structures change, scripts must be adapted. This is not a ScriptRunner problem alone: any extension that hooks into the internals of a standard core product faces that challenge. It is a well-known problem of many plugin concepts.

This uncertainty slows down the rollout of new Jira versions, including security updates. After every update, administrators must make sure their scripts still work. In practice, this means running a development or staging environment just to test scripts, and postponing the upgrade until every script has been checked and occasionally adapted. This leads to clients desiring never changing internal APIs and long term support (LTS) for certain versions. Both are a killer for continuous product improvement. Let me ask you this: Is your iOS a LTS version or do you just auto-install every update? OpenProject tries to have the same quality on updates. You don’t need to worry before an update. However, once you have your own scripts, you will start worrying. That is not the direction that OpenProject wants you to move to.

The conclusion: script and plugin development has to be treated as proper software development, with continuous and automatic testing rather than a one-off check before each upgrade.

Operations

ScriptRunner looks lightweight on the first sight. It provides you with a Web form in which you write or paste Groovy code. On a second glance it provides you with all sorts of tools that are necessary for normal software development. For example ScriptRunner logs script runs to allow you to examine the script’s health. In other words it tries to replicate tools that software engineers already have.

And still, there is no sandbox around ScriptRunner on Jira Data Center: a bug in a single script can degrade or even take down the entire instance.

Every script needs the same care as any other software your organisation relies on: someone has to own it, document it, monitor it and fix it when it fails. When the person who wrote a script leaves the organisation, that knowledge often leaves with them.

As in normal software engineering you better have a 4-eyes principle implemented. Code reviews improve code maintenance and security. It also mitigates the “Truck factor”. However, for an efficient discussion on code you need the right tooling, like GitLab or GitHub. I don’t think that such tools belong into OpenProject.

The OpenProject approach: build it into the core

At OpenProject, we take a slightly different approach than Atlassian. When a use case makes sense for many customers, we build a feature for it directly into OpenProject. Ideally nobody needs to install a plugin or script. That is why our integrations with Nextcloud, XWiki and GitLab are built in and not shipped as plugins. We want OpenProject to work out of the box.

A feature in the core is tested with every release, documented and supported. Administrators don’t have to find, install, license and update it separately, and they don’t have to wonder whether it still works after the next upgrade.

For Jira to OpenProject migrations, this means: the ScriptRunner features that simply extend Jira’s core capabilities will be addressed directly in OpenProject’s core.

Where a gap remains, we close it in the core. A good example is ScriptRunner’s Enhanced Search. It extends JQL with functions like linkedIssuesOf, which select all issues that are related to the results of another query. We believe this use case makes a lot of sense, so we put it on the OpenProject development roadmap. Such powerful tool should not be hidden in a plugin.

When you need to go beyond what we foresaw

No matter how good our product research is, some organisations will need to adapt OpenProject to fit their needs. Maybe the UI needs to change, or data structures need to be extended. OpenProject cannot be optimised for every use case out there.

We don’t want organisations to fork and maintain an entire OpenProject just to change one feature. That is why, more than a decade ago, we made OpenProject extensible through a plugin concept. You then only maintain the plugin and its compatibility with OpenProject’s core.

Two things are important to know here:

• Internal APIs change. OpenProject ships new features every month. We prioritise delivering a better, richer product that liberates organisations over keeping internal APIs stable.
• The REST API stays stable. We take great care that integrations using it keep working. That makes the REST API, together with webhooks, the right foundation for connecting OpenProject to other systems in your IT landscape.

Plugin maintainers often ask us to integrate their plugins into the OpenProject core, and for good reason: it gives users and administrators the best experience, and it removes the burden of keeping the plugin in sync with every release.

Still not every plugin makes sense to be integrated into OpenProject. That is why we believe that the OpenProject team should provide simple solutions for you to monitor your plugins health. We are currently discussing how we could best provide you with CI/CD and Docker image building for your private plugins. If this is interesting to you, please reach out!

The experiment: pasting scripts into a Web form

Sometimes all it takes to change one’s beliefs is a real experience. I wanted to challenge myself and built as a prototype what I really did not want to include into OpenProject. I wanted to know what it would feel like to have ScriptRunner’s flexibility into OpenProject. What is the experience like to paste Ruby code into a simple Web form that completely changes OpenProject? With the help of an AI coding agent, I built an OpenProject plugin called “Scripts” that does exactly that. It lets administrators:

• Add Ruby scripts in OpenProject’s admin settings. The scripts run in OpenProject’s background workers or even within the current web request.
• Trigger scripts on selected events, such as the creation or update of a work package.
• Choose the projects in which a script is enabled.

The plugin is not meant for production use. Installing it is even dangerous, for exactly the security reasons described above. Still, it let us experience what this kind of flexibility feels like, both as a script author and as an administrator.

What we learned

1. Initially it is fun. The freedom to paste any Ruby code into it and change OpenProject just like that is addictive. Once you have it, it is psychologically challenging to give it away, similar to a good piece of chocolate.
2. It is hard to find use cases we would not rather build into OpenProject. Take risk management as an example. A script could calculate a “Risk level” field from two custom fields, “Severity” and “Likelihood”. But it makes much more sense to support risk management directly, with a dedicated UI and built-in datatypes.
3. Writing a script requires deep knowledge of OpenProject’s internals. You need to know the internal data model, the services and the events a script can hook into. A web form cannot provide sufficient hints to provide assistance to you as a script developer.
4. Scripting is real software development. I don’t want to lower my standards of software craftsmanship. I want IDE support with code completion, logging and a debugger. I want peer reviews. Shooting myself in the foot is very easy (yes, I did it), and a Web form is not the right place to avoid it.
5. I want AI support. Writing OpenProject scripts may not be my daily business, so I want help from my AI agent. That agent needs the OpenProject source code and, ideally, a full runtime to validate its results. With my IDE I have that. In a Web form, I do not. Often I am stuck, and I don’t know why a script simply does not work.
6. I want automated tests and CI/CD. If my script breaks with the next OpenProject release, I want to be notified automatically. I don’t like surprises, and I don’t want to postpone an OpenProject update just because I’m unsure whether my scripts still work. My extensions should be covered by automatically executable tests, just like the rest of OpenProject’s code. Actually I want the software tests to be developed while I develop my scripts. This experiment does not offer this. And I do not want to extend the experiment to also include software tests through a Web form.
7. I still want a staging environment that mirrors production, to test my scripts. I would not want to run a script on my production environment for the first time. This requires that I can quickly copy the same setup of scripts from one instance to another.
8. I want my scripts stored and versioned centrally, ideally in a Git repository, for example on GitLab. So, I would need to build some sort of syncing with a Git repository.

Our conclusion

1. Features that make general sense belong in the OpenProject core. Most of ScriptRunner’s tools simply extend Jira’s core, although they should have been part of it in the first place. For OpenProject, this means: if a feature makes general sense, it should be part of OpenProject, not a plugin that has to be added and managed separately.
2. Real feature modifications need real software development tools. When you truly need to change OpenProject’s behaviour, the change is too complex to simply type it into a Web form. Even experienced OpenProject developers would struggle and wish for better tooling. We believe we should instead make it easier to set up an environment for developing and maintaining plugins. Please let us know if you need help with that.
3. Scripts make maintenance too brittle for enterprise software. At OpenProject, we are proud that administrators can simply update and know the update will be fine. With scripts, that is no longer true. Quality assurance also gets harder, because the professional tooling is missing.

What this means for your migration

If you are planning to move from Jira Data Center to OpenProject, we suggest looking at your ScriptRunner scripts one by one:

1. Take inventory. ScriptRunner’s Registry lets you export all scripts as a ZIP file with the Groovy sources, their configuration and a summary CSV. Use it to find out which scripts are still active, who owns each one and whether it is still needed. Scripts nobody needs any more are the easiest to migrate.
2. Check the core first. Many use cases are covered by OpenProject’s workflows, custom fields, custom actions or queries. If something is missing but makes sense for many organisations, tell us, so it can land on our roadmap.
3. Use the REST API for integrations. Connections to procurement, invoicing or other systems belong on OpenProject’s stable REST API and webhooks, not inside OpenProject.
4. Check if OpenProject’s MCP server already covers your needs. It is 2026. OpenProject has a MCP server, Jira Data Center does not. Maybe you can solve your modifications differently in times of AI?
5. Build a proper plugin for the rest. If you really need to change OpenProject’s behaviour, develop a plugin with version control, tests, CI and a staging environment. We are happy to help you set that up.

We want to hear from you

These are our current thoughts, and we are looking forward to your opinion. Are you maintaining ScriptRunner scripts today? What would the ideal experience look like for you? And where are our blind spots? Please share your thoughts with the OpenProject open source Community on this work package.