The Marketplace apps rather than the platform were the line that surprised finance, reaching 40 to 90 percent of the host platform cost on app heavy estates
Apps are priced to match the host tier, so moving the platform repriced every paid app at the same time. Nobody changed an app and the app bill went up.
Prepared by Redress Compliance · August 19, 2026 · Atlassian estate reviews. 20 to 30 estates reviewed, 2024 to 2025.
Executive summary
Marketplace app cost reached 40 to 90 percent of the host platform cost on app heavy estates. That is a second platform bill hiding inside a line nobody reviews.
Unused or duplicated paid apps ran at 15 to 30 percent of the app bill before the migration audit, which is the cheapest part of the estate to correct.
User tier over sizing pushed 1 in 3 estates into a higher band on both platform and apps. A handful of extra accounts moves the whole estate up together.
Migration is the moment to audit, consolidate and right size. Plan the migration and the renewal as one event, well ahead of term end.
Why did the app bill move on its own?
Because apps are priced to match the host product tier. Ending the self hosted product forced every customer onto a higher tier, and the apps followed automatically without anybody touching one.
An app sold for a self hosted instance was priced for that tier. The same app on the data centre product is priced for the data centre tier. The capability did not change and the price did, because it tracks the host.
The migration paths are set out on Atlassian's cloud journey resources.
The user threshold moves everything at once
Crossing a band raises the platform and every paid app together, which is why a handful of extra accounts can move the whole estate. Clean the user list before you size the tier, not after.
What does each destination do to the app line?
Different things, and none of them are neutral. Data centre keeps the user tier band structure, while the cloud plans repackage the estate into a plan plus a band, with the host bands published on the product pricing pages.
| Destination | App pricing basis | Best fit | Cost watch out |
|---|---|---|---|
| Data centre | User tier band | Regulated or heavily customized estates | The tier crosses on user growth |
| Cloud Standard | Plan and user band | Smaller standardized teams | Feature gaps that need apps to close |
| Cloud Premium | Plan and user band | Larger cloud estates | The premium plan plus app tiers on top |
| Cloud Enterprise | Plan and user band | Multi instance estates | Negotiated, so model the app line explicitly |
Some apps have direct cloud equivalents and some do not, needing a replacement or a workflow change. Either way the app line has to be modelled before the platform quote is signed rather than after.
The Atlassian renewal kit
The user audit worksheet, the tier boundary model, and the renewal cap language that survives the redlines.
Get the brief →What 20 to 30 Atlassian estates showed
Across roughly 20 to 30 Atlassian estates reviewed in 2024 and 2025, the Marketplace apps rather than the platform were the line that surprised finance. Three patterns recur.
- Marketplace app cost reached 40 to 90 percent of the host platform cost on app heavy estates.
- Unused or duplicated paid apps ran at 15 to 30 percent of the app bill before the migration audit.
- User tier over sizing pushed 1 in 3 estates into a higher band on both platform and apps.
The app line moved without anyone changing a single app. That is what makes it a budgeting failure rather than a purchasing decision.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call, so you can 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 does the migration audit actually find?
Apps nobody has opened in months, and duplicates that solve the same problem twice because two teams bought independently. Together they ran 15 to 30 percent of the app bill.
For each paid app the decision is one of three: it moves as it is, it is replaced by native capability or another app, or it is retired. Making that decision once during the migration is far cheaper than making it never.
The migration is the only moment the whole list gets read
Outside a migration nobody reviews an app portfolio, because each individual line is small. The tier repricing is what finally makes the total visible, and the same threshold mechanics are covered in the app scaling guide.
Watch the briefing · 6:31Converting Off Atlassian Data Center Before the 2029 DeadlinePricing the renewal, the cloud equivalent and the migration as one comparison.
When should the two events be planned?
Together, and well ahead of term end. Apps renew with the platform, so the timing already aligns whether or not the buyer treats them as one negotiation.
Apps already renew with the platform
Running them separately means the platform tier is agreed first and the app repricing arrives afterwards as a consequence rather than as a choice. That is the sequence that produced the surprise in the estates reviewed.
The migration timing question itself, and what the end of life dates do to leverage, sit in the end of life guide, the cloud migration guide and its companion paper.
Where the renewal calendar itself is the lever, the renewal program runs the two events as one.
What the reviews measured, 2024 to 2025
Two cuts of the engagement file, both on the line finance had not modelled.
On app heavy estates, where the Marketplace line had grown to rival the platform it sits on.
Before the migration audit, from apps nobody had opened and duplicates bought independently by different teams.
The first number is why the line deserves a review. The second is what the review recovers on its first pass.
Your first five moves
- Price the app line before you sign the platform quote, because apps track the host tier and reached 40 to 90 percent of platform cost on app heavy estates.
- Audit every paid app against actual use and decide move, replace or retire, which is where the 15 to 30 percent of unused and duplicated spend surfaces.
- Clean the user list before sizing the tier, since crossing a band raises the platform and every app together and pushed 1 in 3 estates up a band.
- Check which apps have a genuine equivalent on the destination, because the ones that do not need a replacement or a workflow change costed into the same model.
- Plan the migration and the renewal as one event, well ahead of term end. The Atlassian practice models both lines together, and the Atlassian hub carries the rest of the estate view.
Frequently asked questions
Why did app costs rise without any app changing?
Because Marketplace apps are priced to match the host product tier. Moving the platform to a higher tier repriced every paid app on it automatically.
How large is the app line?
It reached 40 to 90 percent of the host platform cost on app heavy estates. That is a second platform bill sitting inside a line most reviews never open.
How much of it is waste?
Between 15 and 30 percent of the app bill sat on unused or duplicated apps before the migration audit, from tools nobody opened and duplicates bought independently.
What does crossing a user tier do?
It raises the platform and every paid app together. A handful of extra accounts can move the whole estate into the next band, which caught 1 in 3 estates reviewed.
How are data centre apps priced?
By user tier, in the same bands as the host product, renewing on the same annual term. The app tier has to match the product tier.
What changes on a cloud migration?
The estate repackages into a plan plus a user band. Some apps have direct equivalents, some need a replacement or a workflow change, and the app line has to be modelled either way.
When should the app audit happen?
During the migration, because that is the only moment the whole list gets read. Outside one nobody reviews an app portfolio, since each individual line looks small.
Should the migration and renewal be one negotiation?
Yes. Apps renew with the platform so the timing already aligns, and running them separately means the app repricing arrives as a consequence rather than a choice.
What are the three decisions per app?
Move it as it is, replace it with native capability or another app, or retire it. Making that call once during the migration is much cheaper than never making it.
How far ahead should this start?
Well before term end. The tier decision, the user list clean up and the app audit all have to land before the platform quote is signed rather than after.
