Deploying JIRA in the Enterprise: Sizing JIRA

Deploying JIRA in the Enterprise – Part 2: Sizing JIRA

This article is the second of a series of three about managing JIRA instances inside the enterprise. This is based on resources from the Atlassian Documentation (here) as well as our knowledge as Atlassian Experts.


JIRA growth

When we install JIRA, it is most of the time to fulfill a specific use case for a team or a particular department. After that, it is common to see JIRA spread within the company as new departments adopt the tool, other companies using JIRA are bough or new use cases arise.

It is important to think about sizing JIRA before you deploy it in order to be prepared for these changes. First, you need to think about how many JIRA instances you will need to cover all your needs. For example, you could need a public JIRA instance open to your customers (accessible through the internet) where you wouldn’t like to store internal data for security reasons.

Some use cases of JIRA mean you will need to get a new license. This is because some items in JIRA are common to all the projects: users, groups, roles, priorities, plugins, application source code, number of custom fields, etc. Gathering multiple (and totally different) use cases on the same instance can quickly become annoying for users, and even administrators.

That said, proliferation of JIRA instances inside a company also raises some important issues:

  • Each JIRA instance requires a license and some specific environments (see previous article)
  • Each paid plugin requires a license per instance
  • With different instances and URLs it is not always clear to the user which instance should be used
  • JIRA Administrators have to maintain several platforms instead of one
  • User management is more complex (unless you use Crowd or some LDAP)
  • It is not possible to easily export some JIRA configuration from one instance to another (except for workflows using the Workflow sharing plugin)
  • Upgrades need to be done on each instance

It is up to you to consider the technical issues described above. Please note that it is also possible to merge two existing JIRA instances together (if you purchase a company with their own JIRA or to reduce costs) using JIRA project import.

Technical recommendations

The technical architecture of your JIRA platform needs to be able to evolve when necessary in order to guarantee data security and acceptable performance. You can start by following Atlassian’s guidelines: 200 000 issues per instance maximum (up to JIRA 5.0 included) or 500 000 issues maximum (from JIRA 5.1 included). We already have clear criteria to split an instance in 2 (or more).

In order to correctly size your JIRA architecture, you first need to estimate (from an existing system if possible):

  • The number of frequent and occasional users
  • The number of initial issues
  • The number of new issues each month

From this, you can select your server based on Atlassian hardware recommendations. To plan for architecture changes, Atlassian supplies a plugin called Data Generator. This plugin will allow you to run performance tests by filling your instance with fictional data matching the volumes you expect.

Cutted Triangle

Subscribe to the Valiantys Newsletter

Registered request ! Subscribing... This is not an email An error occured

In accordance with our privacy policy, we are committed to respecting your personal data.

Contact us

Our Atlassian certified consultants will be happy to answer you.

Join us

We're building the next dream team - Are you in?

Follow us

We use cookies for the operation of our website. This is to improve its use, to personalize your experience, and to compile visitor statistics. By continuing to use this site, you consent to this policy. You can manage the settings and choose whether or not to accept certain cookies whilst browsing. For more information, see our privacy policy. Our privacy policy

Privacy settings

In order to facilitate your navigation and to provide you with the best possible service, we use cookies to improve the site to the needs of our visitors, particularly according to the number of visitors. For more information, please read our privacy policy. Our privacy policy


Google reCAPTCHA is a system designed to distinguish humans from computers, so that bots are unable to maliciously fill out forms on behalf of a human being.


Used to send data to Google Analytics about the visitor's device and behavior. Tracks the visitor across devices and marketing channels. Used by the social sharing platform AddThis to store the user's usage history of the AddThis sharing widget. Registers a unique ID that is used to generate statistical data on how the visitor uses the website.


Targeting Cookies: Targeting cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant advertising on other sites. They are based on uniquely identifying your browser and internet device. You can turn off the use of cookies for targeted advertising here. When the button is green, targeted cookies are on. When the button is red, targeting cookies have been turned off.

Social Media Cookies: These cookies are set by a range of social media services that we have added to the site to enable you to share our content with your friends and networks. They are capable of tracking your browser across other sites and building up a profile of your interests. This may impact the content and messages you see on other websites you visit. If you do not allow these cookies you may not be able to use or see these sharing tools.