mchaudhry Thank you SO MUCH for this. 

All the folks reading these threads must see how vocal I have been.

The lesson here is that persistence and respect go a long way toward healthy communication. While Atlassian has appeared very unreceptive to many of us, it is not entirely intentional. We post a lot of requests and comments on the boards and in the project. Sometimes follow-up is required.

I've seen MANY people say that reaching out is ineffective, that Atlassian doesn't listen.

This is a great example of how they do listen, when we give them opportunity and incentive. Never feel like your voice is too small. Never allow yourself to feel helpless, and great things can be done.

This is one of four large issues we were having, and Atlassian really came through for us, once we gave them the opportunity to be aware of our issues.

I'd like to thank Atlassian for making great effort this year to reconnect with their customer base. It's been wonderful!

It should be possible to increase the amount of issues shown in a board, 5000 is not enough. Especially since "Closed" issues are included in the 5000 issues.

Another MUST that is treated lightly by the development/performance department of Atlassian. I wonder if they have certain employees who INSPECT or create cases of new features or improve and recommend new ones. In the end, as with many others, this feature will be part of an add-on/plugin - and Atlassian would say: "Don't get me wrong...we will...bla bla..." => pure sales, marketing, whatever. 

This is insane. We need at least the double amount of issues in a plan, this because we need to coordinate work between project plans and people across the entire company. 5000 issues isn't enough even to make the boilerplate structure for all our projects. It impossible for us to coordinate work in respect of team capacity and projects plan as the limit sits now. Please update!!!

How many votes need to exist here before this gets done? This is utter insanity. You KNOW there are plenty of people... ie: EVERYONE that has migrated to cloud, that wants this. And you've put out many statements about the improved cloud performance. So it makes no sense that you are not addressing an issue so fundamental, nor are you communicating about any plans for it. 

So, allow me to communicate clearly in your absence. We are a 6 figure customer of yours, and because of the recent direction you've taken, the moment I can justify the expense of moving away from Atlassian, I will be advocating the move, unless things change between now and then. This is a MONUMENTAL issue that needs to be taken care of, and you don't even have the common decency to communicate any intent or timeline. 

You know... the thought just occurred to me.

Maybe the reason this is not getting done... is because they can't display more than 5000 issues on THEIR backlog! Can't display them, they don't exist, right?

Logic.

Yet another core feature critical to many of us, removed. What shocks me is that there is no "Buy this add-on to solve this problem". That's a first!

Every single day, we lose functionality, to have it replaced with something non-essential.

• We have a NEW WAY to create tickets... I mean, the old way wasn't broken. But we have a new way. This was CLEARLY a priority over things that disrupt functionality!
• We have a new "TEAM" custom field we can enable. Of course, you could have just created a TEAM custom field... but hey... it was far more important to dedicate person-hours to that custom field, than it is to dedicate those hours to something... you know... important. Like being able to view all my issues in the backlog. Because, who has more than 5,000 issues in a company doing development work?

Oh...  and my favorite part of all this...

We can't display more than 5000 entries (is this 1982?) because of "performance issues"...

BUT

Atlassian Cloud changes Sep 25 to Oct 2, 2023

Searching for issues just got faster in Jira Cloud

ROLLING OUT

We’ve modernized, optimized, and redesigned the way you search for issues. With features like smart syntax highlighting and enhanced autocomplete, the new JQL editor lets you build powerful queries for accurate search results. Configure and reorder columns to see what’s most important to you. Learn more about the new issue search in Jira Cloud

So... Atlassian has, several times over, informed us that they've improved their search and JQL performance... but being able to view 5001 issues from their cloud offering in Q4 2023 still takes too long? So... Atlassian... what you are saying is... you have "modernized, optimized, and redesigned the way we search for issues". But you have not "modernized, optimized, and redesigned the performance of issue searches."

NO ASSIGNEEE... NO ROADMAP... NO TIMELINE... JUST EXCUSES. 

And I don't even understand WHY. (I do. It has to do with bad choices (tm))

I IMPLORE Atlassian to begin dedicating hours to these problems.

Short of that, I would also suggest that people start letting Atlassian know that this is not acceptable. Start migrating those things that you easily can, away from Atlassian, and exercise your spending power to remind Atlassian what is important to us. Little things like choosing not to renew a marketplace add-on through Atlassian with some documentation in your decision, go a long way.

"They don't care what we have to say. They care about how much we're willing to pay!"

Show them that we're not going to continue paying premium fees for a product that keeps outsourcing it's functionality!

And if you can't do that, then join me in being vocal. They know that very few of us can do a 180 and just change direction after we've invested a quarter of a million dollars or more into migrating to their cloud. Or afford the same cost in migrating to a new tool. But they have to know that more and more of us will... at the first opportunity, if Atlassian doesn't start altering course to be more observant of our requests.

