Migrate to Isolated Cloud using JCMA

Find out what JCMA migrates from ScriptRunner Data Center, the version prerequisites, and how to convert migrated Groovy scripts to TypeScript afterwards.

You can migrate from ScriptRunner for Jira Data Center to ScriptRunner for Jira Isolated Cloud using the Jira Cloud Migration Assistant (JCMA). This can be part of your normal migration journey from Data Center to Isolated Cloud.

Note: ScriptRunner for Jira Isolated Cloud is built on Forge. Even though JCMA copies your existing Groovy scripts across, they will not run in the Isolated Cloud environment. All migrated scripts must be converted to TypeScript before they can be activated. See Post-migration steps for details.

Prerequisites

Before starting your migration, ensure the following are in place:

ScriptRunner for Jira Isolated Cloud is installed on your Isolated Cloud instance.
You are running ScriptRunner for Jira Data Center version 9.32.0, or 10.18.0, and above on your source instance. Migration to Isolated Cloud is not supported on ScriptRunner Data Center versions 8.x or earlier 9.x releases.
You have backed up your Data Center environment, including all scripts and configurations.
You have reviewed your existing scripts and have a plan for converting them to TypeScript.

How the migration works

When you run a migration using JCMA, ScriptRunner participates automatically; there is no separate ScriptRunner-specific migration step. JCMA copies supported ScriptRunner configurations from your Data Center instance to your Isolated Cloud instance.

Nothing you migrate does its old job until you rewrite it. A custom script arrives with your Groovy code commented out and a TODO note in its place. A supported built-in script arrives with a placeholder written by Data Center, describing what the built-in used to do.

Whether a migrated item is switched on depends on what it is:

Scheduled jobs and escalation services always arrive disabled.
Listeners and behaviours keep the enabled or disabled state they had in Data Center.
Workflow post functions, validators, and conditions are enabled on their transitions.

Warning: Check your migrated workflow conditions before anyone uses the workflow. A Data Center condition is not migrated as a script. It becomes a Jira expression that keeps your original Groovy as comments without reproducing it, and it is enabled on the transition. Until you rewrite it, the condition does not restrict the transition the way it did in Data Center.

Every migrated configuration is labelled migrated-from-dc, so you can filter any feature's list to see just what arrived. Built-in workflow functions are also labelled builtin-script.

For full instructions on running a migration with JCMA, follow Atlassian's JCMA migration guide.

What is migrated

The following ScriptRunner configurations are automatically migrated with JCMA:


Feature	Migrated with JCMA	Notes
Custom script listeners	✅ Yes	Code commented out. Keeps its Data Center enabled or disabled state. Events and project filters are migrated where a Cloud equivalent exists; anything without one is listed in the script comments.
Custom script fields	✅ Yes	Code commented out.
Custom script workflow post functions	✅ Yes	Code commented out. Enabled on the transition.
Custom script workflow validators	✅ Yes	Code commented out. Enabled on the transition.
Custom script workflow conditions	✅ Yes	Migrated as a Jira expression, not a script. Your original Groovy is kept as comments and the expression itself is a placeholder, so the condition does not reproduce your Data Center logic until you rewrite it.
Behaviours	✅ Yes	Behaviour structure and mappings are migrated, including Jira Service Management service desks and request types. Code commented out. Keeps its Data Center enabled or disabled state. A behaviour mapped to all service desks or all request types is not applied and must be set up again by hand.
Scheduled jobs	✅ Yes	Code commented out. Always arrives disabled. The Data Center schedule is converted to a cron expression where possible, and the job tells you when it could not be.
Escalation services	✅ Yes	Migrated as scheduled jobs, handled the same way.
Built-in workflow post functions	⚠️ Some	Some arrive with a placeholder written by Data Center, describing what the built-in used to do, for you to rewrite. Coverage is being added gradually, so check each one after migrating.

What is not migrated

The following ScriptRunner features and configurations are not migrated by JCMA and will need to be recreated manually, or may not have an equivalent in ScriptRunner for Jira Isolated Cloud:

