Skip to main content
Home page

Your ScriptRunner for Jira migration cheat sheet

Illustration of a cloud and a server stack connected by a dotted pink path, with bright pink location pins at each end, representing migration from on-premise to the cloud.
This ScriptRunner for Jira migration cheat sheet provides a high-level summary of how certain features may translate from Data Center (DC) to Cloud, helping gauge the difficulty of your migration project. You'll also learn the key differences and limitations of Cloud that may be useful when performing migrations.

General FYIs

White arrow icon pointing right inside a teal circle
The ScriptRunner Migration Suite is a purpose-built toolkit to assist at every stage of your ScriptRunner for Jira migration.
White arrow icon pointing right inside a teal circle
ScriptRunner for Jira Data Center uses Groovy scripting, but in Cloud, you will need to use TypeScript/JavaScript and Jira expressions for some features.
White arrow icon pointing right inside a teal circle
In many cases, HAPI scripts can be directly copied and pasted from DC to Cloud and significantly simplify the migration process. If you need to write DC scripts pre-migration, it may be beneficial to write them in HAPI.
White arrow icon pointing right inside a teal circle
Jira Cloud Migration Assistant (JCMA) will migrate some ScriptRunner features to Cloud, but migrated scripts will be commented out as they will not automatically work on Cloud. Check which features JCMA supports here, and note that it does not support Behaviours.
Speedometer icon with pink needle pointing to the upper end of the gauge

Accelerate your ScriptRunner for Jira migration

The ScriptRunner Migration Suite helps simplify and speed up every step of your migration journey.

Things to keep in mind when writing Cloud scripts

Timer icon with a pink outline and teal ring around a pink centre
Timeouts are stricter on Cloud (each script execution is capped at 240 seconds). If you have long scripts, you may need to break the business logic down into multiple smaller scripts. Long-running tasks can also be run as Scheduled Jobs. Atlassian returns helpful information when these timeouts occur, such as 'Retry-After' or 'X-RateLimit-Reset' headers that can be used to pause scripts and retry.
Pink code block book with teal outlines above
Pagination is also enforced on Jira Cloud to ensure API responses are easier to handle, unlike DC, where you can return very large numbers of results at once. DC scripts that were written to return very large results will need to be modified to account for pagination.
Icon of a pink cog inside a teal shield
You cannot bypass authentication and permissions using scripts, and/or run scripts as any user. Cloud scripts can only be run by the logged-in user or as the ScriptRunner add-on user and will inherit the same permissions as those users.
Dark teal arrows curving in a circular formation
Script execution is asynchronous, so when a script runs, users might experience page loading before the script has fully executed. This is because tasks such as retrieving, updating, or creating issues; managing projects; and other administrative functions are executed through API calls.

Gauging the difficulty of a migration

What follows is a very general glimpse of how features and scripts may translate from DC to Cloud.
Remember: in-depth analysis of scripts is required for an accurate estimate, as exceptions are to be expected.
In ScriptRunner for Jira DC, you can use the Script Registry and the ScriptRunner Migration Suite to clean up and prioritise scripts before migration.
Use the Script Registry to export your DC scripts for review and upload them to the Analyse and Assess tool within SMS for an automated assessment of their Cloud-readiness.
Lightbulb icon

Low-effort migration features

These features are generally more straightforward to translate from DC to Cloud due to equivalent functionality across the two platforms. However, please be aware that there will always be exceptions.
Teal number one
Listeners
Jobs
  • It may be a challenge to migrate Jobs that are used to access a database.
  • Long-running Jobs (e.g. instance maintenance tasks) may need to be re-worked due to Cloud's maximum script execution time of 240s.
Workflow extensions (Validators, Conditions, and Post-functions)
  • Conditions and Validators use Jira expressions.
  • Post-functions can be written with Groovy.
Two overlapping speech bubble icons, one pink and one teal, with a yellow spark on the upper bubble

Jira Expressions generator

Want some help writing Jira expressions? This AI-powered generator helps you convert plain English into production-ready Jira expressions, skipping complex syntax to speed up your automation work. This free tool is handy for extending workflow functions and listeners in ScriptRunner for Jira Cloud.

Moderate-effort migration features

These features may be a little more difficult to migrate depending on the length and complexity of your scripts.
Orange number two
Script Fields
  • Script Fields used for custom or Database pickers may be a challenge to migrate.
  • HTML formatting is not supported on Cloud.
  • Fields that return single values should be straightforward to migrate.

High-effort migration features

These features are more limited on Cloud or do not have equivalent functionality, so it may be more challenging to translate use cases over.
Pink number three
Behaviours
  • More limited on Cloud than DC.
  • Behaviours for Assets is not supported.
  • Modifying field properties (read-only, hidden, and/or required, description, helpText, manage Options) is limited for some field types and system fields.
  • Limited by user permissions. For example, a non-admin cannot access and retrieve lists of options for Select List fields, which means option IDs need to be gathered manually. This limitation affects all Jira Cloud endpoints that only allow access to users with admin permissions. Behaviours scripts to be executed by non-admin users should be written with this in mind.
  • See Behaviours limitations and Behaviours supported fields and products for further details.
  • Written in TypeScript/JavaScript.
Fragments
  • Functionality is more limited on Cloud.
  • Written in TypeScript/JavaScript.
  • Forge custom development can be used to recreate functionality.
JQL Functions
  • On Cloud, you cannot currently hardcode JQL queries/functions into your script like on DC*. Instead, they need to be saved as filters in Enhanced Search and called via a REST endpoint.
    *A new feature update will soon make this possible.
Custom REST Endpoints
  • Not supported on Cloud.
  • Depending on the use case, ScriptRunner Connect or custom Forge development may be used to recreate functionality.
Resources
  • Not supported on Cloud.
  • Forge can be used to recreate functionality.