The old workflow editor disappears by July 26. Check these five things before your users notice.

[#1]

The final removal started July 13 and completes by July 26, 2026, rolling out through Jira's seasonal releases. If you're reading this and your instance still opens the old editor, you're in the last wave, and there are a few things that fail quietly rather than loudly when it flips.

I've spent the last few months moving client instances (and my own app's workflow rules) fully onto the new editor. This isn't a feature tour. Atlassian's announcement already covers "what's changing." This is the list of things that actually bit, in order of how much they'll hurt.

Updated 21st July:

Clarified how common transitions appear in the new editor (nothing is merged; your data doesn't change), and added a sixth check from the comments: the new editor has no XML export, so snapshot your workflows via API before the flip. Thanks to @Becker_ Rene, @Derek F_, @Antonio Valle _G2_  and @Aaron Morris for sharpening this post.

Scope note: this is Jira Cloud only. Data Center keeps its editor, so nothing here applies to DC.

1. Unpublished drafts are the silent killer

The new editor has no draft concept. It edits the active workflow directly. The old editor's drafts don't carry over. Worse: if a workflow still has an old-editor draft sitting on it, edits made in the new editor can fail to apply to transitions, or you'll get stale-draft warnings where publishing the old draft would overwrite newer changes. This is tracked as JRACLOUD-83818.

The fix, before July 26: audit every workflow for unpublished drafts and either publish or discard them. All of them. A draft someone parked in 2024 "to finish later" is now a data-loss risk, because once the old editor is gone, that draft's changes are unrecoverable through the UI.

Quick way to find them: Settings (gear icon) > Issues > Workflows. Drafts are flagged in the workflow list. In larger instances, split the list among your admin team and clear it this week.

2. "Common transitions" don't exist anymore. The model changed.

In the old editor, you reused a transition across statuses by creating it once and applying it to other statuses via Add transition. The new editor replaces this with a single transition that can originate from multiple statuses, carrying one set of rules and properties.

Functionally equivalent for most workflows. But if your old workflow used the reuse pattern with slightly different rule sets on what looked like the same transition, the consolidation is where behaviour drifts. After the flip, open your three most complex workflows and verify each multi-origin transition's rules against what you had. Do it while your old-editor documentation and screenshots are still fresh.

3. Your automation for transition properties may already be broken

Separate from the editor, but it lands in the same cleanup: the workflow transition properties API set has been removed from the public API (deprecated March 30, 2025, now gone). If you have scripts, CI checks, or admin tooling that read or wrote jira.permission.* or other transition properties through those endpoints, they're failing now. The replacement is the Bulk get workflows and Bulk update workflows APIs.

Transition properties themselves still exist and are editable in the new editor (select the transition, then properties in the details panel). It's the old API surface that's gone, not the feature. I've seen these confused in at least three Community threads.

4. Rules moved and got renamed. Retrain the muscle memory before the tickets arrive.

Conditions, validators, and post functions are all "rules" now, configured from the transition's details panel in the single-view editor. No more separate tabs. Atlassian publishes a mapping table of old rule names to new ones ("Features in the new workflow editor" in support docs); print it, because the first week of admin questions will be "where did the Field Required validator go," and the answer is "same rule, new name, new location."

One thing that's better than the rumors suggest: the new editor does have a text view for complex workflows. Atlassian lists it explicitly in the deprecation notice. If you've been holding onto the old editor because "the new one has no text mode," that reason expired. Use it for search-and-debug on your spaghetti workflows.

What is still being raised by admins in the comments of Atlassian's own deprecation post: confusion over how conditions/validators/post functions were remapped, and concerns about approval restrictions and rule-ordering behaviour under the new rule structure. If your workflows lean heavily on approvals or on precise rule execution order, test those specific paths on a copy of a real workflow this week, not after the 26th.

5. If you run workflow apps (JSU, ScriptRunner, JWT, or anything from the Marketplace), test that the rules render

Wearing my app-developer hat for a moment: Atlassian's guidance to vendors is that workflow-related apps must provide their rule configuration properly inside the new editor, ideally with dynamic rule descriptions so admins can read what a rule does at a glance. Most major vendors are ready, but "ready" varies. In one migration I found an app's post function that configured fine but showed a blank description in the new editor, which meant the admin team couldn't audit workflows without opening every single rule.

The test open a workflow that uses app-provided rules, confirm every rule (a) opens its config panel, (b) saves, and (c) shows a meaningful description in the diagram view. Atlassian recently added the ability to preview marketplace transition rules in the new editor, with a "View all" rules experience on the way. The platform side is improving, but the description quality is still on each vendor. If anything fails, raise it with the vendor now; after the 26th there's no fallback editor to hide in.

The pre-July-26 checklist

- Publish or discard every old-editor draft (this is #1 for a reason)
- Screenshot or export your most complex workflows for reference before the flip
- Verify multi-origin transitions consolidated with the correct rule sets
- Grep your scripts for the removed transition-properties API; move to Bulk workflow APIs
- If you use approvals or order-sensitive rules, test those paths on a workflow copy
- Test every Marketplace-app workflow rule: opens, saves, shows a description
- Circulate the old-to-new rule name mapping to anyone who edits workflows

You don't need to migrate workflows themselves. Existing workflows carry over and stay editable. The risk isn't the workflows. It's the drafts, the scripts, and the assumptions.

If you hit something that doesn't behave the way it did in the old editor, drop it in the comments. I'm collecting edge cases from this rollout window and will keep this post updated through the 26th.

[Maria Reisinger]

Great checklist. I also see these platform changes as a good opportunity to review workflow governance. Major migrations often don't create inconsistencies, they simply make existing ones much more visible. It's a great time to step back and ask whether workflows are still consistent and maintainable across projects.

[Becker_ Rene]

Thank you, for the overview!

One question though:

You wrote: The new editor has no draft concept. It edits the active workflow directly. 

I have been using the new editor for quite some time now and it offered a button to save the workflow. The button stays, doesn't it? So I still can tinker and then hit "save" for it to go live. Correct?

I just wanted to clarify in case I misunderstood something.

All the best

Rene

---

[Derek F_]

Also, you can't export to XML anymore.

[Antonio Valle _G2_]

Please add "the new editor has no workflow export functionality", to the checklist, so if you use the XML files for anything, think on exporting your workflows via API.

[Anne Saunders]

Thank You!!

I found 3 drafts hanging out (from goodness only knows when!), and I was able to tidy them up. 

[Aaron Morris]

@Becker_ Rene  

I have been using the new editor for quite some time now and it offered a button to save the workflow. The button stays, doesn't it? So I still can tinker and then hit "save" for it to go live. Correct?

Yes, that button isn't going away.  The difference is that the old editor let us make changes and save them without publishing.  Now, you have to publish or discard (as you've seen).

[Becker_ Rene]

@Aaron Morris : thank you for the clarification :-)

