Atlassian Marketplace App Licensing: How Costs Scale with Users

The Mandatory Full-Count Licensing Rule

Every Atlassian Marketplace app carries the same fundamental licensing rule: the app must be purchased for the complete licence count of the underlying Atlassian product. If your organisation has 800 Jira Software users, any Jira Marketplace app you install costs 800 × per-user-rate, regardless of whether 50 users or 750 users actually open the app.

This rule creates a structural mismatch between value and cost that is unlike most enterprise software licensing. With standard SaaS tools, you can scale down a feature to a subset of users. With Marketplace apps, your billing tier is locked to your Atlassian product tier — the two cannot diverge. If your Jira licence tier is 800 users, every app you add starts at the 800-user tier cost.

The financial consequence compounds as user counts grow. An organisation that grows from 400 to 500 users crosses a tier threshold that triggers a cost jump not just for the Jira licence — but simultaneously for every installed Marketplace app. The tier threshold effect is multiplicative, not additive.

The full Atlassian Marketplace apps licensing and EOL guide provides the complete framework for managing Marketplace costs, including governance strategies and the EOL impact analysis for Data Center deployments.

How Band Pricing Creates Threshold Traps

Atlassian Marketplace apps use tiered pricing with predefined user count bands that mirror the Atlassian product licence tiers. Typical tier bands are 1–10, 11–25, 26–50, 51–100, 101–200, 201–300, 301–500, 501–800, and 801–1,001 users, with Enterprise and custom tiers above 1,001. Within each band, the per-user annual cost is fixed — crossing into the next band triggers an immediate step up to the higher band's total cost.

The practical consequence is that organisations sitting just above a band boundary are paying for the capacity of the next band while consuming users at the previous tier. An organisation with 501 users pays at the 501–800 band for every app, even if their effective user count is only marginally above 500. The 501-user scenario forces payment for up to 299 additional app licences per app than a 500-user organisation immediately below the threshold.

For organisations with 10 installed Marketplace apps at an average per-user cost of $8 per year, crossing the 500-user threshold adds approximately $23,920 in annual app costs ($8 × 299 excess users × 10 apps) compared to an organisation at 499 users. This threshold trap occurs at every tier boundary simultaneously and silently — no purchase approval is triggered because it is a pricing tier change, not a new licence purchase.

Tier Boundary Planning

Proactive management of tier boundaries is one of the most underutilised cost control levers available to Atlassian administrators. Before any Atlassian user provisioning exercise, the administrator should model: what tier boundary does the current user count sit below, how many users can be added before crossing the next threshold, and what is the total cost impact (across all installed apps) of crossing that threshold.

This modelling exercise takes less than one hour and can prevent tens of thousands of dollars in unnecessary tier upgrades. The decision to delay provisioning a batch of users by one billing cycle — or to rationalise inactive users before provisioning new ones — can preserve the current tier position for months.

Maximum Quantity Billing: The July 2025 Change

Atlassian introduced maximum quantity billing for monthly Cloud subscriptions in July 2025. Under this model, monthly app bills are calculated based on the peak user count during the billing period, not the count at billing date or a usage average. The billing period is typically a calendar month.

The operational impact is significant for organisations with dynamic user populations. If an organisation runs at 490 users for 28 days of a month but provisions 15 temporary project users for two days, the monthly bill for that period is calculated at the 501–800 tier for the entire month — not just for the two days at peak count. The peak count, however brief, locks the billing tier for the full month.

This change particularly affects organisations that use Atlassian for project-based work where temporary users are common — consulting firms, technology services businesses, agencies, and any organisation with regular contractor or seasonal workforce involvement. For these organisations, the move from average to peak billing can increase monthly app costs by 15 to 30 percent with no change in actual sustained usage.

The Atlassian pricing changes 2026 analysis documents the full implications of the billing model change for both base product and Marketplace app costs, including which user types trigger billing tier calculations.

The Annual vs Monthly Billing Decision

The maximum quantity billing model creates a strong commercial incentive to migrate Marketplace app subscriptions from monthly to annual billing. Annual Marketplace app billing fixes the user count at the time of the annual commitment — peak-count billing dynamics only apply to monthly subscriptions. An organisation that commits annually at 500 users pays the 501–800 band rate (because 500 users land in that tier) but is not exposed to intra-year peak-count tier escalation.

Annual billing also typically offers a pricing advantage versus monthly billing for Marketplace apps, as many vendors price monthly subscriptions at a higher per-user effective rate than annual commitments. The combination of pricing certainty and monthly billing protection makes annual app subscriptions the preferred commercial structure for most enterprise organisations with stable or slowly growing user counts.

The exception is organisations actively planning a significant user count change — either a reduction (post-merger consolidation, workforce restructuring) or a rapid increase (acquisition, new product rollout). In these cases, annual commitments made at the wrong user count create their own overpayment problem.

Multi-Instance Pricing for Enterprise Customers

Enterprise Atlassian Cloud customers running multiple Jira or Confluence instances — a common architecture in large organisations that maintain separate instances for different business units, acquired companies, or geographic regions — previously faced Marketplace app costs calculated per instance. An app used across three instances was billed three times at the full user count of each instance.

