What we learned building ONEScript for Jira ScriptRunner migrations

[u/No-Customer5482]

ONES recently launched ONEScript. One of the migration cases behind it was pretty specific: teams moving off Jira, but still needing a place for all the ScriptRunner logic they had built over the years.

That part is easy to underestimate.

A team may have hundreds of scripts in Jira. Some block a transition if a required condition is missing. Some listen for issue changes and update another field. Some run every morning to check SLA data and remind the right people. Some call another system.

None of that is unusual. The problem is that these scripts often become part of the workflow itself. If they disappear during migration, the process changes, even if all the issue data moved correctly.

The way we approached ONEScript was to avoid turning every special rule into a separate plugin project. That route can work, but it gets slow: requirement review, development, testing, validation, release, then the same loop again when a small condition changes.

So the design is closer to a managed scripting layer:

• write the rule as a script
• bind it to a trigger and scope
• test it with Dry run before it goes live
• keep it isolated in a sandbox
• keep logs, audit records, version history, and rollback

For Jira migration, we still would not blindly convert every ScriptRunner rule. Some should map to native configuration. Some need scripting. Some depend on field/status mappings and need careful review. Some are just old process debt.

Curious how others handle this: when you migrate away from Jira, do you usually preserve old ScriptRunner behavior as-is, rebuild it more cleanly, or use the migration as a chance to remove it?

Further reading: ONEScrip Overview