Script portability

Script portability

 

The Simple Issue Language (SIL), included with Power Scripts for Jira Cloud and Data Center, is designed to keep scripts portable across Jira environments. In most cases, you can move SIL scripts between Jira Data Center and Jira Cloud with little or no rewriting. This page explains what remains compatible, what changes during migration, and which platform differences can affect your scripts.

The Simple Issue Language (SIL) is mostly identical between Jira DC and Cloud.

Why SIL makes your scripts super portable

One of the main benefits of SIL is that scripts are portable across instances and hosting types. This is possible because the SIL language was created to run at a higher level than a general programming language. It works like a domain-specific language that simplifies the scripting process, reducing implementation complexity while maintaining scripting flexibility.

Benefits of SIL portability

We place a lot of importance on making sure your scripts can move from older versions of Jira to new ones without requiring any changes. That's why Power Scripts uses the simple JavaScript-like language SIL instead of Java-based scripting approaches that often require additional maintenance during upgrades. The benefits include:

  • Scripts written in older versions work in any future version.

  • You can migrate scripts from Server to DC to Cloud without rewriting.

  • No modifications are needed when upgrading Jira.


What differences to expect when migrating scripts

Function differences between Data Center and Cloud

Since the SIL language depends on the Jira API, differences between the Server/DC APIs and the Cloud APIs can subsequently impact the SIL functions. Even though most of the Atlassian APIs are similar between hosting types, there are occasional differences, as shown in the example below.

For example, when adding a comment on the on-prem version, you can set the visibility of that comment to a group or a project role. On the cloud, you can only use a project role.

Of the more than 700 Power Scripts functions available in cloud, approximately 0.4% differ from their Data Center equivalents.

Power Scripts DC functions that are not available in the cloud (yet)

Some DC Jira functions aren't available in the cloud because they're specific to the DC version. For instance, admin functions for complete reindexing of Jira aren't necessary in the cloud.

Other functions are not available for two reasons:

  • There are API limitations from Atlassian’s side.

  • The development of cloud functions is still in progress.

We’re constantly working on adding new functions to make Power Scripts even more powerful. We’ve added 200+ new functions, and there will soon be more cloud functions than DC functions.


What adjustments are required when migrating

Unfortunately, some changes will still be required as there are architectural differences between the DC version and the cloud version.

Configuration differences that can affect scripts

A minor difference comes from the differences between a Data Center instance and a Cloud instance, but could simply come from different instances running on the same platform. For example, differences on a development instance and a product instance, while both might be running on the Data Center there could be an impact to the scripts because they are separate instances. These are usually differences in configurations or settings.

Concrete names vs. aliases

If your script uses concrete configuration names instead of aliases, your script has to be updated. This applies to:

  • Custom field ID’s

  • Project names or keys

  • Status/priority names

  • Issue type names (or any other object that has a name)

Permission settings

In Power Scripts, each script runs as a user, inheriting that user's permissions. If permissions differ between Jira versions or hosting types, this may impact your script.

Differences that will impact your scripts

Issues arise when on-premises and cloud functionality in Jira is different, and scripts therefore become incompatible.

Conditions and Validators

When Jira Cloud was launched, custom conditions and validators didn’t exist. This is because they completely break the design of the cloud architecture. Performing an action in the cloud sets off a chain reaction of micro-services and events all at once, like knocking over multiple rows of dominoes. Conditions and validators require a pause in those events while they determine if the domino should fall over or if it is allowed to fall over. It doesn't work like that, so instead of being able to use scripted conditions and validators, Atlassian released the expressions language, which is the only available way to create custom conditions and validators.

This means that SIL scripts written for Data Center will either need to be rewritten using the expressions language, reimagined in ways that support the Cloud product, or removed completely.

JQL functions

Jira Cloud does have something that looks like the same JQL functions that were available in DC versions. However, they are not real functions. Real JQL functions are executed during the search and run to determine if an issue should be included in the results as part of the query. These results are pre-calculated in the cloud, and the JQL functions just query the result. That is why they are called JQL aliases in the cloud; they act like the function would have.

This means that scripts using classic JQL functions found on Jira DC will need to have the JQL function rewritten to accommodate the differences in Jira Cloud. Scripts that could be executed as part of a custom JQL search will need to be rewritten as custom JQL keyword (alias) scripts.

Live Fields

Atlassian recently introduced the ability to create functionality such as Live Fields. As they have released only a few APIs for a select set of custom fields, Live Fields in Cloud will not be as powerful as those on DC.

To reduce the number of changes:

  • Use SIL aliases: by using SIL aliases you avoid using the custom field ID directly in the script to protect your script from changes.

  • Clean up old projects prior to migration: make any necessary project changes in your familiar environment rather than dealing with them in the new and unfamiliar cloud setting.

  • Use migrations tools like CMJ: Did you know that Power Scripts is compatible with the Configuration Manager Cloud Migration Tool. Well, it is! Configuration Manager helps analyze and report changes, so that they can be resolved prior to the migration.

Need support? Create a request with our support team.

Copyright © 2005 - 2026 Appfire | All rights reserved.