Atlassian introduced multi-instance pricing for Marketplace apps in Q4 2025. Under this model, eligible Enterprise customers are charged based on unique users across all instances, rather than the sum of users in each instance. Users who appear in multiple instances are counted once, not multiple times. This structural change can significantly reduce app costs for Enterprise customers with significant user overlap across instances.

Enterprise customers who have not yet evaluated multi-instance pricing for their Marketplace app portfolio are likely overpaying. The evaluation requires mapping which users appear in multiple instances and calculating the cost difference between current per-instance billing and multi-instance billing. Our Atlassian Marketplace licensing specialists conduct this analysis as part of the annual Atlassian cost review service.

How App Costs Compound at Enterprise Scale

The compounding effect of multiple apps at the full licence count creates an effective per-user cost that is typically two to three times the base Atlassian subscription rate for enterprise deployments. A representative enterprise scenario illustrates this clearly:

A 1,000-user organisation on Jira Software Premium (approximately $125 per user per year at list) that runs ten Marketplace apps at an average of $60 per user per year per app pays $1,000,000 in Jira Premium subscriptions plus $600,000 in Marketplace app subscriptions annually — for a total annual Atlassian cost of $1,600,000. The Marketplace apps represent 37.5 percent of total spend. If average app cost is $90 per user per year (a realistic figure for enterprise tool stacks), the Marketplace share reaches 42 percent of total spend.

When Marketplace apps represent 40 percent of total Atlassian spend, optimising app licensing is not a secondary concern — it is a primary cost management priority of equal importance to negotiating the base product subscription. Yet most organisations devote the vast majority of their Atlassian commercial attention to the base product renewal and treat Marketplace apps as a fixed operational cost.

User Count Optimisation as a Cost Lever

Because Marketplace app costs apply to the full licence count, any reduction in the base Atlassian user count delivers proportional savings across every installed app simultaneously. A 100-user reduction in a 1,000-user Jira environment at $90 per user per year in app costs (ten apps at average $9 per user per year) generates $9,000 in annual app savings — in addition to the base product subscription reduction. Across a 10-app portfolio at higher per-user rates, the savings from a user count reduction multiply rapidly.

The practical approach is to conduct a licence utilisation audit 60 to 90 days before the Atlassian base product renewal, identifying users who have not logged in within 60 days, users who are provisioned but have no active workload, and users in roles that do not require Atlassian access for their job function. Removing these users before the renewal date reduces both the base licence tier and the per-app tier in a single action.

The Atlassian Data Center end-of-life transition is an additional trigger for user count rationalisation. Organisations migrating from Data Center to Cloud have an opportunity to reset their user count against actual need — a migration that replicates all existing DC users without active usage validation will carry legacy inactive users into the Cloud licence tier, paying Cloud rates and app rates for users who generate no value.

Our Atlassian cloud migration planning guide includes a user rationalisation step as a mandatory component of any DC-to-Cloud migration process precisely because the migration window is the best opportunity to right-size the user count before committing to Cloud licensing.

App Vendor Price Increases: An Independent Variable

Atlassian controls the pricing of its base products, but Marketplace apps are priced independently by their respective vendors. App vendor price increases are not coordinated with Atlassian's renewal cycle and can occur at any time during a subscription year. Tempo Timesheets — one of the most widely deployed Marketplace apps — implemented a 15 percent price increase effective September 2025. Other major vendors have made similar adjustments as they reposition their pricing for the Cloud-first environment.

The implication for enterprise app spend management is that the Marketplace app cost line is not stable between renewal cycles. Vendors can — and do — raise prices mid-subscription year for monthly billing customers. For annual billing customers, price protection lasts until the annual renewal date, after which vendors can apply new pricing. Budget models that assume flat Marketplace app costs year over year consistently underestimate actual spend.

The governance response is to build a five percent to ten percent annual growth assumption into Marketplace app budget lines and to monitor vendor pricing communications proactively. Major vendor price changes are typically announced 60 to 90 days in advance of their effective date, providing a window to evaluate alternatives before committing to the higher rate.

Practical Actions for User-Scaling Cost Control

Map your current tier position before any user provisioning. Know which tier boundaries you are approaching for each product and calculate the total cost impact (base product plus all installed apps) of crossing each boundary. Make this calculation visible to whoever approves user provisioning requests.

Model the total cost of each new user batch. Before provisioning any group of users, calculate the total per-user cost including all Marketplace apps, not just the base product rate. If provisioning 20 users triggers a tier crossing that costs $50,000 in annual app uplift, that is relevant information for the provisioning decision.

Migrate monthly app subscriptions to annual billing. Eliminate the maximum quantity billing exposure for stable user populations by committing to annual billing. The predictability benefit alone justifies the switch for most enterprise deployments.

Validate user counts before the annual renewal window. Conduct an active login audit 60 to 90 days before renewal. Remove inactive users before the renewal date to lower the billing tier for both base products and all apps simultaneously.

Review multi-instance pricing if you are on Enterprise. If your organisation runs multiple Atlassian instances, request a multi-instance pricing evaluation for all installed Marketplace apps. The savings can be significant for Enterprise customers with cross-instance user overlap.

For a complete assessment of your current Atlassian Marketplace app spend and a structured optimisation plan, our Atlassian cost advisory services provide independent analysis and negotiation support on the buyer side only.