Taming the Automation Jungle: Auditing Jira DC Before Cloud Migration

[#1]

How To Inventory and Defuse Jira DC Automation Before Moving to Cloud

If my previous post was about why Jira Data Center automation is a ticking time bomb, this one is about what to do next.

This is mainly for the people who will actually have to deal with the details: Jira admins, system owners, Atlassian platform teams, and anyone who secretly knows where the scripts are buried.

Your job is simple to describe and painful to do. You need to figure out:

• What automations you have

• Which ones still matter

• What to keep, what to rebuild, and what to drop before you move to Cloud

Let’s make that at least structured and predictable.

---

The Three Buckets of Jira Automatio

When you start pulling on threads in a mature Jira Data Center instance, you quickly realise automation is everywhere. To avoid getting lost, it helps to put everything into three broad buckets:

1. Jira native automation

2. Marketplace app scripts and automations

3. External scripts, plugins, and integrations

This is not a strict taxonomy. It is a way to make the problem thinkable, so you can talk about scope and risk with other people.

---

Bucket 1: Jira Native Automatio

Jira native automation is usually the most migration friendly part of the picture.

The mental model is familiar in both worlds. You have rules made of triggers, conditions, and actions. You use them to:

• Update fields

• Create or link issues

• Transition issues in response to events

• Send email or chat notifications

There is no automatic migration button for rules. You will normally recreate them in Jira Cloud, then retest. The upside is that the ideas carry across. A lot of rules can be rebuilt almost one for one.

You should spend extra attention on rules that are:

• Global and run very frequently

• Triggered by events on many projects

• Working through large sets of issues in a single execution

• Calling webhooks into other systems

In Cloud, you need to respect different limits and behaviours, such as rate limits, rule run quotas, and slightly different permission handling. A rule that looks harmless in the Data Center UI can become noisy or throttled in Cloud if it fires too often or touches too much.

A sensible first move is to list your higher impact rules, rebuild a subset of them in a Cloud sandbox, and see how they behave. Treat this as “rebuild and test”, not “start from scratch with a blank page”.

---

Bucket 2: Marketplace App Scripts and Automation

This is where effort and risk ramp up quickly.

ScriptRunner and Power Scripts / Power Suit

Two of the most common automation engines on Jira Data Center are:

• ScriptRunner for Jira (Adaptavist)

• Power Scripts / Power Suite for Jira (Appfire)

On Data Center:

• ScriptRunner uses Groovy, running inside Jira with deep access to internal Java APIs and the full data model.

• Power Scripts uses SIL, a scripting language designed specifically around Jira and related tools.

Teams rely on these tools for things like:

• Workflow post functions, conditions, and validators

• Event listeners that react when issues are created or updated

• Scheduled jobs for maintenance, data fixes, or synchronisation

• Behaviours or live fields that dynamically change screens

• Extended JQL functions that drive filters, boards, and reports

In Cloud, none of that Groovy or SIL code can run directly. Custom logic typically lives in:

• Jira Cloud Automation rules

• Forge or Connect apps, usually built in JavaScript or TypeScript

• External services calling Jira Cloud APIs on a schedule or via webhooks

From a migration point of view, that means your existing scripts become requirements, not reusable assets. The questions you need to answer for each major piece of logic are:

• What does this actually do in business terms

• How important is it to keep that behaviour

• Is there a Cloud friendly way to achieve the same outcome

The vendors can help here. Adaptavist and Appfire both publish documentation and guides on what their apps can and cannot do in Cloud, and in some cases provide tools to help move configuration. They cannot automatically port your custom scripts, but they can save you time when you are doing impact analysis.

Workflow Automation: JMWE and JS

Two other tools that show up a lot in serious Jira instances are:

• JMWE, Jira Misc Workflow Extensions (Appfire)

• JSU, Automation Suite for Jira Workflows (Appfire)

On Data Center, they extend workflows with extra validators, conditions, and post functions that Jira does not provide out of the box. Many approval flows, synchronisation rules, and transition side effects live here.

Both products have Cloud versions. However, the feature sets are not identical. Some Data Center functions are missing or have different limits. Jira Cloud itself has a slightly different approach to post functions and workflow execution.

So your job becomes:

• Identify where JMWE and JSU are used in your workflows

• Map those uses against what the Cloud versions support

• Decide whether to recreate the logic using:

  • Jira Cloud workflow features

  • Jira Cloud Automation

  • The Cloud versions of JMWE or JSU

  • Or some combination of these

Again, vendor documentation is your friend. It will not remove decisions, but it will tell you where the known gaps and workarounds are.

Scripted Fields: JMC

Jira Misc Custom Fields (JMCF) is another Marketplace app that often ends up in the critical path.

On Data Center, JMCF lets you define calculated or scripted fields whose values are computed on the fly. These fields then appear on screens, are used in JQL, and feed dashboards and reports.

On Cloud, JMCF supports many of the same ideas, but not every scripted field type is available. Some complex calculations, especially ones that rely on Data Center specific behaviour, may not map cleanly.

For JMCF, a simple triage looks like this:

• List your scripted fields

• Note where each one is used (filters, boards, dashboards, reports)

• Mark which are essential to preserve and which are “nice to have”

• Check Cloud support for each pattern and decide whether to rebuild, replace, or drop it

---

Bucket 3: External Scripts, Plugins, and Integration

The third bucket is everything that lives outside Jira but relies on it.

This can include:

• Custom Java plugins that use Jira’s internal APIs

• Python, Node, or PowerShell scripts that call the REST API

• ETL jobs that pull from the Jira database into a data warehouse

• Internal tools that read Jira data for reporting or orchestration

• Webhooks wired into internal services on your network

You should assume these will not work against Jira Cloud without changes. Here are the main reasons.

Authentication and API structure

On Data Center, many scripts:

• Use basic authentication with a username and password

• Talk to REST endpoints under /rest/api/2

• Expect specific JSON structures and user fields like username or userKey

On Cloud, you will need to move to:

• API tokens, OAuth, or app based auth

• Updated endpoints and API versions

• Using accountId in place of username or userKey

Any script that parses responses or builds URLs based on old patterns will need to be checked.

Java APIs and P2 plugins

Custom plugins and event listeners that run inside Jira and call internal Java APIs are a Data Center only pattern. Jira Cloud does not run P2 plugins. Anything in this category that you want to keep will need to be rewritten as a Forge or Connect app, or replaced with a combination of Cloud automation and external services.

Direct database access

If anything in your environment connects to the Jira database to drive reports or integrations, that approach will not carry over. Jira Cloud does not expose its database layer. You will need a new design built on Cloud APIs, app level exports, or a dedicated data pipeline.

Network and URLs

Data Center Jira often lives on an internal URL such as http://jira.internal:8080. Jira Cloud will live under https://something.atlassian.net. Internal only URLs and firewalls that assume Jira is inside your network will need to be revisited. Webhooks and integrations must use endpoints that are reachable from the public internet and secured appropriately.

If a script or integration touches any of these areas, put it on your list and plan for at least some refactoring.

---

Have a Plan, Not Just a Pil

Once you start discovering all these pieces, it is easy to feel overwhelmed. The goal is not to keep every clever trick you have accumulated over the last decade. The goal is to be deliberate about what you carry forward.

A simple catalogue can turn a messy pile of automations into a structured backlog. For each item, try to capture:

• Source
  Where it lives: ScriptRunner, JSU, JMCF, native automation, external script, custom plugin, and so on.

• Type
  Script, validator, condition, post function, listener, scheduled job, calculated field, integration, report.

• Name and description
  Enough to find it again, plus a short explanation in plain language of what it does and why it exists.

• Complexity
  Roughly high, medium, or low. Think about how many steps, dependencies, or side effects are involved.

• Business priority
  High, medium, or low. Ask what happens if this stops working for a week after go live.

• Compatibility notes
  For example: “config only, should work”, “needs transformation for Cloud”, or “no Cloud equivalent”.

• Action
  Decide whether you plan to drop it, rebuild roughly as is, or redesign the solution.

• Owner or decision maker
  Who owns the process and who can approve changes or retirement.

This work involves discovery, technical analysis, and a fair bit of negotiation with process owners. It is much easier if you start early, while there is still time to experiment in a Cloud sandbox and adjust scope. It is very painful when it happens in the last few months before a hard deadline.

---

If you are reading this and mentally counting how many ScriptRunner jobs, JMWE post functions, or mystery PowerShell scripts your Jira depends on, you are exactly the person this was written for.

As an Atlassian SME, I have helped teams do this inventory work in everything from small Jira instances to very large and regulated environments. The patterns are surprisingly consistent, even when the tools and org charts look different.

If you would like more practical templates, examples of real automation catalogs, or deep dives into specific Marketplace apps, drop a comment with the tools or patterns you are most worried about. That will help me decide what to unpack next.