Jira Cloud Data Limits (September 2026): The Technical Playbook for ITSM Teams, and How ZigiOps Keeps Integrations Under the Caps

Jira Cloud data limits are hard ceilings that Atlassian enforces on configuration objects such as field options, releases, components, priorities, and workflow statuses. Since September 2026, any administrative action that would push one of these objects past its limit is rejected outright. For ITSM teams, the biggest risk is not the admin console: it is the integrations, automations, and pipelines that create Jira configuration on the fly and start failing without warning.

What actually changed in September 2026

Atlassian announced the new limits well in advance, and the official Jira Cloud data limits and guardrails documentation now lists them as enforced. The rollout came in two waves: fields per space and work types per space were capped first, and eight more limits followed in September 2026.

Note the terminology: Atlassian now uses "space" for what most of us still call a project, and "work item" for issue. Same things, new labels.

According to Atlassian's announcement on the Community, the limits apply across the Jira Cloud family of apps, including Jira Service Management and Jira Product Discovery, on every plan. Customers migrating from Data Center get six months from their migration date to comply. Atlassian also introduced softer guardrails, such as recommended thresholds for space role actors, which are not enforced but signal performance risk.

What happens when you hit a limit

It is worth being precise here, because a lot of commentary gets this wrong. When a limit is reached:

• Jira rejects the specific action that would exceed the limit, such as adding option number 20,001 to a select list or creating release number 15,001 in a space.
• If a bulk action would take the configuration over the limit, Jira rejects the entire action rather than applying it partially.
• Existing configuration keeps working. Nothing is deleted, and end users can still create and update work items.
• Unrelated configuration changes are not affected.

So your service desk agents will not suddenly be locked out. The damage happens somewhere quieter: in every process that creates configuration automatically.

Why integrations are where the limits really bite

Most Jira configuration sprawl in ITSM environments is not created by humans clicking in the admin console. It is created by machines. Integrations, automation rules, CI/CD pipelines, and marketplace apps generate options, versions, and components as a side effect of doing their job. When one of those calls is rejected, the integration fails, often silently, and tickets stop flowing between teams.

Here are the patterns we see most often in enterprise Jira and ITSM estates:

• Dynamic select options. An integration pushes ServiceNow categories, configuration item names, customer names, or monitoring hostnames into a Jira single-select or multi-select field, creating a new option whenever a value does not exist. Over a few years, that field quietly climbs toward 20,000 options.
• Pipeline-generated releases. CI/CD tooling creates a Jira version for every build, hotfix, or environment deployment. At a few dozen per day, a busy space reaches 15,000 releases faster than anyone expects.
• Components as routing tags. Assignment groups or services from the ITSM tool are mirrored as Jira components, one per group, per region, per customer.
• Priority mirroring. Instead of mapping source priorities to an existing Jira scheme, a script creates new priorities to match the source system exactly. The limit is 100 priorities per space, which sounds generous until three integrations each bring their own set.
• Status cloning. To make Jira "look like" ServiceNow, teams add every ServiceNow state and substate to a Jira workflow. Multiply that by each variation of the workflow and the 200-statuses-per-workflow cap stops looking theoretical.
• Per-customer security levels and grants. Managed service providers often create an issue security level and a set of permission grants for every customer. With a cap of 50 security levels per space and 50 grants per permission, multi-tenant setups hit the wall first.

If any of these sound familiar, the question is not whether your integrations will break, but when.

How to audit your exposure in an afternoon

Premium and Enterprise customers can use Atlassian's Site Optimizer to see usage against limits. Standard customers do not have it and need to query the Jira Cloud REST API directly. Either way, these are the endpoints worth knowing:

Most of these endpoints are paginated and return a "total" value, so you rarely need to download every object. A minimal Python sketch for the releases limit looks like this:

import requests BASE = "https://your-site.atlassian.net" AUTH = ("admin@example.com", "API_TOKEN") for key in ["OPS", "ITSM", "PLAT"]: r = requests.get(f"{BASE}/rest/api/3/project/{key}/version", params={"maxResults": 1}, auth=AUTH) print(key, r.json()["total"], "of 15,000 releases")

Run the same pattern for components and field options, capture the numbers, and then measure again a month later. The growth rate matters more than the absolute number, because it tells you how much runway you have.

While you are at it, list every integration, automation rule, and pipeline that writes to Jira, and note which configuration objects each one can create. That list is your real risk register.

Your remediation options, from quick wins to structural fixes

There is no single fix, but the options fall into four groups.

