Moving from ScriptRunner for Jira Cloud
Moving from ScriptRunner for Jira Cloud to Oktul Code Studio: where each kind of script goes, how Groovy becomes TypeScript, and what has no equivalent.
Install Code Studio beside ScriptRunner, import your Groovy scripts, let the Rovo translator convert them to TypeScript, and publish each one after its sandbox run. Both apps run side by side. You move one script at a time and switch the ScriptRunner one off when its replacement is live.
What changes
From the comparison, checked on 21.10.2026 against the published documentation of ScriptRunner for Jira (opens in a new tab) by Adaptavist:
- JavaScript and TypeScript instead of Groovy, with completion for the script API in the editor. Scripts
- A sandbox that lists the changes. A test run reads the site and records every write instead of sending it. Sandbox and production
- Jira and Confluence in one app. ScriptRunner sells Confluence as a separate app. Install
- Scripts stay inside Atlassian. Scripts, runs and logs are kept in your site’s Forge storage. Privacy
- Rovo agents write, convert, debug and edit scripts. Rovo agents
Where each kind of script goes
| In ScriptRunner for Jira Cloud | In Code Studio |
|---|---|
| Script Console | The console’s run button, in the sandbox or in production: Sandbox and production |
| Script Listeners | Listeners on Jira and Confluence events: Triggers |
| Scheduled Jobs | Schedules: Triggers |
| Escalation Services | A schedule whose script runs the JQL search and acts on what it finds: Triggers |
| Script Fields | Scripted fields: Fields and forms |
| Behaviours | Dynamic forms: Fields and forms |
| Script variables | Variables, with secrets kept out of logs: Connections and variables |
| HAPI | The REST call each HAPI call makes, through jira. HAPI is not recreated: Groovy migration |
No equivalent: Code Studio has no workflow conditions, validators or post functions, and no JQL functions of its own. Work a post function did after a transition can run from a listener on work item updated.
Two more ways to start a script: a Jira automation rule, or an HTTP request to an API trigger.
Move in five steps
- Install Code Studio
Choose the listing for the product you script most, as in Install the app. ScriptRunner stays installed until the last script has moved.
- Import the Groovy scripts
Into a space, where they are kept read-only beside their conversions. Groovy migration has the details.
- Convert them with the translator
The draft is checked and run in the sandbox, and the translator reports what it could not convert.
- Attach its trigger and publish
Give the script the listener, schedule, field or form it had in ScriptRunner, then an administrator publishes it.
- Switch the ScriptRunner script off
Once the Code Studio run log shows the published script doing the same work. Two scripts acting on one event both act.
A ScriptRunner script runs as ScriptRunner’s app user. A Code Studio listener runs as the app or as the person who caused the event, as you set it, and their field and space permissions can differ. Check a converted listener in the sandbox as the account it will run as: Whom a run acts as.
Common questions
- Can ScriptRunner and Code Studio run side by side?
- Yes. They are separate apps. Move one script at a time, and switch the ScriptRunner one off once its replacement is published.
- Do I rewrite my Groovy scripts by hand?
- No. The Rovo translator converts each to TypeScript as a draft. A person reads it, runs it in the sandbox and publishes it.
- Does Code Studio have workflow conditions, validators or post functions?
- No. Work a post function did after a transition can run from a listener on work item updated.
Related
A problem or a question? Write to support@oktul.com or open a request in the Help Center (opens in a new tab).