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.
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:
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.
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.
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:
In this article, we will focus on the second factor: reducing the impact of occasional users and inactive users on your license.
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.
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:
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.
In the example above, you may realize that:
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.
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.
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.
First, sort users in 5 buckets depending on their activity:
Then, simply apply these license optimization rules:
|Account bucket||Deactivation options||Benchmark||Comments|
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.
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.
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.
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.
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.
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.
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.
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.