Migration method

If a tool such as the Jira Cloud Migration Assistant (JCMA) or the Configuration Manager for Jira (CMJ) is used to migrate from Data Center to Jira Cloud we can assume a number of things that will make the migration more successful:

• Project and issue type names will be identical between DC and cloud - this will ensure that project keys or issue types names used directly in scripts will continue to operate after migration

• Custom field names will be identical - Custom field id’s will definitely not be identical. However, if SIL aliases were used (a best practice) then by updating the SIL aliases settings in cloud the scripts will automatically work with the new id’s. If custom field aliases were not used then this migration is a good opportunity to convert to using them.

• Status and transition names (etc.) will be identical - this will ensure that any scripts using status names, transition names or id’s should continue to operate after the migration

Post migration testing

If a script passes the syntax check from the SIL Manager it means the following:

• The functions used in the code are compatible between DC and cloud

• The syntax of the script it correct

• Custom field id’s are correct or have been updated in the alias file

What it does not mean:

• That the script will operate exactly the same between DC and cloud

Which scripts will migrate from DC to Cloud

Scripts that will need changes when migrating

Conditions and validator scripts

Conditions and validators are written using a language/syntax called Jira Expressions in the cloud. All truly scripted conditions and validators are not supported in Cloud at this time. Many people find using Jira Expressions to be difficult and time consuming. Like other features in Cloud, the solution may be to look at the problem in a slightly different way and to tweak the solution. See this article for a solution to continue using SIL scripted conditions and validators in Jira Cloud.

issue.issueType.name.match('^(Dev Task)$') == null || 
(issue.issueType.name.match('^(Dev Task)$') != null && 
issue.parent.subtasks.filter(subtask => subtask.assignee != null).length == 
issue.parent.subtasks.length)? true : false

//SIL code
boolean passConditionValue = true;
if(issueType == "Dev Task") {
    for(string s in subtasks(parent)) {
        if(s.issueType == "Dev Task && isNull(s.assignee)) {
            passConditionValue = false;
        }
    }
}
setIssueEntityPropertyValue(key, "passCondition", passConditionValue);

//Jira Expression
JSON.stringify(issue.properties['passCondition']).includes('true')

Live Fields scripts

In Data Center, Live Fields is a just collection of functions within Power Scripts that are used to manipulate issue screens and the UI. In Jira Cloud, Live Fields was built as separate app for architectural reasons. This new Live Fields app does not use the SIL language, instead it uses JavaScript or TypeScript. When writing scripts for Live Fields for Jira Cloud an API written by Atlassian must be used. For this reason all Live Fields scripts will need to be converted from SIL to JavaScript.

For example:

//SIL (Data Center)
lfSet("summary", "Value to set");

//JavaScript (Cloud)
getFieldById("summary").setValue("Value to set");

Mail handler scripts

It is important to note that the incoming email service that is available in Power Scripts for Jira Cloud is different from Data Center in that it does not intercept emails coming in on the main “…@atlassian.net” email address. This is because it is currently not possible to intercept those emails as Atlassian has not made it possible to do so. In Jira Cloud, email scripts can only intercept emails going to a separate email account like a Gmail account for example.

It is due to this difference above that different functions were needed between Data Center and Cloud for incoming email scripts. These scripts will need to be modified to use the new functions.

IncomingEmail mail = getIncomingEmail();
string issueKey = matchText(mail.subject, "[A-Z][A-Z]+-[0-9]+"); // find an issue key in the subject
if(isNull(issueKey)) {
	// if no issue key found, create a new issue
    string [] fields = {};
    fields += {"reporter", currentUserKey()};
    fields += {"assignee", getUserByEmail(mail.cc[0]).key}; 
    string newIssue = createIssue("TEST", "", "Task", mail.subject, "Minor", mail.body, {}, "", "", 0, fields);
    attachAllFilesFromEmail(newIssue);
    %newIssue%.watchers = getUserKeysFromEmails(mail.cc); 
} else {
	// if issue key found in subject, add a comment
    addComment(issueKey, currentUserKey(), mail.body);
}

IncomingEmail mail = getIncomingEmail();
string issueKey = mail.subject;
if(issueExists(issueKey)) {
    // add comment
    string commentText = mail.body;
    string userCommenting = getUserByEmail(mail.from).key;
    addComment(issueKey, userCommenting, commentText);
    attachAllFilesFromEmail(issueKey);
} else {
    // create issue
    string summary = mail.subject;
    string description = mail.body;
    string [] fields = {};
    fields += {"reporter", getUserByEmail(mail.from).key};
    createIssue("SCRUM", "", "Task", summary , "Minor", description, {}, "", "", fields);
}

Scripted JQL functions/keywords

With scripted JQL functions/keywords there is a large paradigm shift between Data Center and cloud that has to do with Jira directly and is not caused by Power Scripts.

• In Data Center, scripted functions are executed when the search is executed. The SIL script performs its own, separate JQL search for each issue with the script determining if the issue should be included in the search results as each issue is evaluated one-by-one

• In Cloud, scripted functions are executed in advanced of the search and the result of the script is stored with the issue. The JQL search uses these precalculated results to determine if the issue should be returned with the search results.

This will change the construction of the script JQL function/keyword in the following ways:

• Scripts will not contain their own JQL search in the script

• The return statement of the cloud scripts uses additional operations when compared to DC

• JQL scripts in cloud can update the search values of parent and child issues as well as their own

For these reasons script JQL functions/keywords will need to be updated to use the new methods in cloud.

Script Migration Process/Strategy

Useful scripts, tips and tricks

for(JFilter f in admGetAllFilters()) {
    string oldFunction = "hasLinkType";
    
    if(contains(f.jql, oldFunction)) {
        runnerLog("Filter \"" + f.name + "\" [" + f.id + "] owned by " + userFullName(f.owner) + " <strong style=\"color:red;\">contains</strong> the function for removal: <strong>" + oldFunction + "</strong>", true);
    } else {
        runnerLog("Filter \"" + f.name + "\" [" + f.id + "] owned by " + userFullName(f.owner) + " <strong style=\"color:green;\">does not contain</strong> the function for removal: <strong>" + oldFunction + "</strong>", true);
    }
}

//Starting JQL format:
issueFunction in FUNCTION_NAME("PARAMETER") and ADDITIONAL_CONDITIONS

//Changes to:
FUNCTION_NAME = "PARAMETER" and ADDITIONAL_CONDITIONS

//starting JQL format
issueFunction in hasLinkType("Blockers") and resolution is empty

//would be changed to:
hasLinkType = "Blockers" and resolution is empty

for(JFilter f in admGetAllFilters()) {
    string oldFunction = "hasLinkType";
    string newFunction = "hasLinkType";
    
    if(contains(f.jql, oldFunction)) {
        string jql = f.jql;    
        string [] pieces = split(f.jql, oldFunction);
        
        jql = replace(pieces[0], "issueFunction in ", "") + newFunction;
        
        pieces[1] = replace(pieces[1], "(", " = ");
        pieces[1] = replace(pieces[1], ")", "");
        
        jql += pieces[1];
        f.jql = jql;
        
        admUpdateFilter(f);
        runnerLog("Filter \"" + f.name + "\" [" + f.id + "] owned by " + userFullName(f.owner) + " has been updated to use the new syntax for function: <strong>" + oldFunction + "</strong>", true);
    }
}