So, a few weeks ago, I was contacted by Jira Gal Heather Rimmey. She had seen a comment I had written in reply to someone’s comment about Jira Cloud and Jira Server. It turns out she was having the same discussion with management and wondered if I had any thoughts on the differences between the two deployment models. And well, we all know I do! This week, let’s dig into the differences and discuss when one option may be preferable to the other.
As a note, I’ll be using “Jira Server” a lot during this post. Please understand it to mean Either Server or Data Center. While the two are very different deployment models and have unique feature sets, it’s an excellent grouping to keep this post from getting too confusing.
One is not better than the other.
Let’s get this over with first. I do not think a Server Deployment is better or worse than a Cloud deployment. However, I believe that they are very different creatures who both happen to bear the name “Jira.” That is to say, just because you have experience with Jira Cloud doesn’t mean you’ll transition smoothly to a team using Jira Server and visa versa.
That’s my most significant point, and one I cannot stress enough. Most groups I talk to fail to consider a certain “relearning” time that will cause overall productivity to go down after a migration. Your teams will need to learn how to do all the things they knew on the old platform. This can be offset a bit by training, but only to a point. It’s something to consider.
Control vs. Ease of Use
This concept, as I see it, is the main selling point of Jira Cloud. You don’t have to learn how to set up a server or run an upgrade. You request your site, and within moments you have a Jira instance! Congratulations.
And this is great! If you are a small team, you don’t need that overhead. However, just like everything else Jira, this is a trade-off. Atlassian is continually pushing out updates and upgrades to Jira Cloud. This model means you often get not only bug-fixes first, but the latest and greatest features that the On-Prem deployments may not receive for months or years.
But what happens when Atlassian pushes an update that breaks your processes? Like when they pulled the Cloud version of the Automation for Jira app before the built-in version was completely ready? Don’t get me wrong, I have staked my career on Atlassian’s products, and will be their biggest cheerleader as a result, but sometimes “oops” happens.
With a Server deployment, I can find these “oops” moments in a testing phase of an upgrade. I can then choose to hold off the upgrade until I find a workaround or Atlassian fixes the bug. But you don’t get that luxury in Cloud. The best you get is the ability to put off an upgrade by a few weeks – but only on their highest-tier plan.
Again, not saying this a bad thing. It’s a trade-off for getting all the new toys before the rest of us. But it’s definitely something to consider.
Site Names
This fact maybe just me, but I’ve always been fascinated by Product marketing and branding. As my wife will attest, if I find an interesting product packaging at a grocery store, I will derail the whole thing for a moment while I take a closer look. I’ve honestly purchased some products before so that I can take a closer look at its packaging. It’s kind of sad and funny at the same time.
What does this have to do with Jira Cloud? I’m getting there. Every Atlassian Cloud instance has the following URL Structure: <yoursite>.atlassian.net. What if you prefer jira.thejiraguy.com? Too bad – can’t do that with Cloud. At some companies, this isn’t a big deal. You can still have your company name somewhere in the URL, and that’s good enough.
But that’s not every company. Some companies feel having their URL there is essential for customer perception. I can’t say I wholly disagree with this idea, either. I intend to eventually do a review on a tool that allows you to put public sites (like Atlassian Cloud) on your domain, but even that is just a workaround.
However, on Server, that is the point. You set it up on your servers, so you will need to have the URL set up, too. So you can use whatever URL you have control over.
Scaling
This is a point I think Jira Cloud does a great job on. Look, no matter how robust your system is or how much care you take over your configuration, if your userbase continues to grow, you will eventually outgrow your single server instance? What then?
Well, you are looking at a migration to Jira Data Center. This process presents its own hurdles and challenges. Just like a Server to Cloud migration, not all Apps that are available for Server are also available for Data Center. You will likely have a larger instance at this point, which means you might be trying to move a large amount of data around. Not fun.
And what do you have to do to scale Jira Cloud? Either pay for more users, or on the odd occasion, pay for a higher tier. That sounds a heck of a lot easier to me.
Apps
While this will be my last topic today, it is not anywhere near the last difference between the two deployment models. I’ll be including some additional reading if you want to explore all the differences yourself.
However, I’ve already touched on this one in this article, and it’s probably one of the most annoying things about the deployment models.
Jira Server Apps are not compatible with Jira Cloud, and visa versa. What does this mean functionally? It means that if you are considering moving from one to the other, you have to sit down and look at every single App you are running and determine if they have an equivalent on the other model. And most of the time – there will be at least one or two Apps that don’t.
Then your job is to sit back down and determine if another App is available to give you the same functionality, or failing that, determining if you can live without that App. And honestly, having to find out if you can “live without” happens more often than not.
There is another effect to this incompatibility. I cannot count how many times I am searching for a plugin to solve a specific problem, and I finally find the perfect App. It’s well-reviewed and has a large install base. And the documentation is thorough and doesn’t look too involved. Then I look up and realize it’s only for a whatever deployment model I’m not on. It’s honestly enough to drive one mad sometimes!
Further Reading
As I’ve stated earlier, these are far from the only differences. However, if I were to write on every difference – and the practical effect of each one – I’d be writing a book. However, if you are interested in reading further, I do have two links you would be interested in. The first is a high-level differences in the Cloud platform for all the tools. The second is more specific to Jira.
Look, if you are considering moving to the Jira Cloud, or just want more information before committing to a platform, I encourage you to read through both carefully. Figure out what trade-offs you can live with and what you can’t. Jira Cloud may suit your needs very well. Or it might have several deal-breakers. The only way to know is to do your research!
And that’s it for this week!
Before I forget, big news from this past week! Atlassian announced that they are renaming Summit 2021 to Team 2021! I don’t think we know if this will be the same once we can meet in person again, but I’m still excited. They have also opened up submissions for Speakers for Team 2021. I’ve put in three presentations from some of my favorite posts over the past year, and hopefully, I can get selected! If you have any interesting ideas for presentations, breakout sessions, etc., why don’t you submit too! Nothing ventured, nothing gained!
However, if you’ve found this post helpful, why don’t you give it a Like? I post new articles every Wednesday, so you can sign up below to get it delivered directly to your email inbox! You can also find me on Facebook, Twitter, and LinkedIn, where I’ll post updates, news, and new posts – so be sure to follow!
The Jira Guy 