One user crosses a threshold and every installed app reprices at once
Marketplace apps must license to the same user tier as the Atlassian product they extend, which means you cannot buy an app for a department and cannot buy it for adopters only. The user count becomes a multiplier across the entire app portfolio, and on mature estates that portfolio rivals the core licences while almost never being benchmarked as one number.
Prepared by Redress Compliance · August 10, 2026 · Atlassian advisory. Based on 15 to 25 Atlassian estates reviewed, 2024 to 2025.
Executive summary
Tier matching means you cannot license an app for a subset, which is the most surprising cost rule for buyers. If the host product is licensed for a given user band, every paid app must be licensed for that band too, even where only a handful of people use it.
There are no partial seats and the rule applies to each paid app independently, so a niche tool bought for one team is priced against the whole population and compounds across the portfolio.
Crossing a tier raised total app spend 15 to 30 percent in a single step. Because every paid app tracks the host tier, adding a handful of users can lift the host licence and several app licences in the same cycle.
The jump usually appears only on the next invoice, and shedding users later does not always drop you back a band cleanly, which makes the threshold a one way door in practice rather than a symmetric boundary.
Estates ran two or more apps covering the same need, with 10 to 20 percent of app spend duplicated. Overlap survives because apps are approved individually, on small line items, by people who are not looking at the portfolio.
Combined with tier waste, where apps are licensed to the full user tier while only a minority touch them, that is the recurring structural loss, and neither is visible from any single renewal.
App spend rivalled the core licences on mature estates, yet it was scattered across dates and never benchmarked. Annual app renewals stack on different dates, which hides the total and weakens the negotiating position on every one of them.
The counter is portfolio management rather than sharper individual renewals: inventory every paid app, align the renewal dates, benchmark the portfolio as one number against the host tier, and cut the overlap before the next threshold lands.
Where the cost steps up
| Driver | What happens | Buyer impact |
|---|---|---|
| User tier crossed | All paid apps reprice | Step increase across the whole portfolio |
| New paid app added | Licensed to the full tier | Cost for all users, not adopters |
| App overlap | Duplicate capability | The same need paid for twice |
| Split renewals | Dates scattered | Total cost obscured, negotiation weakened |
The threshold effect is felt many times over, because the host product and every paid app reference the same band.
One trigger lifts the host licence and each app licence together, the jump often appears only on the next invoice, and shedding users afterwards does not always drop you back a band cleanly.
That combination turns a routine hiring decision into a portfolio wide repricing event that nobody approved as such.
The useful discipline is forecasting rather than reacting: track active user count against the next threshold and model the full portfolio reprice before approving new seats, which converts a surprise into a planned decision that can be timed, staged, or offset by a cleanup.
The host pricing mechanics sit in the Cloud pricing guide.
Controlling the portfolio rather than the renewals
- Inventory every paid app with its renewal date and adopter count, because that single mapping is what exposes both the overlap and the tier waste.
- Align the renewal dates, since scattered dates hide the total and leave you negotiating each app as a small line item rather than as a portfolio.
- Benchmark the portfolio as one number against the host tier, which is how app spend that rivals the core licences becomes visible to the people approving it.
- Cut the overlap before the next threshold lands, because duplication repriced at a higher band costs more than duplication removed beforehand.
- Clean up host product users first, as tier matching means user cleanup on the host cuts app cost as well as licence cost, doubling the return on the same work.
The Atlassian enterprise pricing playbook
Tier arithmetic across the host and the app portfolio, the threshold forecast, and the buyer side moves for the next Cloud renewal cycle.
Get the white paper →Why app renewals have to be run as one negotiation
The standard advice is to negotiate each Marketplace app on its own renewal and treat them as small line items, which is exactly how the duplication and the tier waste survive.
In roughly half the estates we reviewed, app spend rivalled the core Atlassian licences, yet it sat scattered across renewal dates and had never been benchmarked as a portfolio, so no single approval ever looked large enough to question.
That is a governance failure rather than a pricing one, and it is fixed by consolidating the view before consolidating the spend.
Start with the inventory, mapping every paid app to its renewal date and its actual adopter count, because those two columns produce both findings at once: apps whose adopter count is a small fraction of the licensed tier are tier waste, and apps whose function overlaps another are duplication.
Then align the renewal dates so the portfolio can be negotiated as one number, which also removes the scattering that currently obscures the total from finance.
Then act before the next threshold rather than after it, since duplication repriced at a higher band is more expensive to carry and harder to unwind.
And because tier matching runs both directions, a cleanup of dormant and departed users on the host product reduces the app portfolio as well as the core licences, which makes it the highest return maintenance work available in an Atlassian estate.
The AI add on interacts with the same tier logic and is covered in the Rovo licensing guide, and the wider negotiation envelope in the enterprise negotiation guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Atlassian app estates, 2024 to 2025
Across roughly 15 to 25 Atlassian estates we reviewed between 2024 and 2025, Marketplace apps were the least governed line and the fastest growing:
Increase in total app spend when a user tier was crossed, felt across the whole portfolio in a single step.
Share of app spend covering a need another installed app already served, surviving because apps are approved individually.
Three patterns recurred: threshold shock, where crossing a user tier raised total app spend 15 to 30 percent in one step; app overlap, where estates ran two or more apps covering the same need with 10 to 20 percent of spend duplicated.
And tier waste, where apps were licensed to the full user tier while only a minority of users touched them.
The buyer side move is to stop treating apps as trivial. Inventory the portfolio, align the renewals, benchmark it as one number against the host tier, and cut the overlap before the next threshold, remembering that host user cleanup reduces app cost at the same time.
The wider library sits in the Atlassian practice.
Your first five moves
- Inventory every paid app against its renewal date and actual adopter count, because that mapping exposes both the overlap and the tier waste in a single pass.
- Track active users against the next tier threshold and model the portfolio reprice, since crossing one lifted total app spend 15 to 30 percent in a single step.
- Align the app renewal dates, so the portfolio is negotiated as one number rather than as a series of individually unremarkable line items.
- Cut the overlapping apps before the next threshold lands, because duplication repriced at a higher band is both more expensive and harder to unwind.
- Clean up dormant and departed users on the host product first, since tier matching means that work cuts app cost as well as licence cost. The Atlassian practice runs the portfolio review with you.
Frequently asked questions
How does Atlassian Marketplace tier matching work?
Paid apps must license to the same user tier as the Atlassian product they extend. If the host product is licensed for a given user band, each paid app must be licensed for that band too, even if only a few people use it.
There are no partial seats, and the rule applies to every paid app independently.
Can we license an app for one department only?
No, and that is the single most surprising cost rule for buyers. The app band must equal the host product band, so a niche tool bought for one team is priced against the whole licensed population.
That makes the adopter count irrelevant to the price and highly relevant to whether the app is worth keeping at all.
Why do app bills jump at thresholds?
Because pricing steps at user tiers and apps inherit those tiers, so adding a handful of users can cross a threshold and reprice every installed app at once.
In our file that step raised total app spend 15 to 30 percent, and it usually appears only on the next invoice rather than at the moment the seats were added.
Can you drop back a tier by removing users?
Not always cleanly. Shedding users later does not reliably return you to the prior band, which makes the threshold closer to a one way door than a symmetric boundary.
That is why forecasting the crossing and modelling the portfolio reprice before approving new seats matters more than reacting to the invoice afterwards.
How much app spend is typically duplicated?
Between 10 and 20 percent, across estates running two or more apps that cover the same need.
The duplication survives because apps are approved individually as small line items by people who are not looking at the portfolio, so no single approval ever appears large enough to trigger a review of what is already installed.
Should Marketplace apps be negotiated individually?
No. In roughly half the estates we reviewed app spend rivalled the core licences, yet it was scattered across renewal dates and never benchmarked as a portfolio.
Aligning the dates and benchmarking the portfolio as one number against the host tier is what makes the spend visible and the negotiation meaningful.
Does user cleanup on the host product help?
Yes, twice over. Because tier matching ties every app to the host band, removing dormant and departed users from the host product reduces the app portfolio cost as well as the core licence cost. That makes host user cleanup the highest return maintenance work available in an Atlassian estate.
