Managing app workflow changes (JSU, JMWE) without risking production

[#1]

I spend a lot of time thinking about the struggles of a Jira admin. It’s a difficult job that requires deep technical knowledge and an ability to connect dots across an organization like no one else. And with more and more new features built into Jira every year, the job only gets more complex. 

What I want to talk about here is how admins manage change in Jira over time. For example, let’s say a workflow or custom field needs updating. How do you go about managing that change to ensure no unintended consequences occur? 

Some admins may have a well-oiled, step-by-step Rube Goldberg approach they’ve perfected over the years — screenshots, careful timing, a coworker over their shoulder to supervise… Ultimately, it’s a very manual, tedious, hair-pulling process to move tested changes from sandbox to production. 

Third party apps add to the complexity

As if managing Jira itself was not complicated enough, now you’ve got a handful of apps that are deeply embedded in your workflow.

If your team is using JSU (Automation Suite for Jira) or JMWE (Jira Misc Workflow Extensions) for workflow automation, you’ve likely built something custom and powerful that your entire business has come to depend on. 

Again, you find yourself asking - how do I effectively maintain changes to these configurations and automations over time?

Sandboxes offer a partial solution

For teams on Premium or Enterprise plans of Jira Cloud, the sandbox feature makes it easy to replicate production to a sandbox system so you can validate changes safely.

But that’s only part of the process.

The native sandbox feature doesn’t account for app-level configurations, which are often embedded directly into workflows. And once changes are validated, there still isn’t a straightforward way to move those updates back into production — for your apps or any configuration for that matter.

So admins end up recreating those changes manually. Rebuilding logic. Double-checking dependencies. Making sure nothing gets missed.

You’re usually left trying to piece it together yourself. What changed. What it affects. Whether it’s safe to push.

What usually happens when it goes wrong

Most failures don’t announce themselves immediately. By the time it’s noticed, users are already impacted with missing custom fields, reports that won't load, or missed tickets entirely. And you’re troubleshooting from scratch without a clear record of what changed.

This is where teams start looking for more structured ways to manage change. Many turn to the marketplace for an app, like Configuration Manager for Jira (CMJ), to automate the movement of changes from sandbox to production. 

Chad Harris, Systems Analyst at NASA’s Jet Propulsion Laboratory, described what changed when his team moved away from manual configuration management:

“With CMJ, productivity has been tremendously increased. I would say a 25 to 50% time savings in hours.”

The time saved wasn’t just on making changes. It was on reducing the overhead of managing the risk around them.

Why CMJ tends to help

Configuration Manager for Jira (CMJ) adds a structured layer to a process that Jira leaves largely manual and unpredictable. 

For teams using JSU and JMWE, you can now use CMJ to:

Capture configurations as snapshots
Instead of relying on screenshots or memory, you have a reusable, point-in-time record of your workflow setup, including JSU and JMWE logic.

Compare configurations before deploying
Rather than guessing what a change might impact, you can see exactly what’s different before anything goes live.

Deploy changes across environments
Instead of manually rebuilding workflows in production, you can promote tested configurations from sandbox to production in a controlled, repeatable way.

Roll back when needed
If something doesn’t behave as expected, you can revert to a known good state instead of debugging from scratch.

Instead of editing directly in production, or testing in sandbox and then manually recreating everything, you have a checkpoint between “we tested this change” and “this change is live.”

If this resonates, check out a demo of this use case in the CMJ documentation.