A simple framework to free up unused Atlassian licenses
When you’re running Atlassian on-premise applications, it’s important to stay on top of how many user accounts you have and how that impacts your investment in data center or server. This is especially true given the recent price surges. To help keep your license cost down and prevent any surprises, in this blog we will go over what factors affect your license price and show a simple framework to minimize the number of licensed users so you can stay within budget.
How to calculate Jira license cost for your company
Licensing costs for Jira Server and Data Center customers depends on the number of users in the system. This can be said for all products in the Jira family, like Jira Software and Jira Service Management — but applies additionally to any other Atlassian application.
Your license price will go up with an upgrade only when you exceed certain thresholds in the overall user count. For example, customers with 250 and 450 users pay the same, but both will start paying more once they reach 501 users.
Whenever your team gets requests to provision more users, they should have this in mind.
This means that proper Data Center license management customers requires:
- Predicting when you will exceed your current user tier.
- Controlling how many users actually need a license.
If you follow the process that we describe in this article, you may even be able to convince procurement officers that you are effectively obtaining a discounted price compared to what would have happened with automatic renewals of your account.
Controlling your Atlassian Data Center budget will also help you justify any changes to upper management in the case of new price surges or unexpected changes.
Current cost of Jira Data Center licenses
Self-hosted Atlassian applications don’t have a calculated price per user. Rather, Data Center has different user tiers with a fixed within each of them. The lower tier from 1-500 users starts at 42k USD for Jira Software, bouncing upwards of 885k for unlimited licenses with more than 50,000 users. All these prices are recurring annual subscriptions, resembling very closely classic SaaS subscription models.
You can see all the details here for Jira Software. Click on the image for more details.
Calculating licensing cost per user in Jira Data Center
Answering the question How much does a user cost? can be trickier than it seems. The formula is the simplest you could think of:
License price / number of users
However, the number of users changes all the time — particularly, in large organizations. There are two factors that make it hard to estimate what the number of users will be in, say, 9 months from now:
- knowing how many users will be added and removed
- understanding who is an active user — and who has access to Jira but never goes in.
In this article, we will focus on the second factor: reducing the impact of occasional users and inactive users on your license.
Coming price surges in Data Center licenses
There is a strong enemy of your budget for Atlassian tools: at some point, Atlassian will change the prices. You know that it will happen, but you may not know exactly when.
However, you can have an idea looking at what’s happened in the past.
The last pricing changes for Data Center licensing came into effect on February 2, 2021; and before that, in October 3 2019. There’s currently no announcement of upcoming changes, but it wouldn’t surprise me that there is one once the old Server option disappears from the market in 2023.
Preventing the move to a higher user tier
While you can’t control price changes by Atlassian, it is in your hands to make sure that you don’t end up paying for user accounts you don’t need.
With this goal, we recommend comparing three numbers:
- How many active users you currently have
- How many user accounts are currently provisioned
- What’s the limit for your current user tier
If the number of user accounts (2) is very close to the tier limit (3), then you have to be particularly vigilant, as the budget could skyrocket soon.
For example: if you have 480 users growing at a steady rate of about 50 a year, you know that, unless you do something about it, your instance will be jumping to the 501-1000 user tier sometime next year.
It’s a very common scenario with an imminent jump in price:
What many customers don’t realize is that this moment can be postponed for a very long time.
In this scenario, there is a healthy distance between the user tier
threshold and the actual user accounts:
That’s only possible because real active users (1) are constantly measured and the user accounts optimized accordingly.
How to determine how many of your users are active
In the example above, you may realize that:
- out of the 450 existing user accounts, only 385 have an active status in Jira. (you can see this in path)
However, a user that has never used the app can have an active status: it would be a false positive.
With User Deactivator, you can easily query your user database in Jira to check which users have done something in the app in the last three months. Or even every week.
The result:
- out of the 385 active accounts, 315 accessed Jira in the last three months, but only 180 go into Jira every week.
These numbers give a better sense of how many licenses are strictly needed in your organization.
Let’s have a look at a simple procedure designed to revoke access entirely when a user will never have the need for it, while preserving the right to access the application to those who will eventually need it.
A simple framework to deactivate users without removing access
Prerequisites
To follow this framework, you will need to have installed resolution’s User Deactivator, which is available for Jira, Confluence, and Bitbucket in the Atlassian Marketplace.
It’s also recommendable to combine it with the benefits of resolution’s SAML Single Sign-On app.
The framework
First, sort users in 5 buckets depending on their activity:
- Ghost accounts. Accounts which have never been used in the past and will never be used in the future.
- Former users (mummy accounts). These accounts have been active in the past, but will never be used again for any reason (retirement, job change, etc.)
- Fake active users (zombi accounts). These accounts have an active status in the application, but no real activity in a reasonable amount of time (for example, 3 months)
- Occasional users (sloth accounts). These users don’t go into Jira or Confluence every day, but rather when they are asked to do so or have a specific need. For example, requesting vacation days or checking very specific instructions for their job.
- Active users. These users go into Atlassian application every day or at least once a week. Some of them may even be power users.
Then, simply apply these license optimization rules:
| Account bucket | Deactivation options | Benchmark | Comments |
|---|---|---|---|
Ghost accounts | Delete the accounts | Easily around 1-5% in larger companies. Should be triggered as soon as license utilization becomes a problem. | With no historic activity, account deletion is safe. |
Mummy accounts | Deactivate the accounts. See different options here | Lingering access is a critical security risk. Anything over a 0% would be dangerous. Deactivation must occur immediately for each user after it has left the company. | Keeps links and historical actions in Jira and Confluence. Doesn’t consume licenses. |
Zombi accounts | Deactivate the accounts (with SSO) Optimize license utilization | Many accounts are rarely used once provisioned, but may still need access in the future. This bucket can be as high as a 30%. | Combined with SSO, deactivated users can automatically regain access when they first attempt to login again. In absence of SSO, it’s recommendable to optimize license utilization instead. |
Sloth accounts | Deactivate the accounts (with SSO)Optimize license utilization | 15-50% It is estimated that even in companies with a very strong Atlassian culture, at least a 15% of the users do not go into the applications more than once a week. | Occasional users are the larges opportunity to prevent undesired license upgrades. It is always recommendable to optimize their license utilization to align active users and provisioned accounts. |
Active users | Do nothing | Should be as close as possible to the actual number of provisioned accounts. Without optimization actions, this number is usually around 40-60%. | Active users should not be optimized unless your user tier is about to explode. |
In summary:
- Ghosts will be simply deleted and mummies deactivated, as they will no longer need access.
- Zombies may and sloths will need access in the future, so they require a more subtle approach to deactivation that doesn’t remove access entirely.
For existing customers of our SAML SSO app, just in time provisioning can be used to reactivate a deactivated user with the subsequent login attempt. The user will not even notice that the account had been deactivated.
However, if your company is not currently using our SAML SSO app, there’s an equally effective solution called license optimization. As in the example above, users will not experience their deactivation – in fact, they will never be deactivated.
How to optimize licenses while maintaining access
The License Optimizer is shipped since version 4.6.0 of User Deactivator. It will save the amount of licenses consumed in your company without actually preventing anyone from accessing Jira or Confluence when they need it.
This is what you need to understand about the License Optimizer: users only consume licenses while using the application. When not using the application, users are removed from the group that consumes licenses without deactivating them.
That’s why the License Optimizer eliminates the risk that Zombi accounts and Sloth accounts can overflow your current user tier.
This is how it works in more detail:
If you’re interested in setting it up in your company, you can share the Admin Guide with your Jira or Confluence Admin.
Conclusion
If you’re concerned about requesting additional budget for your Atlassian applications because of a surge in user accounts or upcoming price changes, perhaps it’s time you put our license optimization framework to test and see the benefits for yourself. If you need help setting it up, we recommend talking to Atlassian partners
Sometimes, a refusal for additional budget can be the spiraling moment that ends up in a painful migration to a competitor or to equally concerning cuts in other essential budget items.
In the current climate, having a stable budget for your internal stack will help you provision funds to more important innovation projects, the raises that your team deserves, or any unforeseen expenses.
