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.