Jira Cloud Surprises for Server Admins

So, we are in the end-game now. Atlassian has stopped selling “net new” Server licenses and is only renewing existing licenses at this point. I guess that explains the results from the polls I ran last week.

So – taken together, the people have spoken. This week we’ll be looking at “Cloud Gotchas” you can expect if you’re used to managing a Server or Data Center instance. These are little surprises you might not have experienced before or something that works completely differently in Cloud. So, let’s dig into this:

“Next-gen” Projects

So, I’ll get the biggest Gotcha out of the way. In Server and Data Center, you have Projects, which are a way to divide out the issues on an instance. Each issue is tagged with a Project Key, and a bunch of settings can be set at the Project level to affect how the associated issues behave. They come in 3 overarching flavors (Business, Software, and Service Desk), but a project is a project at the end of the day.

In Jira Cloud, Atlassian said, “If we had to build the idea of a project from scratch again, what would it look like?” – then built that into the product. These are called “Next-gen” Projects. The old Projects you are used to from Server and Data Center are still there but are branded as “Classic” Projects.   Subtle Atlassian…

The easiest way to think of a Next-gen project is to imagine that each project was hosted on its own independent Jira instance. The settings for a Next-Gen project are entirely isolated, making you free to make changes without impacting other projects. It also means you cannot reuse things like custom fields and workflows between projects, but that is the trade-off. 

One of the biggest benefits I can see to using a Next-Gen project is delegation. No longer will the Jira administrators be a bottleneck for things like requesting custom fields and workflow changes – that can all be handled by the Project Admin, freeing you up to focus on more significant issues. However, as I stated above, this comes with the trade-off that you no longer have control over the instance’s custom field count.

Surprise Upgrades

So – upgrades can be stressful. Things are changing, which means you have to, once again, appease those people who hate changes. And then there is the dice roll that is “Will this upgrade break a critical App or Integration?” If you caught it in testing, it leads to the mad scramble trying to figure out a fix or a work-around. If not – well, Mondays are fun, aren’t they?  

But you at least have control of when this process happens. You can time it around critical events in your organizations, such as releases and holidays. You can delay an upgrade if something is broken so that your system stays usable. You are in control. I assume you can see where I’m going with this.  


Yep, in Jira Cloud, upgrades happen whether you are ready for them or not. And often, changes are rolled out with little-to-no warning. Meaning if Atlassian pushes a change that breaks your teams’ workflow – the first you may hear of it is when said teams are calling you.  

Now, as with everything else in here, this is a trade-off. I know as an Atlassian System Administrator, much of my time over a given year can EASILY be taken up by upgrade testing. Having Atlassian worry about that part would save me a lot of time. I can then focus on other priorities, such as onboarding more teams and training. But that gained time does come with risks.


My colleagues at Atlassian were rather quick to point out a fact I forgot to include.

Under Premium or better, you can bundle together updates, which would give you a little more control over when they deploy. This does give a bit of time to find fixes for and prepare for updates before they are applied to your Cloud Instance. It’s not much time, and if you delay to long the update will be applied anyways, but it’s better than waking up to a surprise.

However, this is an advanced feature that is part of an upgraded package, so if you are on the base Tier, the above still stands.

You can read more about the Release Tracks feature here:


So, as a Server and Data Center, you are used to controlling how your users access Jira. Most often, it’s through some sub-domain of your company and may look like jira.superawesomeurl.com. And this is awesome. 

However, you don’t have this luxury in Jira Cloud. As much as it may surprise you, all Jira Cloud URL’s end with atlassian.net. Do you happen to own the superawesomeurl.com domain? Too bad. You are now stuck on atlassian.net. Honestly, this still surprises me. Most other services at least offer a custom domain as an upsell. The fact Atlassian isn’t may be a missed opportunity.

User Management

So, just saying, this is something I think Cloud wins on. You are rarely managing just Jira. Often, it’s Jira and Confluence, with the Occasional Bitbucket or Bamboo thrown in for flavor. And unless you are also running Crowd in that mix, you often have to go to each Application to manage users and groups. Active Directory integration helps, but it’s as often a hindrance too. 

However, in Jira Cloud, users are managed in a central Organization. This arrangement means you have a one-stop-shop if you need to manage a user – you no longer need to stop by each Application individually.  

That being said, I’m not ashamed to admit I spent an hour trying to find the user settings on my first Jira Cloud instance before admitting defeat and looking this up.  

Marketplace Apps


So – this may not exactly be a gotcha. Honestly, it may be saying the quiet part aloud. But if you are already on Jira Server and Data Center and looking to move to Jira Cloud, not all of your favorite Apps will be waiting for you. Even those that are also available on Jira Cloud may have different functionality than you are used to.

Jira Cloud is built on a completely different architecture than the Server and DC products. This fact has meant not all Apps could make the jump to Cloud – and of those that could, many have had to rework how the Apps work entirely. 

I like how one vendor I spoke to put it:

“At this point, we are no longer thinking of feature parity, but rather value parity for our customers.”  

That is to say, Apps may never have a 1:1 replacement in the Cloud, but this particular vendor was putting their efforts into making sure their Cloud App was still worth your money. And no, I won’t name names. 😛