---

[Antonio Valle _G2_]

@Sami Shaik I have been reviewing this with the team. We can not find any API endpoint that helps us to evaluate a site and check for draft workflows.... that means to review all the workflows in every site!

Do you know if there is any alternative?

The only clue we have is the visual indication, but having something that allows us to create a script would be great!

 

[Sami Shaik]

@Antonio Valle _G2_ 

Great question. I dug into the current API docs properly before answering because I did not want to guess on this one.

Short answer: I could not find one either, and I am fairly confident it does not exist in the public API.

Three dead ends, for anyone who wants to retrace it:

1. GET /rest/api/3/workflow/search is documented as returning published classic workflows only, so old-editor drafts are invisible to it. The older GET /rest/api/3/workflow endpoint was removed on June 1, 2026, so no luck there either. Note that inactive workflows do appear in these results, since they are published, just unassigned. They are easy to mistake for drafts, but they are a different thing.
2. The draft endpoints you will find in the docs (/rest/api/3/workflowscheme/{id}/draft and friends) are for workflow scheme drafts, a completely different object: they hold edits to the issue-type-to-workflow mapping, not edits to a workflow itself.
3. The one API surface that acknowledged workflow drafts was the workflow transition properties set, which had a workflowMode parameter. That entire API was deprecated on March 30, 2025 and has since been removed, and its replacement (the Bulk get and Bulk update workflows APIs) works on published workflows only.