Built-in scripts (non-custom scripted features), apart from the workflow post functions noted in the What is migrated table above
Picker fields (e.g. User Picker, Issue Picker)
Simple scripted conditions (built-in, non-custom)
Simple scripted validators (built-in, non-custom)
Script fragments and REST endpoints
Any other ScriptRunner feature not listed in the What is migrated table above

Post-migration steps

After JCMA completes the migration, you will need to manually convert and activate your scripts. Because ScriptRunner for Jira Isolated Cloud runs on Forge, all scripts must be written in TypeScript as Groovy is not supported.

Tip: Terminology updates

Atlassian has updated its workflow terminology as part of the new workflow editor experience. Some names and concepts may differ from what you're used to in the classic editor. For a detailed description of the changes, refer to Atlassian's official workflow documentation.

Review what was migratedwhat was migrated. JCMA's own migration report tells you whether the transfer succeeded. To see what arrived, open each feature in ScriptRunner for Jira Isolated Cloud: event listeners, scripted fields, workflow actions, workflow validators, field behaviours, and scheduled jobs.
Every migrated configuration is labelled migrated-from-dc, so you can filter any feature's list to see just what arrived. Built-in workflow functions are also labelled builtin-script.
Conditions are the exception. They are set directly on the workflow transition rather than saved as a configuration in ScriptRunner, so they appear in no list and carry no label. Open the workflow in Jira to find them.
Each migrated item has a description that begins "Migrated from DC", along with any notes from Data Center. Anything that could not be carried across, such as an event or a project with no Cloud equivalent, is recorded in the comments at the top of the script.
Check what is switched on. Not everything arrives deactivated.
- Scheduled jobs and escalation services always arrive disabled.
- Listeners and behaviours keep the enabled or disabled state they had in Data Center, so anything that was running in Data Center is running now, with no logic in it.
- Workflow post functions, validators, and conditions are enabled on their transitions.
Disable anything you are not ready to work on, so that a half-migrated item cannot affect your users.
Convert your scripts to TypeScript. What a migrated script contains depends on what it was in Data Center. In each one, replace the comment with TypeScript that does the same job, using HAPI or Jira's REST API.
- A custom script arrives with your original Groovy commented out, above an empty function.
- A built-in script that is supported arrives with a placeholder written by Data Center, describing what the built-in used to do, in place of the Groovy.
Rewrite your migrated workflow conditions. A Data Center condition is migrated as a Jira expression rather than a script, so it needs a Jira expression rather than TypeScript. You edit it on the transition, in the Jira workflow editor.
Warning: A migrated condition keeps your original Groovy as comments without reproducing it, and it is enabled on the transition. Until you rewrite it, it does not restrict the transition the way it did in Data Center.
Activate your scripts once they have been converted and tested.
Recreate non-migrated configurations manually, including built-in features and the other items listed in What is not migrated.
Test thoroughly in a staging environment before going live. Verify:
- Listeners fire as expected
- Script fields return correct values
- Workflow post functions, conditions, and validators behave correctly
- Behaviours apply to the correct spaces and work types
- Scheduled jobs run on the schedule you expect

Note: Re-migrating

ScriptRunner remembers what it has already migrated for 7 days. Within that window, running JCMA again skips anything it migrated before rather than overwriting it. If you need to re-migrate an item, delete it from the Isolated Cloud instance first.

After 7 days that record expires, and running JCMA again creates a second copy of everything instead of skipping it.

Resources

Jira Cloud Migration Assistant (JCMA)
Atlassian JCMA migration guide: Step-by-step JCMA instructions.
ScriptRunner Migration Suite: A suite of tools designed to help you migrate from ScriptRunner for Jira Data Center to ScriptRunner for Jira Cloud. While not specifically built for this Isolated Cloud ScriptRunner product, the tools can still be useful during your migration journey:
- Migration Analyse and Assess Tool: Review your Data Center scripts for cloud readiness and identify potential issues before migration.
- ScriptRunner Migration Agent: AI-powered assistant for converting and optimising scripts. Note that script conversion suggestions will target ScriptRunner for Jira Cloud (Groovy), not TypeScript for Isolated Cloud.