Last reviewed: February 20, 2023

Is Jira Data Center more expensive than Jira cloud?

In short: yes, almost always.

But how much does a user cost in Jira Data Center? It depends: Not less than 18 dollars for Jira Software, and as much as 344 per agent on Jira Service Management’s starting tier. That’s a wild range and it’s hard to compare exactly, although it’s generally safe to say that the cloud prices are generally lower, with a Premium plan that starts at 15.25 dollars and becomes cheaper as you add more users.

When you’re running your Atlassian applications on Data Center, the price of your licenses will not be calculated based on flat price per user, like in Jira or Confluence cloud. However, a difference of just one user can force you to upgrade, increasing your Atlassian licensing costs in thousands of dollars. That’s why you should monitor very closely how your Data Center licenses are consumed.

In this blog we’ll go over the current pricing of Jira Data Center licenses, show you how to calculate the price per user that you will pay, teach you strategies for getting discounts, and share a simple framework to recycle your licenses and prevent unnecessary upgrades.

Tier structure and starting prices

Jira Data Center pricing is structured in user tiers. The smaller user tier for Jira Software is up to 500 users and costs 42,000 USD per year, whereas for Jira Service Management it’s up to 50 agents and 17,200 American dollars.

Below are pricing tables for all user tiers in Jira Software Data Center and Jira Service Management Data Center. As an indication, we have included a column with the cost per user for each tier, assuming the maximum number of users for that tier (for example, 500 users in the first tier).

Full pricing tables for Jira Data Center

Current cost per user tier of Jira Software Data Center licenses

Current cost per agent tier in Jira Service Management Data Center

Current cost per user tier in Jira Work Management Data Center

Jira Work Management is a cloud-only product and Jira Core, its server version, is also not available on Data Center. So no table here.

Changes in the cost of Data Center licenses over time

There is a strong enemy of your budget for Atlassian tools: at some point, Atlassian will change the Data Center prices. You know that it can happen, but you may not know exactly when. Here’s a summary of the most recent history.

Price increases for Jira Software Data Center since 2019

Here is a table with the last price changes of Atlassian Data Center applications. We will only take the prices in Jira Software as an example.

Price increases in Advantage Pricing

Advantage pricing is designed to help existing customers absorb the impact of Data Center price increases, which can be quite dramatical. The prices are cheaper than the prices listed for new customers, and will gradually reach an equal footing with them.

In the tables below you can see a sample of the latest changes in advantage prices, and their relationship to the current list price.

Advantage Pricing for Jira Software Data Center

Advantage Pricing for Confluence Data Center

Source: Atlassian Future Pricing

How to calculate your cost per user in Jira Data Center

The cost per user is a useful metric of how much value you’re getting for your dollars, and can be obtained with a simple formula:

License price / number of users

This means that, for every tier, the cost per user depends on the actual number of users, and is actually a range. Here is a sample of the current Jira Software prices, and those ranges.

Ranges in cost per user per tier, Jira Software Data Center (sample)

As you can see, being in the lower end of a user tier sucks: you will get the exact same functionality, but will start paying a lot more per user than before the upgrade. On the other hand, being on the upper end of a tier is a better deal in terms of cost per user; but it’s also risky, because a few activations can trigger an upgrade.

To add complexity to this calculation, both variables in the formula for calculating the cost per user can fluctuate a lot: as we just saw, Atlassian has hiked license prices every other year for Data Center; and active users come and go.

To accurately calculate your cost per user, you should start by following this process:

1. Estimate how many people will have access to Jira. Obviously, the same calculation would work for Confluence. This will determine your user tier. If the answer is: everyone should have access potentially, then have a look at this guide on universal user provisioning with conditional licensing.
2. Check whether any discounts are applicable, including loyalty discounts for Server customers and advantage pricing for Data Center renewals.
3. Check whether Atlassian has announced any upcoming price changes. The last one was the change of the advantage plans on February 15, 2023.
4. Divide the final price for that tier by your estimate. For example, if you estimate 250 users for Jira Software and you are not eligible for any discounts, you will have to divide 42,000 USD / 250 = 168 USD per user.

Factors than can impact your Atlassian budget in the future

