Moving from Atlassian Data Center to Cloud typically raises annual subscription cost by 20 to 40 percent once a perpetual-license-plus-maintenance estate converts to per-user Cloud tiers, and that is before migration services, app re-licensing, and the internal effort the project consumes. The Cloud sticker price is only one line of the true cost. The full bill includes the subscription change, professional services or internal labor to move the data, the re-purchase or re-subscription of every Marketplace app, and the productivity cost of the cutover. Planning the migration as a whole-cost exercise, not a tier comparison, is what separates a controlled move from a budget surprise.
This guide breaks down each cost component, the factors that move it, the dual-running and compliance considerations, the common mistakes, and the levers that hold cost down. It sits under our Atlassian Cloud pricing guide, links across to Atlassian Data Center pricing, and is delivered through our software licensing advisory practice.
Why the move costs more than the tier price
Atlassian has steadily pushed customers from self-managed Server and Data Center products toward its Cloud platform, and the commercial model changes with the move. Data Center is an annual license tied to a user tier, often run on infrastructure you already own. Cloud is a per-user subscription on Standard, Premium, or Enterprise tiers, billed for every licensed user every year. For many estates the per-user Cloud cost exceeds the Data Center license plus the infrastructure it replaces, which is the source of the 20 to 40 percent increase.
The increase is not universal. Small estates that ran Data Center on costly infrastructure can come out flat or cheaper on Cloud once hosting, patching, and administration savings are counted. Large estates with thousands of users frequently see the steepest subscription rise, because the per-user model scales linearly while the old license tiers flattened at the top. Modeling your own estate, rather than assuming the average, is the first step, and the savings on infrastructure and administration must be netted against the subscription rise to see the real change.
It also matters that the move is, for most organizations, effectively one-way. Atlassian has ended new Server sales and is steering its roadmap and innovation toward Cloud, so the decision is less whether to move than when and on what terms. That reality cuts both ways in the budget: it removes the option of standing still indefinitely, but it also means the migration is a moment of genuine commercial weight, where the terms negotiated will govern cost for years rather than a single transaction.
The five cost components
A complete migration budget has five parts, and leaving any one out produces the classic underestimate. The table sets them out with the typical driver of each.
| Cost component | What it covers | Main driver |
|---|---|---|
| Subscription change | Cloud per-user tier versus Data Center license | User count and tier |
| Migration services | Data move, validation, cutover | Estate size and complexity |
| App re-licensing | Marketplace apps re-subscribed on Cloud | Number and type of apps |
| Internal labor | Project, testing, training, change management | Customization and integrations |
| Productivity / downtime | Cutover disruption and ramp | Cutover approach and timing |
The two components most often missed are app re-licensing and internal labor. Marketplace apps are licensed separately on Cloud and frequently cost more there, and a heavily extended Jira or Confluence estate can carry a large app bill that doubles at migration. Internal labor, the time of administrators, project managers, and testers, is real cost even when it does not appear on an invoice, and it scales with how customized the existing estate is. A complete budget assigns a number to each of the five lines for your specific estate before any commitment is made.
Migration services and data complexity
The data move itself ranges from a near-automated lift for a clean, standard estate to a multi-month project for a large, customized one. Atlassian provides migration tooling, the Cloud Migration Assistant, that handles standard projects, users, and content. Where it gets expensive is the non-standard material: complex permission schemes, custom fields and workflows, large attachment volumes, and integrations with external systems that must be rebuilt against Cloud APIs.
Customization is the cost multiplier: A vanilla Jira and Confluence estate migrates cheaply with the Cloud Migration Assistant. A heavily customized estate, with bespoke workflows, many custom fields, and deep integrations, can cost several times more in services because each customization must be reviewed, mapped, and tested. Audit and rationalize customizations before migrating, not after.
This is why a customization and app rationalization pass pays for itself before the move. Every workflow, custom field, and app removed before migration is one less thing to map, test, and re-license on Cloud. Estates that migrate everything as-is pay to move complexity they no longer need; estates that clean up first migrate a smaller, cheaper footprint and emerge with a simpler platform that is cheaper to run and easier to govern afterward.
Marketplace app re-licensing
Marketplace apps are a cost line in their own right. On Data Center, apps are licensed to the user tier; on Cloud, they are per-user subscriptions that bill alongside the core products. Many apps cost more on Cloud than the Data Center equivalent, and some Data Center apps have no Cloud version, forcing a replacement that carries its own migration and learning cost. A heavily extended estate can find the app bill rivals the core subscription.
The discipline is to inventory every installed app, identify which are actually used, confirm each has a Cloud version and at what price, and drop the rest before migrating. Apps installed for a one-time need and never removed are common, and each one carries forward as a per-user Cloud cost if it survives the move. The app inventory is part of the same rationalization that reduces the services bill, and it is best done as a deliberate review with the teams who own each tool rather than a blanket lift of everything currently installed.
Dual-running and downtime cost
Few large estates cut over in a single weekend. Most run Data Center and Cloud in parallel for a period while content is moved, validated, and users are trained, and that dual-running window means paying for both platforms at once. Atlassian often grants a free or discounted dual-running period as a migration incentive, but the length of that grant and what it covers are negotiable, and a window too short forces either a risky big-bang cutover or paying twice.
Downtime and productivity cost sit alongside dual-running. A phased migration by project or business unit limits disruption but lengthens the dual-running window; a single cutover shortens the parallel cost but raises the risk and the productivity hit if something goes wrong. The right balance depends on the estate, but both the dual-running grant and the cutover approach should be decided and costed before the migration deal is signed, not improvised mid-project.
Data residency and compliance
For regulated organizations, the move to Cloud raises data residency and compliance questions that can drive the tier choice. Atlassian offers data residency controls and advanced security and compliance features on its higher Cloud tiers, so an organization with strict residency or certification requirements may be pushed to Premium or Enterprise regardless of its functional needs. That tier requirement is a real cost input and should be identified early, because discovering it late can force a mid-project re-tier of the whole user base.
Let compliance, not the sales pitch, set the tier: Map your residency, security, and audit requirements to the specific Cloud tier that satisfies them, then license to that tier only for the populations that need it where the platform allows. Buying Enterprise across every user for a feature a subset requires is a common and expensive migration error.
Common migration mistakes
The same errors recur across Atlassian migrations. The first is treating the project as purely technical and never negotiating the commercial terms, accepting the standard Cloud price and uplift when migration incentives and a price cap were available. The second is migrating the estate as-is, carrying every dormant project, unused app, and legacy customization into the per-user Cloud model where each now bills or adds services cost.
The third is underbudgeting internal labor and the dual-running window, then discovering mid-project that the team is stretched and both platforms are billing longer than planned. The fourth is over-tiering, buying Premium or Enterprise across the whole user base for features a subset needs. Each of these is avoidable with preparation, and each is far cheaper to prevent than to unwind after the migration deal is signed and the baseline price is set.
How to control the total cost
The migration is a negotiation as much as a project. Atlassian wants the Cloud move and offers migration incentives, including extended dual-running periods and Cloud discounts, that a prepared buyer can secure. The conditions for a good outcome are the same ones that reduce the technical cost: a clean, rationalized estate, an accurate user count, a tier choice matched to need, and a timed commitment that uses the incentive on offer.
| Lever | Effect on cost |
|---|---|
| Rationalize users and apps first | Smaller subscription and services bill |
| Match Cloud tier to real need | Avoids over-tier on every user |
| Negotiate Cloud migration incentives | Discounts and dual-running periods |
| Cap the renewal uplift in writing | Protects the post-migration price |
| Phase the cutover | Limits productivity and downtime cost |
The renewal uplift deserves attention because the migration sets the baseline for every future renewal. A Cloud subscription negotiated with no uplift cap will rise each year on the full user base, so the time to cap it is at the migration deal, when Atlassian is motivated to close the move. Securing the migration incentive and the uplift cap in the same agreement is the difference between a one-time saving and a durable one. Firm-side help runs through our Atlassian negotiation practice.
One final cost discipline is to treat the post-migration estate as a managed subscription rather than a finished project. Cloud user counts drift upward as teams add members, and unused seats keep billing until someone removes them, so a quarterly review of active users and app adoption preserves the savings the migration achieved. The migration is the start of the per-user cost relationship, not the end of it, and the organizations that hold their Cloud cost down are the ones that govern it continuously.
The action plan
Before committing to an Atlassian Cloud migration, build the full five-part cost model for your own estate, not the average. Rationalize users, apps, and customizations to shrink the footprint you are moving. Choose the Cloud tier that matches genuine functional and compliance need. Then negotiate the migration as a deal, securing Atlassian Cloud incentives, a dual-running window, and a written uplift cap in the same agreement, and phase the cutover to limit disruption.
The recurring lesson is that the Cloud tier price is the smallest part of the migration cost and the easiest to fixate on. The services, apps, labor, dual-running, and uplift are where the budget is won or lost. For an independent migration cost model and negotiation support, see our Atlassian practice and software licensing advisory, with pricing detail in the Atlassian Cloud pricing guide.