One thing that shrinks the manual job considerably: drafts only ever existed on active workflows, because that was the only case the old editor could not edit directly. So you only need to eyeball the Active section of each site's workflow list, not the full list.

The practical version for this week: split the Active workflow lists across the team and clear the drafts manually. Painful, but it is a one-time job that becomes impossible once each site flips, so better now than after the 26th.

If anyone from Atlassian reads this and knows an endpoint I missed, please correct me. Happy to be wrong on this one.

[Esther Ortega]

Excellent post! Exactly the kind of practical analysis needed to land on the new workflow editor without any surprises. I appreciate that it's not another "what's changing" tour, but rather the list of what actually bites, ordered by impact.

The point about unpublished drafts strikes me as especially valuable: it's one of those things that fail quietly and are easy to overlook until there's no going back. I'm taking the checklist as-is to review with my team before the 26th; and the nuances in the comments are really useful too (the export-via-API issue and the lack of an endpoint to detect drafts).

Thanks for taking the time to compile it and, above all, for committing to keep it updated throughout the rollout. Saved as a reference!

[Antonio Valle _G2_]

@Sami Shaik  Maybe it is a problem with the language. We don't understand the paragraph "But if your old workflow used the reuse pattern with slightly different rule sets on what looked like the same transition, the consolidation is where behaviour drifts."

Do you mean that Atlassian will fusion different transitions into a single one? Under which criteria?

When does this happen? When you open the workflow with the new editor for the first time?

[zoltanersek _outpostlabs_dev_]

One additional recommendation I'd make is to use this transition as an opportunity to clean up workflow sprawl. Most organizations don't revisit workflows unless they're forced to, and a platform change like this is the perfect trigger.

[Sami Shaik]

@Antonio Valle _G2_ 

Fair question, and the fault is my wording, not your English. Let me be precise.

No, Atlassian does not merge anything. No transitions are fused, there are no consolidation criteria, and nothing changes when you first open a workflow in the new editor. Atlassian has stated this directly in their announcement: your workflow setup should not change when moving from the old editor to the new one, and pre-existing workflows work in the new editor regardless of which editor created them.

What actually happens: in the old editor, a "common transition" was always one single transition under the hood, referenced by several statuses and sharing one set of rules. The old UI showed it in multiple places, which made it easy to read as several separate transitions. The new editor draws that same single transition once, with multiple From statuses. Same data, clearer picture.

And the reverse case: two transitions that only shared a name were never one entity, and they stay separate in the new editor. Nothing gets combined. Transition reuse does not even exist in the new editor yet (see JRACLOUD-37296 if you want to vote for it).

The risk I was pointing at is human, not technical. If your team edits a multi-origin transition believing it only affects one path, the change applies to every From status at once. If they assume two same-named transitions share rules, they will edit one and wonder why the other did not change. That is why I suggested verifying complex workflows: not because Atlassian changed them, but because the new view finally shows the structure you always had.

I have reworded that paragraph in the article to make this clearer. Thanks for pushing on it, this made the post better.

[janez_m]

I tried to discard the drafts from old editor by opening them and then selecting "Discard draft" on the floating box that appears on the left lower corner - but it looks like there is a bug, as this action does not discard the draft - on the list of workflows the text that it contains draft remains and if you reopen the workflow you are presented with the "Load draft from old editor?" again. Tried to get some help from ROVO and it hallucinated some V3 and V2 API non existent api calls how to delete the drafts. I will open a support ticket as I do not know how to proceed - other suggestions from ROVO are not acceptable (to apply changes and such).

P.s. Looks like there is a workaround that works - you can discard the draft in the old editor.

[Julia Foden]

@janez_m I came here to answer your question and saw that you found the solution and edited your comment :)

So yes, ignore that floating box in the lower left and open the workflow in the old editor to discard the draft.

And ignore Rovo ;)

@Sami Shaik thank you for this piece, really useful.

[Antonio Valle _G2_]

My investigation has been successful. I found the way to get all your drafts using a deprecated (but still useful) endpoint:

GET https://your-domain.atlassian.net/rest/api/3/workflow/search?startAt=0&maxResults=50&expand=default,hasDraftWorkflow&isActive=true&orderBy=name

The key here is the hasDraftWorkflow expand

Good hunting!

Antonio