1. Clean up what is unused

Atlassian has shipped cleanup tools alongside the limits, including bulk removal of unused custom field options and unused issue security levels. Archive or delete releases from closed projects, merge duplicate components, and retire workflows that are no longer assigned to any scheme. This buys time, but it does not stop the sprawl from coming back.

2. Redesign the data model

Some fields should never have been select lists. High-cardinality values such as hostnames, configuration item names, or customer IDs belong in text fields, labels, or a proper asset or CMDB system, not in a 20,000-option dropdown. Release versions should represent actual releases, not every build.

3. Change how integrations write to Jira

This is the step most teams skip, and it is the one that keeps the problem from recurring. Integrations should map incoming values onto a controlled set of existing Jira options, priorities, and statuses, and only create new configuration deliberately, if at all.

4. Move historical data out of Jira

For years of closed work that still has audit or reporting value, the answer is not deletion but relocation: migrate the history to an archive, a data platform, or another ITSM tool, then clean up the Jira configuration that only existed to support it.

Groups three and four are exactly where ZigiOps comes in.

How ZigiOps keeps your integrations under the limits

ZigiOps is a 100% code-free integration platform that connects Jira Cloud, Jira Data Center, and Jira Service Management with ServiceNow, BMC Remedy, Azure DevOps, Salesforce, Zendesk, Freshservice, monitoring tools, and more. See the full list of Jira integrations. Because every integration is configured in a guided UI rather than in scripts, changing how data is written to Jira is a configuration change, not a development project.

Map to existing values instead of creating new ones

ZigiOps field mapping supports conditional mappings and expressions, so incoming values are translated onto the options that already exist in Jira. A typical configuration:

• ServiceNow category "Network" or "Network Hardware" maps to the Jira option "Network".
• ServiceNow category "Database" or "Storage" maps to "Data Platform".
• Anything unmatched maps to "Other", while the original value is written to a plain text field for reference.

The same approach works for priorities (ServiceNow 1 to 5 mapped onto your existing Jira scheme) and statuses (ServiceNow states mapped onto the statuses your Jira workflow already has, instead of cloning them). The field option count stays flat no matter how many new categories the source system invents. We walked through this pattern in detail in Conditional Mapping in Jira and ServiceNow Integrations.

Check before you create with Lookup actions

When an integration genuinely needs to reference a release or component, a ZigiOps Lookup action queries Jira first and only proceeds if the conditions are met. For example, a workflow can check whether a matching release already exists and attach the work item to it, rather than creating a near-duplicate. Lookups also prevent duplicate work items when a monitoring tool fires the same alert repeatedly. Read more in Mastering Lookup Actions in ZigiOps.

Filter what reaches Jira in the first place

Trigger conditions decide which records are collected from the source system, using operators such as "is one of", "contains", and "greater than". Only P1 and P2 incidents for specific assignment groups need to become Jira work items? Configure it once. Less noise in Jira means fewer components, fewer versions, and fewer options created downstream.

Keep correlation lean

ZigiOps links records across systems through a correlation field. The recommended practice is a dedicated custom text field on the Jira side, which carries no options at all, so correlation adds nothing to your option budget. And because ZigiOps is a standalone application rather than a Jira plugin, it does not install its own bundle of custom fields, screens, and schemes into your instance.

Migrate history without scripts

When cleanup means relocating data, ZigiOps can move historical work items, comments, and attachments from Jira to another system, such as ServiceNow, Azure DevOps, or a separate Jira instance, using the same no-code workflows as live integrations. Trigger conditions let you migrate in controlled batches, for example by project, resolution date, or status, and "Last Time" expressions ensure only new or changed records are picked up on each run. Jira Cloud's rich text format (ADF) is converted properly on the way out, a topic we covered in ZigiOps ADF to HTML. For the broader methodology, see Data Migration in Batches and our enterprise data migration page.

Spread the load across the right tools

Sometimes Jira hits its limits because it is doing jobs that belong elsewhere: acting as a CMDB, a customer registry, or a release management system for every build. ZigiOps lets each tool do what it is good at, with ServiceNow as the system of record for incidents and configuration items, Azure DevOps or Jira for development work, and a bi-directional sync keeping them aligned. See how this works in practice with the ServiceNow Jira integration.

Enterprise-grade by design

• No data storage: ZigiOps does not store the data it transfers, only a few kilobytes of runtime state.
• ISO 27001 certified, with AES-256 encryption (FIPS 140-2 compliant) for credentials and TLS for web and listener traffic. Details on the ZigiOps security page.
• Unlimited transactions, with licensing based on connected system pairs, so a large migration does not come with a per-record bill.
• Deploy on-premises or in the cloud, with a primary and backup server model for high availability.

