You are registered. Your guide is ready. The full 2026 edition of the Atlassian Cloud Migration Guide follows below.
Prepared by Atonement Licensing · buyer-side advisory · last reviewed June 2026. Pricing figures are list-level or clearly labelled indicative ranges; the cost proportions and scenarios below are representative benchmarks for illustration, not quotes.
Executive summary
An Atlassian Cloud bill is set by three choices you control — your billed user count, your edition, and your Marketplace apps — and the migration off Server and Data Center forces all three at once, under time pressure, with the vendor framing the options. That is exactly why rushed migrations lock in inflated costs for years. Buyers who measure real usage, size the user count to the right side of a tier boundary, and price every app before they move routinely cut Atlassian spend without losing function.
The gap is concrete. On a representative mid-size estate, a like-for-like migration that carries every inactive account and every legacy Marketplace app across to Cloud models roughly 25 to 40 percent higher than the same estate cleansed first, deprovisioned, app-rationalised, and edition-matched to confirmed need (indicative). The difference is not a discount the vendor withheld; it is waste the buyer migrated. Most of it lives in dormant seats billed per user, apps re-bought by habit, and a Premium or Enterprise edition accepted ahead of a confirmed requirement.
This guide lays out how Atlassian Cloud builds a price across Jira, Confluence, and Jira Service Management, where the user tier model jumps, when an edition upgrade is worth paying for, how Marketplace app costs change on Cloud, the migration paths out of Server and Data Center, and the contract terms to fix before you commit. The governing principle is simple: treat the migration as a procurement event, not just a technical project, and cleanse the estate before you price it.
How Atlassian Cloud builds a price, and where migrating buyers overpay
Atlassian Cloud is priced per user, per product, per edition. Jira, Confluence, and Jira Service Management each carry their own subscription, their own user count, and their own edition choice. There is no single bundled seat that covers everything, so the cost is the sum of the products you run multiplied by the users on each. For a buyer moving off Server or Data Center, that structure is the first surprise: what was one perpetual license plus maintenance becomes a stack of per user subscriptions.
Within each product, the per user rate is tiered. The smallest deployments pay a flat or simple rate, and above that the per user price steps down in bands as the user count rises. That tapering rewards scale, but the band structure also creates boundaries where adding a small number of users moves the whole subscription into the next block.
On top of the per user charge sit the edition premium, the Marketplace apps, and any platform add-ons such as Atlassian Guard for identity and security controls. Jira Service Management adds a further wrinkle because it is priced by agent rather than by general user, so the people who resolve tickets drive that line while everyone else consumes it.
Where the spend concentrates on a typical multi-product estate (illustrative proportions, not a quote).
Action. Decompose the Cloud quote into all four layers before you respond to it, and assign each layer an owner. A number you have not broken apart is a number you cannot reduce.
2The user tier model and the jumps that catch buyers
The single most common Atlassian cost surprise is a tier jump. Because user counts are billed in bands, a deployment that sits just below a boundary can move into a higher cost block when a handful of accounts are added. The marginal users are cheap; the reclassification of the whole subscription is not.
The defense is to know where your user count sits relative to the nearest band boundary before any change. If you are close to crossing one, decide deliberately whether the additional users justify the move, and time the increase so it coincides with value you actually need rather than incidental account creep.
| Trap | How it happens | Buyer action |
|---|---|---|
| Band boundary jump | A few added users push the count into the next pricing block | Track the count against the nearest boundary before adding seats |
| Inactive accounts | Departed staff and dormant accounts keep counting | Run an access review before every renewal and deprovision |
| Over counted users | People who only read are licensed as full users | Match the access level to the real need per product |
| Service desk agents | Jira Service Management agents priced higher than users | Confirm who truly needs agent access versus customer access |
| Product duplication | Overlapping tools paid for alongside Atlassian | Rationalize the wider tooling estate before you commit |
Inactive accounts are the quietest line on the invoice. On a per user model, every dormant account is a recurring charge for nothing, and an access review before each renewal routinely removes a meaningful share of the billed count. Atlassian's own admin tooling shows last active dates if someone is assigned to look, yet most estates never look until the advisor does. The seats you reclaim here cost you nothing to remove and recur every year you leave them.
Action. Map your billed user count against the nearest band boundary per product, then deprovision dormant accounts so a small, deliberate increase never tips the whole subscription into the next block.
Planning an Atlassian Cloud migration or renewal this year? Our advisors size it with you.
SaaS License OptimizationStandard, Premium, and Enterprise: choosing the right edition
Atlassian sells Cloud products in editions, typically Free, Standard, Premium, and Enterprise. Each step up adds capability and cost. The mistake buyers make is to accept an edition upgrade as a default rather than mapping the specific features they need to the lowest edition that includes them.
Standard suits most general deployments. Premium adds advanced administration, higher storage and automation limits, and an uptime commitment, which matters for teams that depend on the platform for production work. Enterprise adds organization wide controls, multiple instances under one agreement, and the commercial structure that larger buyers need. Each tier is worth paying for only when the included features map to a confirmed requirement.
Build the feature checklist before the sales conversation, not during it. Typical entries that genuinely force an edition decision include automation rule limits on large Jira instances, sandbox and release track controls for change management, IP allowlisting, unlimited storage, and the financially backed uptime commitment. Write each requirement down with the team that owns it, then map every line to the lowest edition that satisfies it. If nothing on the list demands Enterprise, the conversation gets simpler and cheaper.
| Edition | Typically suits | Watch for |
|---|---|---|
| Standard | General team use with standard admin needs | Storage and automation ceilings on large instances |
| Premium | Production critical use needing uptime and advanced admin | Paying the premium for features you will not use |
| Enterprise | Large estates needing multi instance and org controls | An upgrade sold ahead of a confirmed need |
The Enterprise edition conversation usually starts as a security conversation. Before agreeing to it, separate the requirements: identity, SSO enforcement, and audit controls are delivered by Atlassian Guard, which is priced per unique user across products, while multi instance administration and the stronger uptime commitment sit in the edition itself. Buyers who price Guard plus Premium against Enterprise often find the cheaper combination covers every confirmed requirement.
Action. Decide the edition from a written feature checklist owned by the teams that need each capability, then buy the lowest edition that includes all of them and nothing you cannot name a use for.
4Marketplace apps and the cost of re-buying on Cloud
Apps are where migration budgets quietly break. A mature Server or Data Center deployment often carries a dozen or more Marketplace apps, and those apps do not transfer to Cloud as an entitlement. On Cloud they are licensed separately, frequently as a different product, sometimes with a different vendor, and sometimes with no Cloud equivalent at all.
The result is that a migration can require re-buying a stack of capability you already paid for, at Cloud pricing, on a per user model that scales with your user count. Apps that were a one time or modestly priced Data Center purchase can become a recurring per user charge on Cloud.
Migration is the one moment you are allowed to leave things behind. Carry every app across by habit and you re-buy your own backlog at Cloud prices.
Inventory every app before you migrate. For each one, decide whether the capability is still needed, whether a Cloud equivalent exists, whether the function is now native in a higher Atlassian edition, and what the Cloud price will be at your user count. Watch the user count mismatch as well: most Cloud apps are priced against the full user tier of the parent product, not against the subset of people who use the app. A reporting app used by twelve project managers can be billed for two thousand Jira users, which is why the app rationalisation and the user cleanse belong in the same exercise.
The portion of a mature multi-product Atlassian bill that Marketplace apps commonly reach once re-bought on Cloud at the parent product's full user tier (indicative).
Roughly the share of legacy apps that an inventory finds are unused, duplicated, or now native in a higher edition, and can be dropped before migrating (indicative).
Action. Inventory every app, price its Cloud equivalent at your user count, and delete anything unused, duplicated, or now native in the edition you have chosen before a single wave moves.
5The Server and Data Center exit and migration paths
With Server support ended in February 2024, the practical choice is Cloud or Data Center. Cloud removes the infrastructure burden and suits most organizations. Data Center remains the path for buyers with strict data residency, regulatory, or customization requirements that Cloud cannot yet meet, and it carries its own per user subscription that has risen over recent years.
Atlassian offers migration tooling and time limited incentives that can apply dual subscription credit or discounts during a transition. Those incentives are part of the negotiation, not a fixed published benefit, so confirm what applies to your situation and your timeline rather than assuming a standard offer.
Keep Data Center alive as an alternative even when Cloud is the likely destination. A buyer who has costed the Data Center renewal for another term, and who can credibly defer the move a year, negotiates the Cloud price from a position of choice rather than necessity. The alternative does not need to be preferred to be useful. It needs to be real, priced, and visible to the vendor at the moment the Cloud quote lands.
| Stage | What to do | Why |
|---|---|---|
| Assess | Inventory users, editions, apps, and customizations | You cannot size a migration you have not measured |
| Decide | Choose Cloud or Data Center per product on the facts | The right destination differs by workload and rule |
| Cleanse | Deprovision inactive users and drop unused apps | Migrate a lean estate, not the accumulated one |
| Price | Cost the target editions, apps, and user bands | Set your number before the vendor sets it |
| Negotiate | Confirm discounts, migration credit, and terms | Incentives and rates are negotiable, not fixed |
| Migrate | Move in planned waves with a tested rollback | Control risk and avoid a rushed cutover |
Ask explicitly about dual licensing credit during the transition window. Atlassian has offered Cloud migration trials and overlap credit so that buyers are not paying for Data Center and Cloud in full at the same time while waves move across. The terms shift by program and by quarter, which is precisely why they belong in your written agreement rather than in a reseller's email. A migration quoted without overlap treatment is a quote with a hidden second bill.
Action. Decide Cloud or Data Center product by product on the facts, keep a costed Data Center renewal credibly in play, and get any overlap credit written into the agreement before you commit to a cutover date.
6Contract terms, the committed user count, and data residency
The headline discount matters less than the terms that govern the next three years. Fix price protection so the per user rate and the edition price cannot rise sharply at renewal. Fix the treatment of mid term user additions so growth is priced in advance. Confirm whether unused capacity can be reduced at renewal, and on what notice. For app heavy estates, ask whether key apps can be brought under the same agreement and the same protection rather than billed and renewed separately on their own cycles. Terms you have confirmed in the contract are protection; terms you have only been told are not.
The committed user count is the number that most affects your cost, and the discipline mirrors any subscription: commit the count you will genuinely use, not a padded forecast. Base it on a cleansed user list after deprovisioning, with realistic growth treated separately rather than baked into the commitment. Confirm how mid term additions are priced so growth does not arrive at an unfavorable rate, and understand whether the count can be adjusted down at renewal or only up. On multi year terms, trade length for protection rather than for a marginally deeper discount: a two or three year agreement is worth signing when it locks the per user rate, caps any renewal uplift, and preserves the right to true down at each anniversary, and worth refusing when it locks only your commitment and leaves the vendor's pricing free to move.
Where data residency or regulatory rules apply, treat it as a written confirmation exercise. Ask Atlassian to state, for each product and each region you operate in, where data at rest is pinned, what categories of data fall outside the pinning, and what the roadmap commitment is for the gaps. Atlassian Guard, the product formerly sold as Atlassian Access, delivers identity and security controls across products on its own per user basis and belongs in the cost model from the start. Product data and app data are not always treated the same way, and a Marketplace app can move data outside the residency boundary the core product respects. Your compliance position is only as strong as the least compliant component in the stack.
Term length is a concession you sell. Price protection is the currency you demand for it — never the other way round.
Action. Lock price protection, capped renewal uplift, true-down rights, and the mid-term addition rate in writing, size the commitment to a cleansed baseline, and confirm residency per product and per region before you sign.
Get this guide applied to your Atlassian contract. Confidential assessment within one business day.
SaaS License OptimizationJira Service Management and the agent question
Jira Service Management deserves separate attention because it is priced by agent, not by general user. Agents are the people who work and resolve requests. Everyone else, including the employees who raise tickets, are customers who do not carry an agent charge. The cost of the product is therefore driven by how many people you license as agents.
The common error is to license too many agents, either by treating occasional responders as full agents or by leaving departed staff with agent access. Review the agent list with the same discipline as the user list, confirm who genuinely needs to work requests, and move occasional contributors to a model that fits their real use. On a per agent basis, every unnecessary agent is a recurring charge for access that is rarely used.
The agent versus customer boundary is a contract definition, not just a product setting. When you negotiate, state in writing that request participants and approvers are customers, not agents, and confirm how automation accounts and integration users are counted. We have seen service desk estates where simply reclassifying approvers and integration accounts removed a double digit share of the agent bill without touching a single workflow.
Action. Reclassify approvers, request participants, and integration accounts as customers in the written agreement, and right-size the agent count to the people who actually resolve requests.
8Reading the bill, timing the renewal, and the buyer's business case
Most buyers see a single Atlassian invoice total and treat it as one cost. The total is a stack of independent lines, and you cannot reduce what you cannot see. Break it into its parts: the per user subscriptions, one line per product with a user count and edition; the Marketplace apps, each with its own per user count that should match the product it serves but often does not; the platform add-ons such as Atlassian Guard; and any Jira Service Management agent lines, which are priced differently from general users. Teams that assumed the core Jira and Confluence subscriptions were the whole story often find apps, agents, and an over specified edition account for a large share of the bill.
Timing decides how much room you have to prepare, and preparation decides the price. The user cleanse, the app inventory, the edition decisions, and the benchmarking all need lead time, so begin the assessment at least a quarter before the renewal or the planned migration date. That window also lets you treat the migration incentive as a negotiation rather than accepting whatever standard offer is presented under time pressure. The phases below are the timeline we run.
Inventory and attribute
Break the bill into products, editions, apps, and agents, attribute each line to an owner, and inventory users, agents, and Marketplace apps against real activity.
Cleanse and price
Deprovision inactive users, cut unused apps, decide editions from the feature checklist, and benchmark the per user rate so you set your number before the vendor sets it.
Anchor and close
Open the commercial conversation with your structure and a credible alternative in play, then close with price protection, true-down rights, and addition terms locked for the full term.
The work produces one artifact: a business case that states your cleansed user count by product, your edition decisions with the features that justify them, your rationalised app list with Cloud pricing, and the contract terms you require. The per user price a buyer can secure depends on the user count, the term length, and the credibility of the alternative, whether that is Data Center, a competing toolset, or a slower migration timeline. Buyers who arrive with this case consistently do better than buyers who react to a renewal quote. The difference is not skill in the room; it is the preparation done in the weeks before.
Action. Start a quarter out, attribute every invoice line to an owner, and walk into the renewal with a written business case and a costed alternative rather than a reaction to the vendor's quote.
Cleanse the estate before you price it, decide editions and apps from confirmed need rather than the vendor's default, size the committed user count to a clean baseline, and write price protection, true-down rights, the mid-term addition rate, the agent definition, and residency into the agreement before the headline discount is even discussed. Treat the migration as a procurement event on your calendar, keep Data Center credibly in play, and the cleansed, benchmarked business case recovers the 25-to-40-percent gap that a rushed, like-for-like migration locks in for years.
Key takeaways
- Atlassian Cloud cost is user count times edition times apps. Reduce each before you negotiate.
- Watch the user tier bands; a few added seats can jump the whole subscription.
- Run an access review and deprovision inactive accounts before every renewal.
- Choose the edition from a feature checklist, not a sales recommendation, and price Atlassian Guard plus Premium against Enterprise.
- Inventory and price every Marketplace app before you migrate, then cut the list.
- Decide Cloud or Data Center product by product, on residency and customization needs.
- Fix price protection, the agent definition, and mid term addition pricing before the headline discount.
Frequently asked questions
How does Atlassian Cloud pricing work?
Atlassian Cloud is priced per user, per product, on a tiered model. Each product such as Jira, Confluence, or Jira Service Management has its own user count and edition. Above the smallest tiers the per user rate steps down in bands, so your billed user count and chosen edition set the cost.
Why did my Atlassian bill jump after adding a few users?
User counts are billed in bands. Crossing a band boundary moves you into the next pricing block, so adding a handful of users can shift the whole subscription up a tier. Plan the committed user count so a small increase does not push you across a boundary you did not budget for.
Do my Server or Data Center apps carry over to Cloud?
Not automatically. Marketplace apps are licensed separately on Cloud and are often a different product from the Server or Data Center version. Some have a Cloud equivalent, some do not, and the pricing model can change. Inventory every app and price the Cloud equivalent before you migrate.
Is Atlassian Cloud Premium or Enterprise worth the cost?
Only when you use the features that justify the step up, such as advanced administration, higher storage, or guaranteed uptime. Map the specific features you need to the edition that includes them, and resist an edition upgrade sold ahead of a confirmed requirement.
Can I negotiate Atlassian Cloud pricing?
Yes, particularly at higher user counts and on annual or multi year terms. Discounts, migration incentives, and commercial terms are negotiable. Negotiating power comes from an accurate user count, a clear edition decision, and timing the conversation before the renewal date.
Related research: this is the full edition of the Atlassian Cloud Migration Guide. Continue with the SaaS license optimization guide, the cloud renewal strategy playbook, and the enterprise software price benchmarking report. For deeper pricing detail, see the Atlassian Cloud pricing guide and the Atlassian Cloud migration cost guide.