Once you have the initial price and the initial cost per user, you know what your Atlassian budget will look like… for now. But bear in mind that, as the license price and the number of users change in the future, so will your budget.

Here are some of the the main factors that can drastically impact your starting Atlassian budget in future fiscal years:

New pricing changes

This is a purely external factor, and there is little you can do to change it or forecast it with any accuracy. We don’t know what Atlassian will decide in 2026. However, a look at the pricing tables at the start of the article will give you an idea of how frequently does Atlassian review its prices, and you won’t be that surprised when you read the next announcement.

To summarize: the last price increases went into effect in 2019 and 2021, with some additional adjustments for Advantage plans in 2023. I wouldn’t expect new increases this year, but I would be surprised if we don’t see any news around the end of 2024.

Mergers and acquisitions

There is possibly not much you can’t do to control this aspect either. However, if you’re company is on a buying spree, you probably know that your Atlassian budget can change drastically anytime.

Fluctuations in the number of active users

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.

At the end of this article, we will teach you how to proactively reduce the impact of occasional users and inactive users on your licensing.

What’s important to know is that, for know, you should always the following question in mind whenever your team gets requests to provision more users,

How many users until we reach the limit for our tier?

While you can’t control how many new people join the company, there is a lot you can do as a Jira admin to stay on top of the instance. Rather than wait for the upgrade to arrive, you can proactively keep it at bay… until the time has finally come.

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:

1. How many active users you currently have
2. How many user accounts are currently provisioned
3. 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. Having a healthy distance between the user tier threshold and the actual user accounts results in a very different chart:

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.

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. This will for example allow deactivated users to sign in seamlessly as soon as they try to access Jira again.

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 this 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.

Prevent guest users from consuming licenses

Guest users also eat up licenses

You want to collaborate with partners, customers, contractors, or agencies. Unfortunately, collaborating in your Jira instance with users from other organizations is not that simple.

For starters, the concept of a guest user doesn’t exist in Jira. Any collaborator from a different organization will consume a license – even if you give them read-only permissions.

To add insult to injury, giving restricted permissions to a changing number of users is the high maintenance, high error kind of task no admin wants to be in charge of. And I don’t blame them.

In my experience your admin will not approve creating a new user unless there is a very strong case, so you will end up collaborating outside of Jira. And this is how silos, blind spots and bottlenecks emerge in your otherwise visibility-driven process.

Guest users – the early access feature in Confluence Cloud

In 2021 a new beta feature of guest users was announced for Confluence Cloud. As of June 2022, it still is in early access and closed to new customers.

While the announced feature solves the administration problem pretty well, it does not solve the licensing problem. Guest users will still consume licenses.

Sharing Jira with external users without creating an account

But there’s another option. External Share for Jira and External Share for Confluence are Atlassian Marketplace apps that enable you to share secure, unique links to your Jira issues or Confluence pages with whomever you choose.

Using External Share makes a lot of sense if you’re sharing a single Jira issue or Confluence page with a partner, customer, or someone from another team. You certainly don’t want to have to buy a whole license when your guest user only needs to see one issue or page from time to time.

That said, if you do need to share a bunch of issues or pages, you still don’t need to buy a license, because External Share lets you do it. In External Share for Confluence, you can enable the sharing of child pages and share a whole page tree. In External Share for Jira, you can create an External Share link to a list of issues using Jira Query Language (JQL).

External Share links allow collaboration to continue inside Jira and Confluence while keeping your content secure. The shared links have hard-to-guess 16-character URLs that can be protected further by adding time limits and passwords. External users cannot edit the body of the issue or page, but you can enable them to add comments and attachments. You can also let them transition Jira issues between statuses, so when a contractor has completed a task, they can move it to “done” and save you doing it.

Most importantly, these are live links. So when the issue or page gets updated, the external user will see the changes as soon as they refresh the page. So, no more of this nonsense.

You can get an idea of how much money External Share can save you on licenses using Old Street Solutions’ External Share Return on Investment Calculator.

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 Solution 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.

Start recycling licenses

No matter your tier, setting up a license recycling framework like the one described above can only benefit on the long run. Try out User Deactivator and talk to our support team if you have any doubts about the setup!