A worked example: ServiceNow to Jira without option sprawl

Consider a hypothetical but very common setup. ServiceNow incidents assigned to engineering groups are escalated to Jira, where developers work them. The original integration, built with scripts, created a Jira select option for every ServiceNow configuration item and a Jira component for every assignment group. After four years, the "Affected CI" field holds 18,600 options and one space has 4,200 components.

Here is how the same flow looks when rebuilt in ZigiOps:

1. Trigger: poll ServiceNow every minute for incidents where the assignment group is one of the engineering groups and priority is 1 or 2.
2. Trigger condition: exclude records last updated by the integration user, to prevent update loops.
3. Mapping, CI: write the ServiceNow CI name to a Jira text field instead of a select list. The legacy select field is retired and its unused options removed with Atlassian's cleanup tool.
4. Mapping, assignment group: conditionally map 60 ServiceNow groups onto 8 Jira components that reflect how engineering actually organizes work.
5. Mapping, priority and status: map ServiceNow values onto the existing Jira priority scheme and workflow statuses.
6. Correlation: store the Jira key in the ServiceNow correlation_id, and the ServiceNow number in a Jira text field, so comments, attachments, and state changes sync both ways.
7. History: migrate closed escalations older than 24 months to an archive project on a separate instance, in monthly batches, then remove the configuration that only existed for them.

The result: the integration keeps working, option and component counts drop far below the limits, and the growth rate falls to near zero because nothing in the flow creates configuration anymore.

Cleanup mistakes that make things worse

Under deadline pressure, teams tend to reach for the fastest fix. A few of those fixes create new problems:

• Deleting options that historical work items still use. Removing a select option can strip that value from closed work items and break reports. Use Atlassian's "unused options" cleanup first, and migrate or re-map values on historical records before deleting anything that is still referenced.
• Cleaning Jira without touching the integrations. If the integration that created 18,600 options is still running unchanged, you have only reset the clock. Fix the writer before you clean the data.
• Merging components or priorities without updating mappings. Every integration that references the old values will start failing or writing to the wrong place. Update the mappings in the same change window.
• Running one giant bulk operation. Because Jira rejects a bulk action that would exceed a limit in its entirety, large imports and restructures should be broken into smaller batches that you can validate one at a time.
• Treating it as a one-off project. Without a governance rule, the same fields grow back. Put an owner and a review date on every high-cardinality field, release convention, and component scheme.

A simple early-warning loop helps: schedule the REST API checks from your audit to run weekly, and alert when any count crosses 70% of its limit. That gives you weeks of runway instead of a surprise failure in the middle of a major incident.

ZigiOps vs. other Jira integration approaches

If you are re-evaluating how integrations write to Jira, these are the realistic options. Details are based on each vendor's public documentation at the time of writing.

The key differentiator for the data limits problem is not the connector list. It is how easily your team can change mapping logic when the limits force a redesign. Scripts and Groovy rules can do it, but someone has to write, test, and maintain the code. In ZigiOps, it is a mapping change in the UI. For the business case behind that choice, see Building vs. Buying a Jira Integration.

Your 30-day action plan

1. Week 1: Baseline. Pull current counts for every limit using Site Optimizer or the REST API. Flag anything above 60% of its cap.
2. Week 1: Map the writers. List every integration, automation rule, pipeline, and app that creates Jira configuration, and what it creates.
3. Week 2: Quick cleanup. Remove unused field options and security levels, archive dead releases, and merge duplicate components.
4. Week 2 to 3: Fix the integrations. Change integrations to map onto existing values, add lookups before creation, and filter what reaches Jira.
5. Week 3 to 4: Relocate history. Migrate closed, high-volume data that still needs to be retained, then clean up the configuration it depended on.
6. Ongoing: Govern. Add configuration limits to your change process. New select fields, components, and release conventions should require an owner and a cleanup policy.

The bottom line

Jira's September 2026 data limits will not lock out your users, but they will break the automation your ITSM operations depend on, one rejected API call at a time. The fix is part cleanup, part redesign, and part changing how integrations write to Jira. ZigiOps handles the last two without code: mapping onto existing values, checking before creating, filtering noise, and migrating history, all without storing your data.

Want to see your own Jira and ServiceNow flow rebuilt to stay under the limits? Book a demo and bring your largest select field.