I am constantly evaluating new products. And every single time we run into an issue, my suggestion to my coworkers is that we set up a POC to see if it will serve us. 3 years ago, it was more trouble for my users to think about something new. Now? It's more trouble for my users to try to find fixes and workarounds. For every problem we've had in Jira or Confluence since our migration, we've found a less expensive third party solution NOT associated with Atlassian.

We're beginning to build out solutions with partners that "play well together" and remain focused on priorities more aligned with my organization's technical and financial requirements. Little by little. Piece by piece. 

I'm not trying to be a jerk. I'm saying all of this because I like Atlassian's legacy products. I like the ideas and promises they make. And I want to remain an Atlassian customer. But this is not MY choice! This is Atlassian out-pricing themselves and not keeping critical functionality in the product(s). I mean, you can't even remove the borders from a table in their wiki product UNLESS YOU BUY AN ADD-ON anymore!

When is this feature going to be implemented and released?
I have a project where I already have 5400 issues and it is just the middle of the project, most tasks are connected to each other and I can't move some of them to another project to filter issues properly
Also, I have Tempo plugin and 2 projects will not work for it afaIk

Hi - is this going to change? I do understand the need for it and the requirement for the board performance though. Thank you

https://getsupport.atlassian.com/browse/JST-833930

Hi Team, 

this is an essential feature for our company, and we need this to start/complete our sprints.

We migrated to cloud 1 week ago and we used to start sprints for many projects at once, and now we can't keep this behavior on cloud.

currently we don't have any other solution to start a sprint for a large amount of issues.

Please push this feature.

Any idea if this can be pushed up at all please? Thank you

In order to take advantage of Jira's capabilities for some of our core business needs, our program highly values having an aggregate board that pulls everything into 1 place with the ability to filter-down as needed. It would be extremely helpful to have this artificial 5,000 issue limit removed to unlock these important use cases.

Hi - any progress on this? Thank you

I have asked to be connected to legal in this matter, as a denial of service based on a limitation not disclosed when entering a contract is a breach of contract.

Adding a counter and move the responsibility for poor coding to the end users is NOT a technical solution that is acceptable.

We have used Jira server to process multiple projects across a single combined sprint concurrently. It is important that all projects have simultaneous visibility on the Agile Board and the Backlog as Product Owners are responsible for setting priorities across multiple teams and domains. This regularly means a combined backlog of 5000+ cases. The Server version of Jira does not apply this restriction but the Cloud system does, which means that, for my Company, this is actually a regression in functionality. Yes, 5000+ issues is more than a human can handle. Thing is, we use a single backlog that is managed by multiple teams and people so this holistic view is essential.

Please consider this a priority. It is a change in behaviour from the legacy platform and is clearly inconveniencing a lot of people. Otherwise, we'll have to look at Version One or similar.

This causes an issue and hardship on the teams, to have to break down a backlog into separate boards, which then defeats the purpose of teams working from a single source of truth.

Please, asap

+1. This limitation is preventing our teams from fully utilizing Jira Advanced roadmaps using Jira as a tool for capacity planning, dependency management, and roadmapping across large multi department initiatives. We would need the limit to be closer to 30K or 40K.  

+1 - We just experienced this this week. Please advise if there is any timeframe around fixing this? We have an "open" filter that needs to pull based on if assignee set is based on a group of users. Please advise? Thank you in advance

This limitation has caused us to filter down the list to bare minimum that has a major side-effect on the reporting framework that Jira provides. Now we are having to use two boards - one for sprint planning and another one for reporting. Eagerly looking forward to a resolution on this so that we can starting the same board.

I would suggest that you limit the loading of issue to x at a time if it causes performance issues but please do not restrict the count.

Here is the reference for the challenge we were facing and the workaround we are having to live with: [https://getsupport.atlassian.com/servicedesk/customer/portal/48/PCS-7884
]

This is also a major issue within our company and I have been asked by my management team to request that this be escalated and resolved as quickly as possible.

Hello,

I'd like to urge  speed of resolutio on this ticket. Our company Jira is quickly growing to 800+ users with over 50 projects with well over 5K tickets in concurrent sprints. From a planning perspective, it is simply not feasible to handle every individual project and completely lose the program/portfolio overview and control.

Control, metrics, tasks are serious impeded. Confusion is increasing. We're quickly reaching the tipping point of feasibility (e.g, having to search for alternatives). Please get back to me asap.

Thanks in advance!

Bert Lohmann

tel +31 655177676

This restriction has presented us with significant issues in terms of how we plan/manage sprints and we would certainly be in favour of increasing the limit or reverting the change entirely.   As a minimum we would want to see the limit increased to 10000 items.