Migrate from ScriptRunner for Jira Server to Cloud

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. 

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

  • Custom Script Field
  • Custom Script Listener
  • Custom Jobs
    • Escalation Services
  • JQL Functions
    • epicsOf
    • nextSprint
    • linkedIssuesOfRecursive
    • subtasksOf
    • previousSprint
    • parentsOf
    • dateCompare
    • expression
    • componentMatch
    • linkedIssuesOf
    • issueFieldMatch
    • issuesInEpics
    • linkedIssuesOfRecursiveLimited
    • issueFieldExactMatch
    • versionMatch
    • hasLinkType
    • hasComments
    • hasSubtasks
    • hasLinks
  • Workflow Functions
    • Custom Validator
    • Custom Condition
    • Custom Post Function
    • Post Function Add/Remove from Sprint 
    • Post Function Assign to Last Role Member
    • Post Function Clones an Issue and Links
    • Post Function Create a Sub-task
    • Post Function Fast-track Transition an Issue
    • Post Function Transition Parent When all Sub-tasks are Resolved
    • Post Function Send a Custom Email

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