Hi everyone, I’ve been working with Jira for managing projects, and as the number of issues and workflows grows, I’ve started noticing some performance slowdowns and difficulty keeping everything organized. I wanted to ask the community: * What are your best practices for handling large-scale projects in Jira? * Do you recommend splitting into multiple projects or keeping everything centralized? * How do you manage workflows, boards, and automations efficiently at scale? I’m especially interested in real-world experiences—what worked for you and what didn’t. Thanks in advance for your insights!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices for managing large-scale projects in Jira without performance issues?

Anna Wilson_3pwqr8

Hi everyone,

I’ve been working with Jira for managing projects, and as the number of issues and workflows grows, I’ve started noticing some performance slowdowns and difficulty keeping everything organized.

I wanted to ask the community:

What are your best practices for handling large-scale projects in Jira?
Do you recommend splitting into multiple projects or keeping everything centralized?
How do you manage workflows, boards, and automations efficiently at scale?

I’m especially interested in real-world experiences—what worked for you and what didn’t.

Thanks in advance for your insights!

Accepted answers

Trudy P Claspill

Hello @Anna Wilson

Welcome to the Atlassian community.

Another factor to consider is the number of issues in your system. As the number increases, searches slow down. One way to mitigate this is to Archive older projects and/or older individual issues. The issues/projects archived can still be viewed if you have a direct link to an issue, but the data can't be changed. And the issues are removed from the index which improves the performance of searches.

All comments

Fabian Lim

Hi @Anna Wilson ,

Welcome to the community!

The approach will largely depend on how the organization and its teams collaborate. If the teams share the same members and there are no concerns around access restrictions, consolidating work into a single project is a viable option. In that case, you can leverage custom fields such as Components or Teams to logically separate work streams and sprints.

For Data Center environments, a key performance consideration is to minimize the number of custom fields and make use of field contexts to scope them appropriately.

Regarding workflows, the recommended practice is to keep them as generic as possible so they can be reused across projects. However, once a workflow becomes unique to a specific team's process, that is typically the point at which it makes sense to break the work out into a separate project.

Having a lot of plugins also slows down the system significantly as well.

Regards,

Fabian

Trudy P Claspill

Hello @Anna Wilson

Welcome to the Atlassian community.

Anna Wilson_3pwqr8

Thank You so much for your help.

Anna Wilson_3pwqr8

Thanks Fabian, that’s actually really helpful context.

The point about keeping workflows generic until a team’s process truly diverges makes a lot of sense. I also hadn’t considered how much custom fields and plugins can impact Data Center performance over time, especially at scale.

Using Components or Teams for separation inside a shared project seems like a cleaner starting approach before splitting things into multiple projects too early.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

data-center

jira-service-management

jira-service-management-data-center