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.

You can migrate from ScriptRunner for Jira Server/DC to Cloud either:

We recommend you use the Cloud Migration Assistant when migrating an instance with ScriptRunner from Server to Cloud.

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

Migration Process

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. Check for feature parity in Cloud and analyse the API if you are migrating manually. 
    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 information applies:
    Option A: Using Atlassian Cloud Migration Assistant
     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 will be deactivated. Compatible filters containing JQL functions will be automatically re-created in Enhanced Search. Incompatible filters will not be converted. You can check the migration report in ScriptRunner for Jira Cloud to find the details of any problems during filter migration. 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, 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
    Option B: Not using the assistant

    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 .Migrate from ScriptRunner for Jira Server to Cloud v7.3.0 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 Atlassian Cloud Migration Assistant:

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

The table below outlines the differences 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 Atlassian Cloud Migration Assistant:

  • If you have already migrated a project with the assistant 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.

Jira Server and Cloud Function Name Differences

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 Asignee

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 validatiors only, so can be safely discarded.

Custom script condition [ScriptRunner]

ScriptRunner Script Condiion

  • Test Against - Used for testing scripts when creating or editing validatiors 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.



On this page