A practical guide to floating license management on Jira Data Center — with real pricing data, a step-by-step case study for 15,000 users, and the math behind $373,000 in annual savings.

If you've renewed Jira Data Center licenses in the last few years, you know the pattern. For the 15,000-user tier, the numbers look like this:
More than doubled in five years. Atlassian has invested heavily in the platform, but that investment has to land somewhere — and it lands on your renewal. (List prices change regularly; check Atlassian's Data Center Pricing for the latest.)
List price is only part of the story. Most Jira DC costs sit in OPEX, which means they can't be capitalized — they hit the P&L directly, every year. And it's not just the Jira license itself. Third-party apps mostly bill per user as well. When Atlassian raises the tier price, your Tempo bill goes up, your ScriptRunner bill goes up, and suddenly the total cost sits 30–40% above the bare license.
We've seen this catch finance teams off guard more than once. The Jira renewal comes through, gets waved through because "it's the same as last year plus inflation" — and three months later someone notices the Marketplace invoices have climbed too.
There's no single fix, but a few things consistently move the needle:
Clean up your user base regularly. In most Jira instances, there are hundreds of accounts that haven't logged in for months — sometimes years. They still count toward your license tier. A quarterly cleanup sounds unsexy, but it can drop you a whole pricing tier.
Figure out who actually needs a full license. Not every user in your directory works in Jira daily. Some log in once a quarter for a status update. Others have left the company but the account is still active. Separating heavy users from occasional ones is the foundation for everything else.
Charge costs back to the teams creating them. Once departments see their actual share of the Jira bill, behavior changes. We've seen teams voluntarily clean up their own inactive accounts once cost-center allocation made it visible.
And then there's the big lever: floating licenses. Instead of paying for every user in your directory, you optimize how many licensed users you actually need — with licenses assigned and released dynamically based on activity. That's what the rest of this article is about.
Before we dive into floating licenses, it's worth looking at who's actually in your Jira instance. In a typical 15,000-user setup, we roughly see five groups:
Admins manage the instance — they need permanent licenses, no question. But that's usually fewer than 50 people.
Heavy users live in Jira all day. Developers, project managers, scrum masters. They create issues, maintain boards, run queries. Permanent licenses make sense for this group too.
Management / VIP users check dashboards, review reports, approve things. They log in a few times a week, sometimes less. Full licenses for this group are expensive relative to actual usage.
Standard users work with Jira regularly but aren't in it every minute. They update their tickets, check the sprint board, log some time.
Occasional and inactive users — the silent majority in many instances. People who log in once a month, or accounts that haven't been touched in two years because someone changed departments — and no one touched the account. These accounts cost the same as the most active developer on your team.
Groups three through five are where the money is. They make up the bulk of the user count but only a fraction of actual concurrent usage. That's exactly the gap floating licenses close.
You'll need the VIP.LEAN Floating Licenses app, installed on your Jira Data Center instance.

We offer a free 3-month trial license so you can dial in your optimal setup before committing. This trial period matters — rushing it leads to either too many licenses (wasted money) or too few (locked-out users).
First, identify which users should be managed through floating licenses. In a 15,000-user instance, you'd typically keep admins, technical/API users, and your most active heavy users outside the floating pool. In our example, that leaves around 14,500 users to be managed dynamically.
Create two Jira groups:
Install the trial license for 15,000 floating licenses. Move the 14,500 users into "jira-virtual-users." From there, here's what happens: when one of these users logs in, the app automatically assigns them a license and adds them to "jira-software-users." Once they've been inactive for a defined period — we usually start with 60 minutes — the license is released and made available to the next user.
Visibly, nothing changes in the first few days. Everyone can log in as usual. The app just tracks usage patterns in the background.
Now it gets interesting. Start reducing the available floating licenses from 14,500 step by step — we typically drop by 200–500 per week, depending on the usage pattern. Watch whether anyone gets rejected at login or complains.
In our experience, many organizations land at around 3,500 concurrent licenses to comfortably serve 14,500 floating users. That's roughly a 4:1 ratio — a number we see across many enterprise setups.
If users do get rejected at login:
The goal isn't to squeeze every last license — it's to find the point where no one notices the system is running at all.
Say you land on 4,000 concurrent licenses for your 15,000 users. You buy the VIP.LEAN Floating Licenses app for 15,000 floating users and keep a 3-month observation window to confirm the numbers.
After that, you reduce your Jira Data Center subscription from 15,000 down to the license tier that matches your actual need. The math:
USD 604,000 (15,000 users) → USD 231,000 (reduced tier) = USD 373,000 in annual savings
This isn't a theoretical number. This is what happens when you stop paying for 11,000 users who aren't logged in.
Floating licenses work best when there's a large gap between total user count and peak concurrent usage — and that's the case in most enterprise Jira instances. If your 15,000 users are all developers working eight hours a day in Jira, the ratio won't be 4:1. But that's rarely the reality.
The 3-month trial exists for exactly this reason: measure first, then decide. The data tells you whether the savings are there.