Your ScriptRunner for Jira migration cheat sheet
This cheat sheet provides a high-level summary of how certain ScriptRunner for Jira 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
ScriptRunner DC uses Groovy scripting, but in Cloud you may need to use Typescript/Javascript and Jira expressions for some features.
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.
Jira Migration Cloud Assistant (JCMA) will migrate some ScriptRunner features to Cloud. Migrated scripts will be commented out as they will not automatically work on Cloud. Check which features are supported here, and note that Behaviours is not supported.
Things to keep in mind when writing Cloud scripts
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.
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.
You can not 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.
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.
You can use the Script Registry feature on ScriptRunner for Jira DC to export all ScriptRunner scripts from a DC instance, ready for analysis. The Script Registry will also provide useful metadata on scripts, such as projects the script is mapped to and when it was last run.
Try the AI-powered Jira expressions generator that can help you convert plain English into Jira expressions. It’s free to use and part of ScriptRunner’s Leap experiments.
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.
Listeners
- It's not possible to trigger scripts based on events from third-party apps.
- The number of event triggers is more limited than DC. Check what is available on Cloud here.
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.
Moderate-effort migration features
These features may be a little more difficult to migrate depending on the length and complexity of your scripts.
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.
Behaviours
- More limited on Cloud than DC.
- Jira Service Management is not supported.
- 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 can not 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 can not 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.
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.
