The 1,000-issue wall
Jira Cloud's built-in bulk change tool (search → select all → Bulk change) is hard-capped at 1,000 issues per operation. The cap protects site performance, applies no matter how many issues your search matches, and there is no admin setting to raise it. If your cleanup touches 10,000 issues, the native tool means running the same wizard ten-plus times, hoping nobody edits the underlying set between runs.
Beyond the cap, the native tool runs in your browser tab, offers no before/after preview of values, and leaves no record of what changed once the confirmation screen is gone.
Option 1: Slice the query into batches of under 1,000
The classic workaround: partition your JQL so each slice matches fewer than 1,000 issues, then run the native bulk change once per slice. Typical slicers are project, issue key range, or created date:
project = OPS AND created >= 2024-01-01 AND created < 2024-07-01 AND labels = old-team
project = OPS AND created >= 2024-07-01 AND created < 2025-01-01 AND labels = old-team
…Works, but: it is manual, slow, and error-prone. You have to verify each slice is under 1,000, repeat the identical wizard N times without fat-fingering a step, and stitch together your own record of what was changed. For a one-off change of 1,500 issues it is tolerable; for recurring hygiene at scale it is misery.
Option 2: CSV export and re-import
Jira's external system import can update existing issues when the CSV contains the issue key. So: export your search to CSV, edit the column in a spreadsheet, and re-import with field mapping.
Works, but: it is site-admin territory, the field mapping step is notoriously fiddly (especially for selects, users, and multi-value fields), exports are themselves paginated, and a mis-mapped import writes wrong values at scale with no preview and no undo. Most admins reach for CSV import as a migration tool, not an editing tool.
Option 3: Script it against the REST API
The Jira Cloud REST API has no 1,000-issue ceiling: page through the search results and
PUT each issue. A short Python or Node script with an API token does it.
Works, but: now you own pagination, field-format quirks
(update vs fields, option IDs vs labels), rate limiting with
backoff, retries, and logging. The script runs with your credentials from your laptop, and
when it dies at issue 3,182 you get to work out where it stopped. It is a fine option if you
are comfortable writing and babysitting scripts, and a liability if the next admin isn't.
Option 4: Use a Marketplace app built for it
This is the gap our app Bulk Ops for Jira exists to fill. It runs the whole operation as one JQL-driven job on Atlassian's own infrastructure:
- One query, one run: write the JQL once and the run covers the entire matched set, past the 1,000-issue ceiling, in the background. Close the tab; it keeps going.
- Mandatory preview: before anything changes you see the exact field and the before/after value per issue, with an option to suppress email notifications.
- Audit trail: every issue is recorded as ok / skipped / failed with before and after values, exportable to CSV. Rate limits are handled automatically.
- No data egress: it is built on Atlassian Forge and runs entirely inside your Atlassian environment, with no external servers.
It covers field edits (text, dates, priority, users, selects, components, versions), add/remove on multi-value fields like labels, and workflow transitions. See the user guide for the full walkthrough, or the companion post: how to bulk edit Jira issues with JQL, step by step.
Try it free: the free plan includes the full operation set with runs up to 1,000 issues (the same ceiling as native Jira, but with the preview and audit trail), so you can evaluate it on real work before a paid plan lifts the cap entirely. Bulk Ops for Jira on the Atlassian Marketplace →
Which should you pick?
| Approach | Effort | Preview | Audit trail | Best for |
|---|---|---|---|---|
| JQL slicing + native tool | High, repetitive | Issue list only | None | One-off, 1,000–2,000 issues |
| CSV re-import | High, fiddly | None | None | Migrations |
| REST API script | Developer time | DIY | DIY | Teams with scripting habits |
| Bulk Ops for Jira | Minutes | Before/after per issue | Per-issue, CSV export | Any size, repeatable |
Frequently asked questions
Why does Jira only let me bulk edit 1,000 issues?
The 1,000-issue cap on the native bulk change tool is a platform performance safeguard. It applies to every Jira Cloud site and cannot be raised by an admin setting.
Can I bulk edit without spamming everyone with notifications?
Yes: both the native tool and Bulk Ops for Jira let you suppress change notifications for the run, so a 5,000-issue label cleanup does not send 5,000 emails to watchers.
Does bulk editing respect permissions and workflow rules?
In every approach above, changes are validated by Jira itself: field configurations, permissions, and workflow conditions still apply. Bulk Ops runs as the admin who launches it and can only change what that admin could change by hand; issues that fail validation are reported individually instead of aborting the run.
Is there an undo?
Not natively, in any approach. That is why a preview and an audit trail matter. Bulk Ops records the before value of every change, so reversing a mistake is a second run using the recorded values, not an archaeology project.
Kyle Twogood is the founder of Magrathea Software. He’s been building production software since 1997.