Jira Cloud Surprises for Server Admins - thejiraguy.com X-Post

[#1]

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.  

Surprise!

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.

Correction:

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 too 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:

• Manage Product Release Tracks

URL's

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 maybe 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

Functionality

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. :P

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 setup 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 its functionality, it's entirely plausible that it will be storing some of the data that makes up your Jira Cloud Instance. This 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.

Remember, you can find more posts like this at https://thejiraguy.com a full week earlier, so if you find it useful, head on over to the site and read this week's article, where we discuss even more rules of thumb to help you run your Jira instance.  And until next time, Have you updated your Jira issues today?