What happens to your ScriptRunner scripts when you move to Cloud

What customers usually expect

Most customers know their scripts will need some work before a Cloud move. They expect a rewrite, and they expect it to be one of the harder parts of the migration. That part is accurate.

What they usually expect less is how different the end result can look. The common assumption is that each script moves from A to B, still in ScriptRunner, doing roughly the same thing. Many don't realize that a good share of their scripts can be replaced with native Jira features, Automation, or a simple Forge app. And few stop to ask whether they still need each script at all.

Why scripts don't move as they are

Cloud is a different platform, and scripts feel that difference more than almost anything else in a migration.

Different APIs

On Data Center, scripts can reach deep into the application. On Cloud, they work through Atlassian's APIs. Logic that relied on that deeper access has to be rebuilt, and some of it cannot be rebuilt the same way.

Time limits

Cloud puts limits on how long a script can run. Scripts that looped through large sets of work items, or waited on slow outside systems, can hit those limits and fail. They need a different design, not just a translation.

Features that behave differently

Some ScriptRunner features look and work differently in Cloud. Behaviours are the one we run into most, and they have more limitations there. Scripted fields can also render more slowly, which users notice right away. Teams should expect some things to look and feel different after the move.

How we sort the scripts

We don't start by translating code. We start by understanding what each script is for.

1. Inventory every script. Listeners, workflow functions, scripted fields, Behaviours, scheduled jobs, and anything else running on the instance.
2. Check real usage. Some scripts run constantly. Some haven't done anything useful in a long time.
3. Read the code. We follow the logic line by line to learn what the script actually does, not what its name suggests.
4. Flag outside connections. Scripts that reach third-party systems need extra care, because they carry both integration and access concerns.
5. Check native options. Many workflow conditions, validators, and listeners can now be handled by Jira itself or by Automation.
6. Define the end state. For each script, we decide what the ideal Cloud version looks like and where it should live.

Each script lands in one of a few places:

• Native Jira, when a built-in feature now does the job.
• Automation, for rules and listeners that fit a trigger, condition, and action pattern.
• A Forge app, when the logic is custom but simple enough to build and maintain as a small app.
• ScriptRunner Cloud, when the logic is complex and scripting is still the right tool.
• Retired, when nobody uses it or the process it supported no longer exists.

The decisions the customer had to make

Sorting scripts is the technical part. Deciding what matters is the business part, and only the customer can do it.

• What is absolutely critical and has to work on day one?
• What can be transformed into native features or Automation?
• What needs a real refactor, and is it worth the effort?
• What can simply go away?

Teams should expect this to be real work. Years of Data Center use tend to leave a lot of scripts behind, and working through them takes time.

Nobody owned the scripts

The bigger problem was not the code. It was that nobody clearly owned it. Scripts had built up over years, and many were written by people who had since been offboarded. The scripts kept running, but the knowledge of what they did had left with their authors. There was no current record of what each script did, what it touched, or why it existed. Over time, scripting had become ungoverned.

So we reset from the beginning. For every script that moved forward, the customer needed three answers:

1. Who owns it?
2. What does it touch?
3. Why does it exist?

We also recommend a named person who is in charge of scripts and keeps that documentation current after the migration.

Translating the code for the team

Often, only one or two people on the customer side understood the scripts, and sometimes nobody did. That is when teams get overwhelmed during a migration. Part of our job is to explain what each script does in plain terms, so the people who will own it in Cloud can make good decisions and maintain it later.

How it turned out

Teams came out of this with a clear picture of what everything does and what actually matters. They ended up with fewer scripts, less to maintain, and less technical debt in Cloud. A lot of what used to need a script now runs without one.

What they have now is inventoried, documented, and built with tools the team understands and can maintain. That was the goal from the start: set Cloud up for as little ongoing maintenance as possible, and avoid carrying the old problem forward.

What I tell teams facing this

1. Treat the migration as a chance to rethink, not just rewrite.
2. Inventory scripts from scratch. Don't trust old documentation.
3. Read the code before you estimate the work.
4. Check native features and Automation before you rewrite anything.
5. Give every script an owner, a purpose, and a record of what it touches.
6. Expect some features to look and behave differently, and tell users early.

Where this connects to identity and agents

The scripts in this engagement did not fail because of bad code. They became a problem because the people who wrote them had moved on, and nobody left behind knew what they did. Agents create the same risk, only faster. Teams are building them quickly, and the people who build them change roles or leave. If nobody records who owns an agent, what it touches, and why it exists, the same knowledge gap shows up a few years later. The habit we built for scripts during this migration is the same one every team needs for agents from day one.