Heads up! ScriptRunner documentation is moving to docs.adaptavist.com. Adaptavist will keep this site up for a bit, but no future updates to documentation will be published here. ScriptRunner 6.20.0 will be the last release to link to scriptrunner.adaptavist.com for in-app help.

This page is for users who want to move from Jira Server to Jira Cloud and want to maintain ScriptRunner functionality.

Platform Differences

Due to the differences in programming model and API, there is currently no automatic migration between Server and Cloud. The process of migration involves analysing the desired functionality and translating that into the target platform. Jira Cloud uses the Atlassian Connect framework to allow add-ons like ScriptRunner to provide additional functionality whereas Jira Server (and Data Center) uses the Atlassian Plugins framework, known as Plugins v2 or P2.

There are fundamental differences between Connect and P2 that directly impact ScriptRunner functionality and script writing. Some of the differences are:

Table 1. Platform Differences
P2 Connect


Java API - it is possible to call almost any of the Host application code directly. Plugins are running in the same JVM as the host application.

REST APIs are available to interact with the host application. Connect has access to a limited set of REST APIs as defined by the Product API Scopes, this means that Connect add-ons can only do things officially supported by the APIs, but it also means that APIs are less likely to change and add-ons are less likely to break as a result.


Any part of the UI can be customised. Javascript runs as on the page in the same context and frame as the host application. Host application code can be manipulated and broken by add-ons and add-on code can easily be broken by host code (or its dependent libraries) updates.

Specific areas can be cusomised. Each add-on runs in its own iframe and Javascript Sandbox. Interaction with the host page is via a Javascript API.

Programming Model

In the same JVM as the host application. Events can be vetoed and code runs synchronously. A bug in add-on code can seriously affect application stability or performance.

Asynchronous. Runs as a completely separate service. No code runs in the same JVM as the host. Events are processed as webhooks that fired from the host and processed asynchronously by the add-on - no waiting for events to be processed. A failing add-on does not impact the performance of an Atlassian application (although functionality may be missing).

Authentication and Authorisation

Code can run as any user in the system including as no user (which is not the same as Anonymous). Authentication and authorisation can be bypassed.

Add-ons make requests as the add-on user or the user that initiated the interaction. It is not possible to bypass authorisation or authentication

In summary there are significant differences between the Connect and P2 frameworks and it is necessary to re-think how ScriptRunner scripts execute and interact with the host application when moving from Server to Cloud. The asynchronous nature of Connect has implications with regards to host interaction, for example in Jira it is not possible to implement event listeners that prevent event processing. Similarly when writing ScriptRunner scripts for server hosts it is important to consider the impact that scripts will have, particularly when interacting with external systems that might be slow. As with most programming situations there are trade offs when writing scripts for both Cloud and Server and the limitations of Cloud are at the expense of stability and performance of the Atlassian application.

Have questions? Visit the Atlassian Community to connect, share, and learn with other Atlassian users and experts, including Adaptavist staff.

Ask a question about ScriptRunner for JIRA, Bitbucket Server, or Confluence.

Want to learn more? Check out courses on Adaptavist Learn, an online platform to onboard and train new users for Atlassian solutions.