Atlassian has published a second wave of enforced configuration limits for Jira Cloud. Eight new ceilings take effect in September 2026, and they apply to all Jira Cloud instances, including Atlassian Government Cloud. There is no tier carve-out.

Before anything else, here is what Atlassian says about existing data, because it is the first thing you need to know and it is stated plainly in their own documentation:

Existing configurations exceeding these limits will remain functional, and no existing data will be deleted.
Atlassian, Data limits and guardrails

Nothing breaks. Nothing is lost. What changes is your ceiling. A configuration that lands over one of these lines arrives in Cloud frozen at that line, and you find out about it the first time somebody asks you for one more status.

That is a specific risk for a long-lived Jira Data Center instance, because Data Center never told you to stop. Fifteen years of accumulated workflow, fifteen years of releases and a permission scheme that has absorbed every reorganisation since the instance was stood up are exactly the estate that lands over a line. This page gives you the numbers and then gives you the counting exercise to run against your own instance before you pick a cutover date.

The eight new limits

20,000 field options per field
50 work item security levels per space
50 permission grants per permission
15,000 releases per space
150 workflows per workflow scheme
200 statuses per workflow
10,000 components per space
100 priorities per space

These follow an earlier wave enforced in March 2026: 700 fields and 150 work types per space, and 10,000 select-list options per field. Both waves are published on the same page, Data limits and guardrails, which is the source for every figure above.

A note on vocabulary before you count

The limits are written in Cloud’s vocabulary, which is not the vocabulary on your Data Center screens. When you run the counts below, read space as the Data Center project, work item as the issue, and work type as the issue type. The objects are the same. Only the labels moved.

What “enforced” actually means

Two partner writeups arrived at the same reading of the enforcement behaviour independently, and it is narrower than the word suggests. Rustem Shiriiazdanov of Actonic, writing on 19 August 2026, puts it plainly:

Nothing already stored is deleted. Configuration that is over the line on the enforcement date stays where it is, and you are simply prevented from adding more of it.
Only the action that would cross the line gets blocked. Teams keep creating work items, commenting and transitioning as normal.

So the failure mode is not an outage. It is an administrator, some months after a migration, discovering that a routine configuration change will not save. That is a smaller problem on any given day and a larger one over a five-year horizon, because it is permanent and it is not visible until you hit it.

Count your instance: eight checks to run before you commit to a date

Run these against your Data Center instance. Every one of them is a screen you already have. The point is not to find a blocker, because most estates will not have one. The point is to know, before you commit, which of these eight numbers you are close to, so that “we will sort out the configuration later” is a decision rather than a discovery.

Statuses per workflow (limit 200). Administration, then Issues, then Workflows. Open each workflow and count its steps. The workflows to look at first are the ones that have been edited by four different teams: a generic “Task” workflow rarely gets near 200, but a service desk workflow that absorbed a decade of process can.
Workflows per workflow scheme (limit 150). Administration, then Issues, then Workflow schemes. Count the workflow entries in each scheme, not the total number of workflows in the instance. A scheme with one workflow per issue type across a wide issue type scheme is the pattern that climbs here.
Permission grants per permission (limit 50). Administration, then Issues, then Permission schemes. This is the one most likely to surprise you, because it is not counted per scheme. It is counted per permission line. Open a scheme and look at a single permission, such as Browse Projects, and count how many groups, roles and users are granted it. Estates that grant access group by group rather than through project roles accumulate here quietly.
Work item security levels per project (limit 50). Administration, then Issues, then Issue security schemes. Count the levels inside each scheme.
Releases per project (limit 15,000). Project settings, then Releases or Versions, per project. The estates at risk are the ones with automated release creation from a build pipeline, where a version is cut per build rather than per release. Fifteen years of nightly builds is the shape that gets there.
Components per project (limit 10,000). Project settings, then Components, per project. Same pattern, same cause: anything that creates components programmatically.
Field options per field (limit 20,000). Administration, then Issues, then Custom fields, then Configure on each select, multi-select, radio or checkbox field. The candidates are the fields that mirror something external, such as a customer list, an asset register or a cost centre list synced from another system.
Priorities per project (limit 100). Administration, then Issues, then Priorities gives you the global list. If you use priority schemes, which assign a subset of that list to each project, the number that matters against a per-project ceiling is the size of your largest scheme rather than the global list. Most instances are nowhere near 100 either way, so this is a two-minute check rather than an exercise.

Write down the number next to each limit rather than a pass or fail. A project at 12,000 releases passes today and does not pass in three years, and the number is the thing that tells you that. The pass or fail does not.

If this count is part of a wider scoping exercise rather than a one-off check, the Atlassian instance sizing tool takes a description of the same estate and returns a cost comparison alongside a migration complexity estimate. It runs entirely in your browser and sends nothing anywhere, which matters when the inputs are your own licence counts.

Two details worth noticing

Government Cloud is included. Atlassian’s page states the limits apply to “all Jira Cloud instances (including Atlassian Government Cloud)”. The deployment sold to the most constrained buyer Atlassian has gets the same ceilings as everyone else. If you are migrating into Government Cloud on the assumption that its constraints run in the other direction, they do not.

Visibility is not evenly distributed. Writing on the Atlassian Community on 18 August 2026, MeghnaP of LogicLemur Labs makes the point that Standard admins “may not have the same level of built-in optimization visibility available to higher-tier customers”. The limits are the same on every plan. The tooling for seeing where you stand against them is not.

The part that is structural rather than newsworthy

None of this is a squeeze, and a page that told you it was would be wrong. Published guardrails are ordinary platform engineering. A multi-tenant platform has to bound what any one tenant can do to the shared system, and publishing the bounds in advance is the responsible version of that. Atlassian has now done it twice, in March and in September, which also tells you it can do it a third time.

The difference worth understanding is structural, and it is the actual thing you are choosing between. A shared platform publishes ceilings, and those ceilings move on somebody else’s schedule. A platform you run yourself does not have a published ceiling, because the constraint is your hardware and your operational judgement, both of which you control. Neither arrangement is free. One trades a class of operational work for a set of limits you do not set; the other keeps the limits and keeps the work.

Count your instance first. Then decide which of those two you are buying, and against which of the Data Center deadline dates you are actually planning, because they are not all the same clock and not all of them apply to you.

Sources: Atlassian, Data limits and guardrails. Rustem Shiriiazdanov, Actonic, 19 August 2026. MeghnaP, LogicLemur Labs, Atlassian Community, 18 August 2026. Figures verified against Atlassian’s documentation on 1 September 2026; this is a page Atlassian revises without announcement, so check it against the source before you rely on a number.