I sold this transition from the vendor side, so let me be blunt about the play. The migration conversation is engineered to be about Jira and Jira Service Management seats, because that is the headline number everyone is watching. The apps ride along quietly in the back of the quote. By the time finance sees the first true-up, you have re-licensed a dozen Marketplace add-ons at Cloud per-user rates and nobody decided to do it on purpose. That is the gap to close.
If you only do one thing, do this: Book a renewal review
Why do Marketplace apps cost more on Cloud?
Because the pricing model changes shape. On Data Center, many apps were sold as a fixed annual fee tied to your Jira user tier, so a 500-user tier app cost the same whether 50 people touched it or 500. On Cloud, most apps are priced per user, on the same tier band as your underlying subscription, and billed in line with it. Move 1,200 users to Cloud and an app you bought at a 500-tier Data Center price now meters against 1,200.
The vendor framing is that this is fairer and more granular. From the buyer seat it is a re-price, and a re-price always needs to be checked rather than assumed. As of 2026, with no new Data Center sales after 30 March 2026 and Data Center renewals running only through 30 March 2028, the migration clock is real, but the clock pressure is exactly what makes buyers skip the app audit. Do not skip it.
Which apps actually need to move?
Most estates carry apps that no longer earn their place once you are on Cloud. Three buckets are worth separating before you sign anything.
| App bucket | What the vendor assumes | What to do instead |
|---|---|---|
| Native-now features | Re-license the app on Cloud | Drop it. Cloud Jira Service Management may cover the function natively, so confirm before paying again. |
| Low-usage add-ons | Carry the full user count across | Right-size to active users or cut entirely. An app 40 people use should not bill against 1,200. |
| Mission-critical apps | Per-user Cloud price, list rate | Keep, but negotiate the Cloud rate and ask the Marketplace vendor for a migration or co-term discount. |
The discipline here is the same one we apply to seats. You do not move what you do not use. Reconciling app usage against real activity before migration is the cheapest saving in the whole project, because an app you never re-license costs nothing to negotiate.
How do I avoid paying twice during the migration?
This is the trap that mirrors the seat problem. While you run Data Center and Cloud in parallel, you can end up paying for the same app on both sides for the overlap window. The fix is to time the cutover and ask for grace. Atlassian has offered cloud migration and loyalty pricing, and many Marketplace vendors will grant a dual-use or co-term period so you are not double-billed during the switch. None of it is automatic, and none of it appears unless you ask in writing and name the apps. The same double-payment logic on the core subscription is covered in Atlassian dual licensing during migration, and the app layer follows the same rules.
What should I negotiate on the apps I keep?
Three things, in order. First, the per-user Cloud rate itself, because Marketplace list prices are a starting point and bundled migrations are the moment vendors are most willing to move. Second, a co-term so every kept app lines up with your Jira Service Management Cloud anniversary, which removes the scatter of renewals that quietly erodes leverage. Third, a capped uplift on the apps that matter, so the saving you win at migration is not given back through annual increases on the add-on layer.
Work the app negotiation as part of the platform deal, not after it. Once the core Cloud contract is signed, the apps lose their leverage, because the vendor knows you have already committed the estate. We fold the Marketplace layer into the wider Cloud move inside the Atlassian Data Center end-of-life migration guide, which is the hub for the whole transition.
Our gated Jira Service Management Negotiation Guide includes the app-audit worksheet and the Cloud migration term sheet that drive this sequence.
A simple sequence to control the app bill
Run it in this order and the app layer stops being a surprise.
- Export every Marketplace app and its current Data Center cost, user tier and renewal date.
- Pull usage for each app so you know who actually invokes it, not who has it enabled.
- Sort into the three buckets above: drop, right-size, or keep.
- Model the Cloud per-user cost for the keep list against your real Cloud user count, not the old tier.
- Negotiate rate, co-term and uplift cap on the keep list, inside the platform deal.
- Time the cutover and secure a dual-use grace window so you never double-pay.
This is the work behind the headline numbers. Across ITSM and adjacent platform engagements the firm has negotiated more than $420M of contract value and averages a 30% reduction, and the app layer is one of the places that saving hides in plain sight.
Frequently asked questions
- Do Atlassian Marketplace apps cost more on Cloud than on Data Center?
- Often. Most Cloud apps price per user on your subscription tier band, while many Data Center apps were a fixed annual fee on a user tier. The Cloud bill meters against your full user count, so confirm each app's Cloud model against your order form.
- Can I get credit for unused Data Center app time when I move?
- Sometimes. Atlassian has run migration and loyalty discounts, and some Marketplace vendors grant co-term or dual-use grace periods. None of it is automatic. Ask in writing, name the apps, and tie the credit to your migration dates.
- How do I stop paying for apps I no longer need on Cloud?
- Audit usage before you migrate. Drop apps that Cloud covers natively or that nobody uses, and right-size the user count on the ones you keep so you are not paying for inactive seats.
Control the app bill.
We audit your Marketplace estate, decide what migrates, and negotiate the Cloud rate inside the platform deal. Fixed fee or gainshare.
Book a renewal review →