App Hosting

However, there is another Gotcha to do with Marketplace Apps we haven’t even begun to discuss yet. Another Gotcha you should be aware of is that Marketplace Apps are not a part of your instance. What do I mean by that?

In Jira Server and DC, Apps are a jar file that is imported into and ran within the overall Jira JVM. This set up allows fairly deep integrations within the Application and means that it’s rare that you will have an App Fail while your central instance is still online. 

However, in Jira Cloud, App Vendors host their Apps separate from your instance. In this regard, Apps are more of an integration than a part of the process. This arrangement is why Server/DC Apps and Cloud Apps sometimes cannot have the same functionality. However, it also means that your Jira Cloud instance can be up, but the Apps to be down. The fact that Cloud Apps aren’t beholden to the same SLAs as Jira Cloud has been a point of contention for a while.

This setup has security implications too. Because each App self-hosts their functionality, it’s entirely plausible that they will be storing some of the data that makes up your Jira Cloud Instance. Which means if you have security or data residency requirements, you will have to vet not only Atlassian but any App Vendor you plan to use

User Limits

Do you remember when an unlimited User license in Jira wouldn’t cost you a supercar? The Jira Guy remembers.

I joke, but it is something for you to be aware of. Jira Cloud has a hard limit of 10,000 users per instance. This rule is not up for negotiations – if you try to add user 10,001 to your Cloud instance, the Organization (which can have more) won’t let you.  

“But I was told the Enterprise Tier lets you have more?” you say? Well, that is all smoke and mirrors. They let you have more by letting you have multiple Jira Cloud instances – which collectively add up to more than 10K, while each one is still limited to 10K each. 

So what do you think?

Have you encountered any gotchas on Cloud I may have missed? Feel free to share them in the comments! If I get enough, I may do a part two.

Don’t forget you can also follow me on LinkedIn, Facebook, Twitter, and Instagram! There I’ll post community updates, random polls, and sneak-peaks into posts I’m working on. You can also subscribe to the blog to get new posts delivered straight to your Inbox! As usual, the form will be at the bottom of this post. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”



  1. Darn, I was hoping this article would be an announcement of new Cloud-specific news that would help on-prem admins! 😅

    Glad you found out about release tracks – hopefully Atlassian includes the track option “Really, Really Slower” to allow for more warning/training for certain feature updates.

    And if you haven’t voted for https://jira.atlassian.com/browse/CLOUD-6999 “Allow custom domains for Cloud apps”, do it if you’re interested in that!


  2. “One of the biggest benefits I can see to using a Next-Gen project is delegation. No longer will the Jira administrators be a bottleneck for things like requesting custom fields and workflow changes – that can all be handled by the Project Admin, freeing you up to focus on more significant issues. However, as I stated above, this comes with the trade-off that you no longer have control over the instance’s custom field count.”

    Great… or not… Im into tight administration and not users making own fields… its a bad way in the long run, when You have 5-15 fields called “bla bla” – each of different type. Will make JQLs really sufficient.

    I have never seen a Jira Instance that has benefitted over time from more than 2-3 admins actually knowing what the do. But hey – Im paid to clean up as a Atlassian consultant….

    Talking about surprices:

    What About – https://jira.atlassian.com/browse/CLOUD-6999 – So year, +10 years for resolving, so You are for sure stucked with Atlassian.net. Surpricingly postponed again.

    I am so glad You actually mentioned the distributed cloud architecture: https://community.atlassian.com/t5/Jira-Core-questions/SLA-for-Addons-in-JIRA-Cloud/qaq-p/133291

    Currently in Europe, the Schreems II verdict actually blocks most cloud usage for us, as we cant put several types of data on Cloud services that are under US Laws.. (thats for sure debateable currently)

    I’m all for cloud – but Server Admins and people migration should know the differences, alt not all good!

    Liked by 1 person

    1. I’m just happy Atlassian is trying with CLOUD-6999 versus other tickets.

      The cost of switching their established atlassian.net infrastructure to support custom domains (and in a way that’s generally acceptable to customers) is so high. Imagine the redirects, potential XSS issues to mitigate, and behavioral quirks in their app (how many links depend on a BASE_URL, how many are writing *.atlassian.net references…), etc. to resolve?

      As a step one, maybe they should have new Cloud instances potentially support custom domains.

      +1000 on Next-Gen projects and custom fields. In what world is a Next-Gen project helping a small team? As soon as they realize they can’t do cross-project reporting (as easily as centrally-managed classic projects), freakout ensues.


      1. I also agree with the two of you on having to maintain control over custom field count. My comments in post were to say I could understand how – on paper- Next-Gen projects sounds like a good idea. But I’ve had to clean up too many instances with “Rubber stamp” policies around Custom fields to think unfettered access to Custom Field Creation is a great thing.

        I think for Next-Gen projects to be successful, you really would need to up your training game. Anyone you trust to be a Project Admin would need to undergo training to explain when you should (and more importantly, should not) create a custom field, as well as what the impacts are on a system with too many custom fields. You know – the things you normally hire Jira Admins to think about…

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.