Migrate from ScriptRunner for Jira Server to Cloud

Please note that to migrate from ScriptRunner for Jira Server to Cloud, you will likely need to update (or have updated) your Server or DC version. Currently, users who are moving from ScriptRunner for Jira Server/DC to Cloud need to be on version 6.47.0 or above.

There are two ways to migrate from ScriptRunner for Jira Server/DC to Cloud: manually, or using the Atlassian Cloud Migration Assistant.

When migrating an instance with ScriptRunner from Server to Cloud, we recommend you use Atlassian's Cloud Migration Assistant.

Be aware that any migration from Server to Cloud (manual or through the Cloud Migration Assistant) will require rewriting scripts.

Whether you are using the assistant, or manually migrating, you must follow these steps:

  1. Analyse the purpose/functionality of your existing scripts. We suggest you clean up your instance as much as possible before migrating. Navigate through each ScriptRunner feature tab, for example, listeners, to see a list of all listeners configured on your instance.
  2. If you are migrating manually, check for feature parity in Cloud and analyse the API.  Each script you want to migrate should be analyzed to determine if the functionality is desired and possible within the Cloud feature set.

    If you are using the Atlassian Cloud Migration Assistant this is done for you. 

  3. If there is no feature parity, we suggest you analyse the value parity:
    • What is the script doing?
    • Is it required in Cloud?
    • Is there a similar Cloud feature that could cover the requirement (see the feature parity table for possible workarounds)? 

    Need help with this step? Speak to our team of consultants. Or if you want to suggest a feature for ScriptRunner for Jira Cloud, please send an enhancement request

  4. Once you have identified the ScriptRunner configs you want to migrate, write out the script in pseudo code making the intention clear.

  5. Depending on whether or not you are using the assistant, the following will apply:
    If it is the case that you are using the assistant, the configurations for the following features are recreated on Cloud (for a full list see Features Supported by Jira Cloud Migration Assistant below):

    • Custom Script Field
    • Custom Script Listener
    • Custom Jobs
    • JQL Functions
    • Custom Workflow Functions (and specific Post Functions see below)

    The code will be "migrated" but commented out, and features deactivated. Compatible filters containing JQL functions will be automatically re-created in Enhanced Search. Incompatible filters will not be converted. All script configurations for other ScriptRunner features will need to be recreated manually. 

    Once any of the following items are migrated, subsequent migrations will not overwrite that migration.

    • Custom Script Field
    • Custom Script Listener
    • Custom Jobs

    This means that if you want to re-migrate these from Server again then you will need to delete them from the Cloud instance beforehand.

    The Enhanced Search version of dateCompare function requires a valid JQL query in the first parameter. dateCompare will be automatically migrated into an ES filter when all parameters are provided. If there is a mismatch between the names in the Cloud/Server issue fields referenced in any parameter of the function i.e. in the case of custom fields, then the migration will not automatically create an ES filter and it will need to be created manually in ES.

    OR 
    If it is the case that you are not using the assistant, you'll need to recreate all your script configurations manually.

  6. Rewrite the new relevant script configurations using ScriptRunner for Jira Cloud. Interactions with the API need to be replaced with calls to the appropriate REST APIs and it is possible that alternatives may need to be found for dependencies that are not available for ScriptRunner Cloud. Check the Platform Differences documentation for more information. 

    Need help with this step? Speak to our team of consultants. Or if you want to suggest a feature for ScriptRunner for Jira Cloud, please send an enhancement request

Features Supported by Jira Cloud Migration Assistant

The following features are migrated from Jira Server to Jira Cloud when using the Jira Cloud Migration Assistant:

  • Custom Script Field
  • Custom Script Listener
  • Custom Jobs
    • Escalation Services
  • JQL Functions
    • epicsOf
    • nextSprint
    • linkedIssuesOfRecursive
    • subtasksOf
    • previousSprint
    • parentsOf
    • dateCompare
    • componentMatch
    • linkedIssuesOf
    • issueFieldMatch
    • issuesInEpics
    • linkedIssuesOfRecursiveLimited
    • issueFieldExactMatch
    • versionMatch
    • hasLinkType
    • hasComments
    • hasSubtasks
    • hasLinks
  • Workflow Functions

The table below outlines the differences in between the Server and Cloud function names and provides guidance on how these fields may be mapped together when migrating Workflow functions. 

You should note the following points when using the JCMA:

  • If you have already migrated a project with JCMA and want to re-migrate it again, then you must delete the project and associated workflows/workflow scheme in order for the workflow rules to be migrated. Jira does not delete these when a project is deleted.
  • Any scripts commented out, due to the fact that the APIs are different between Server and Cloud, will need to be rewritten.

  • Conditions and Validators use the Jira Expression language.
  • Built-in script conditions or validators migrated from Jira Server/Data Centre are not supported and will display in ScriptRunner for Jira Cloud as blank validators or conditions. Therefore, once the migration is performed, these will need to be deleted.

Server Function Name:

Cloud Function Name:

Incompatible Fields that should be discarded:

Add/remove from sprint [ScriptRunner]

Add/remove from sprint

  • Return user to Execute As - In Cloud, users can run as the Add-on or initiating user only and cannot choose a specific user to run the post function.

Assign to first member of role [ScriptRunner]

Assign Issue

  • Include Reporter

  • Include Assignee

  • Force Assignee

Clones an issue, and links [ScriptRunner]

Clone Issue

  • Fields to copy

  • Copy Comments

  • Copy Subtasks

  • As User - In Cloud, users can run as the Add-on or initiating user only and cannot choose a specific user to run the post function.

Create a sub-task [ScriptRunner]

Create Subtask

  • Fields to copy

  • As User - In Cloud, users can run as the Add-on or initiating user only and cannot choose a specific user to run the post function.

Fast-track transition an issue [ScriptRunner]

Fast-track transition issue

  • Transition Options

Transition parent when all subtasks are resolved [ScriptRunner]

Transition Parent Issue

  • No incompatible fields.

Custom script post-function [ScriptRunner]

Run Script

  • No incompatible fields.

Custom script validator [ScriptRunner]

ScriptRunner Script Validator

  • Test Against - Used for testing scripts when creating or editing validators only, so can be safely discarded.

Custom script condition [ScriptRunner]

ScriptRunner Script Condition

  • Test Against - Used for testing scripts when creating or editing validators only, so can be safely discarded.

It's worth noting that any fields that could not be mapped, such as, when an item is referenced by ID, will be mentioned in a comment within the Conditions box of the workflow rule.

Once migrated, these features are deactivated so you can make them Cloud compatible before reactivating.