Empowering Jira admins to optimize usability at scale

[#1]

Introducing new limits, guardrails, and data management tools for the Jira Cloud family of apps to make it easier than ever to manage your data

Hello, Atlassian Community!

We’re excited to announce several new ways to improve working in the Jira Cloud family of apps at scale.

The newly published guardrails, upcoming data limits, and fresh data management tools for Jira, Jira Service Management, and Jira Product Discovery are here to help you manage your data shape and environment.

As your Jira sites grow, so does the complexity and volume of your data. Over time, things like custom fields, work types, and statuses can accumulate and make it harder for users to find what they need amidst all the content. This growing data can also lead to slower performance, making it harder for teams to be efficient.

To address these challenges and support your growth, we’re rolling out:

• New limits: Starting February 2026, the Jira Cloud family of apps will enforce new hard limits on certain data types, including custom fields and work types per project. These limits are designed to prevent performance slowdowns and ensure a smoother user experience.

• New published guardrails: By popular demand, we’ve released new guardrails—recommended thresholds for data volume and configuration. These best practices help you keep your sites healthy and high-performing.

• Enhanced data management tools: We've launched improved data cleanup tools, available for all customers, to help you find and easily manage unused or outdated data. Use these new tools to archive old work items in bulk, clean up unused custom fields, and remove outdated projects.

  • Optimize field configuration schemes

  • Optimize work types in a work type scheme

• Site Optimizer for Premium customers: Now available to enterprise and premium customers, Site Optimizer provides actionable insights and recommendations for cleaning up your site.

Limits vs guardrails: What’s the difference?

• Limits are software-enforced ceilings for data usage. If you reach a limit, the Jira apps will prevent further actions until you remediate.

• Guardrails are recommended best-practice thresholds that, if exceeded, are likely to impact performance. These are not enforced, but we strongly advise staying within them for optimal performance.

What are the new limits and guardrails?

Type	Entity	Limit or Guardrail Value
Limit (enforced starting Feb. 2026)	Fields per project	700
Limit (enforced starting Feb. 2026)	Work types per project	150
Guardrail (best practice; not enforced)	Work items per site	18,000,000
Guardrail (best practice; not enforced)	Projects per site	8,400

Adhering to the limits and guardrails

Customers on the enterprise and premium plans can easily view their data usage and clean up unused entities using Site Optimizer.

Additionally, we have recently rolled out new data management tools in the Jira Admin screen to help all customers understand their site usage.

The new field configuration schemes page, seen above, will show the number of fields included in your site. It will also let you know if you're approaching the limit, and offer ways to clean up unused data across projects. We have also released this feature for managing work types.

Improving usability at scale

As sites grow, well-managed data reduces search time and increases productivity; no more scrolling through endless custom fields or scrubbing duplicate work types to find what you need. We’re pleased to share these updates as new ways to improve the Jira Cloud family of apps' usability and make teams more efficient. And, for scaling enterprises, limits and guardrails ensure your Jira sites can grow with your organization, especially at 100k users, without sacrificing speed or reliability.

Limits and guardrails are two sides of the same coin, both focused on delivering a scalable, user-friendly, and performant experience. We encourage all admins to review the new documentation, assess your current data, and take action to clean up your sites ahead of the limit enforcement next year.

Thank you for partnering with us to improve the Jira apps for everyone. We’re committed to helping you scale confidently and keeping your teams moving fast!

[Hubert Kut]

We know how important data governance is and how crucial it is to keep Jira instances in good shape as they scale.

That’s exactly why we built Doctor for Jira 🩺 — to help customers with a full instance analysis in just one click, showing all objects across projects and allowing you to clean them up automatically.

Our goal is to support admins in keeping their environments healthy, compliant, and ready for growth. 🚀
You can even try it out with a free 30-day trial and see the impact yourself.

[Joerg]

Hey,

I like it a lot.

Over the last decade or so, we always had the problem of having a need for multiple Jira admins, sometimes with different philosophies when it comes to customfield governance and specifically naming (naming genericism vs. naming clarity). 

A few migrations later (Datacenter to Cloud, and Cloud to Cloud), and we have a huge mess on our hands.

Although to really make informed decisions about removing customfields, there is important information missing in the customfield optimizer:
Creation date and author.

Example: A field that was created 3 years ago and still does not hold any data, can probably be safely deleted, but a field that was created yesterday or a month ago might obviously be missed if deleted. Knowing who created the field can give it additional context as well.

[Fernando Eugênio da Silva]

Hi @Mel Policicchio , super thanks for this article the these instructions are very necessary and helpful when we are talking about performance and scale.

One question here, please: For Fields per Project limit, you're assuming that each project has their own Field Configuration Scheme, is that right?

If there is a case of many projects uses the same field configuration and the number of fields added into this field configuration is higher than 700. What would happen? All associated projects it will be limited to add more fields at their scopes? How can we measure and evaluate this?

Thank you!

[Anwesha Pan (TCS)]

Thanks for sharing this article @Mel Policicchio :) Very informative

[Pavel V]

Hi @Fernando Eugênio da Silva, the limit is applied on a field configuration scheme level, meaning you won't be able to add more than 700 to a single field configuration, or a single field configuration scheme.

We are now rolling out UI changes where you will see a preview of what exactly is going to happen in February and what will be limited.

Pavel

[Pavel V]

Thanks for the feedback @Joerg, I will see if we can surface this information. P

[Joël Kemnitzer]

Hi @Mel Policicchio 

thanks for sharing this.
How about team-managed projects and their created custom-fields?
Does they count against the limit, too?

Thanks in advance,
Joey