• Community
  • Products
  • Jira
  • Questions
  • Best way to set up & manage a very large number of small projects? Individual JIRA/GH projects or Epics within one project?

Best way to set up & manage a very large number of small projects? Individual JIRA/GH projects or Epics within one project?


Just wondering what the best way would be to organize, set up and manage a very large number of small projects in Jira/GH.

We are anticipating to have a large volume of projects, say 1-2 new projects each week. Each project would typically have less than 100 issues. Then after the initial active development (which would last 1-2 weeks) they'd be largely dormant, except for maybe < 5 or so maintenance issues per year. Logically, since each of these projects are for individual clients, they should be separate Jira/GH projects.

However, my concern is how would Jira/GH cope over the years as the number of projects increases? Say over 300+ projects? Can Jira/GH scale to cope with this?

What alternatives are there? Maybe having 1 large Jira/GH project, but Epics for individual client projects? What would be the disadvantages of this approach? Obviously the integration with Confluence which is used to manage requirements specifications etc, would become less effective.

Looking forward to hearing your thoughts.


2 answers

1 accepted

2 votes
Answer accepted

One thing to keep in mind that there does not need to be a 1-1 correlation between a "Project" in JIRA and a "Project" as in Project Management. In JIRA, it is often better to have projects be aligned to products, libraries, or code bases that tend to have long lifecycles. Project Management Projects by definition have a discreet time duration with an end - but that end does not signfy the end of the products lifecycle.

You should pare down the number of Projects in JIRA based on that consideration. Traditional projects may be aligned by the use of Versions (i.e. releases) or possibly Epics or a combination of those and other things like components. You may also use a custom "Project" field to designate as well.

Thanks Chris. I think Epics might work well for the number of projects that we have. Certainly saves admin time, ie creating projects etc.

Probably it won't. It will be a good idea to keep regular backups and JIRA database and delete of the projects. So that in case you need to get some old data, you can always restore the database to another instance and refer the data.

There is a JIRA archiver which is being planned, if interested in evaluating you may contact Roy, refer - https://jira.atlassian.com/browse/JRA-5843

The other alternative is to use a single project as you mentioned and handle teh customer as a component or a custom field drop down. Or even a label as this removes administrative overhead.

Thanks for that info Renjith. What is the reason you think Jira/GH won't necessarily cope? Is it because there is a large overhead with each Jira project?

While I do not have a direct mapping on the number of projects to JIRA performance, in general it affects as the project size increases. Also the amount of references to various schemes stored will start increasing with the number of projects.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Thursday in Jira

Updates to jira.atlassian.com give you visibility into what's coming in Jira Server and Data Center

Hello, Community! My name is Gosia and I'm a Product Manager on Jira Server and Data Center here at Atlassian. Since 2002 when we launched our public issue tracker, jira.atlass...

319 views 1 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you