How to bulk edit Jira issues with JQL, step by step

Before you start

• You need Jira administrator permissions: Bulk Ops is an admin-only tool.
• Install Bulk Ops for Jira from the Atlassian Marketplace (free for the full operation set up to 1,000 issues per run), then open Jira Settings → Apps → Bulk Ops for Jira.
• Every run follows the same three steps: write JQL → preview the matched set → confirm and run. Nothing changes until you confirm the preview.

Example 1: Clean up an inconsistent label

Your teams have tagged tech-debt work as techdebt, tech-debt, and TechDebt over the years, and every dashboard filter has to match all three. Let's standardize on tech-debt.

Step 1: Select the issues

labels in (techdebt, TechDebt)

Type the query in the JQL editor (it autocompletes fields and values), then run the search. The matched issues appear so you can sanity-check the set before going further.

Step 2: Build the operation

Choose Add or remove values on the Labels field: add tech-debt, remove techdebt and TechDebt. Add/remove never clobbers other labels on the issue; it only touches the values you named.

Step 3: Preview and run

The preview shows the before/after label list for every issue. Tick suppress notifications (nobody needs 2,000 "labels updated" emails), confirm, and the run executes in the background. Issues already carrying only tech-debt are counted as skipped (already correct, not an error), which also means re-running the same operation later is harmless.

Example 2: Reassign everything from a departing teammate

Someone is leaving and 340 open issues across six projects still list them as assignee.

assignee = "Erin Yao" AND statusCategory != Done

Choose Set a field → Assignee and pick the new owner (or unassign). The preview lists each issue with its before/after assignee. Project permissions still apply: if the new assignee can't be assigned in some project, those issues are reported individually as failed in the audit trail while the rest proceed.

Example 3: Close a backlog of stale issues

Every backlog accumulates issues nobody has touched in a year. Closing them in bulk, with a resolution that says why, keeps velocity reports honest.

project = OPS AND statusCategory != Done AND updated <= -365d

Choose Transition issues, pick the transition (say, Done), and set the optional resolution to Won't Do. Only issues whose workflow legally allows that transition from their current status are moved; the rest are reported per-issue in the audit trail rather than blocking the run.

After the run: the audit trail

Every run keeps a per-issue record: ok, skipped, or failed, with before and after values, exportable to CSV. Two habits worth forming:

• Export the CSV after significant runs. There is no one-click undo in any Jira bulk tool; the recorded before-values are your undo path (run the inverse operation if you ever need to roll back).
• Check the failed rows, not just the totals. Failures name the issue and the reason (a required field, a permission, a workflow condition), so fixing the stragglers is a two-minute follow-up run.

Tips for large runs

• Refine JQL until the count matches your intent. The preview step exists precisely so an OR you forgot doesn't edit half the site.
• Runs survive the browser. Execution happens server-side on Atlassian Forge, so you can close the tab and check the dashboard later.
• Rate limits are handled for you. If Jira throttles the API, the run pauses and resumes automatically; a huge run just takes a little longer.
• Free vs. paid: the free plan runs up to 1,000 issues per run; paid removes the cap entirely and extends run history from 7 to 90 days, the difference that matters for site-wide cleanups. More in how to bulk edit more than 1,000 issues in Jira.

Kyle Twogood is the founder of Magrathea Software. He’s been building production software since 1997.