Well, last week was fun, don’t you say? Well, from one perspective, it was. You guys shared, commented, and drove a ton of views to the post – so much so that it got the attention of Atlassian’s top brass. Of all the emails I was expecting in all this, that one was not it. We are still ironing out the details, but exciting things are coming for the blog.
However, time does move on, and so do we. One complaint I heard last week was my numbers were off because of one reason or another. And on that note, I must disagree with you – slightly. The situation was off, not the numbers. I was looking at a pure situation where you were running no add-ons, and you were not applying discounts. And I stated in the post that it was not a realistic scenario, but it was good enough to get a basic idea of what was going on.
The reason I went with this approach in the previous was for the sake of this post. I can analyze one situation and maybe help one person. Or I can provide a method to do your analysis and help vastly more people. I knew I wanted to do this as a follow-up. It did not help with how suddenly Atlassian announced these changes, but that’s another story.
So, let us get into it. How do you know which path you should take for your situation? Is there even an option? What are your constraints: costs, functionality, performance, or regulations? Unfortunately, there are so many variables that this answer is likely to be unique to everybody who does the analysis. So without any more stalling, here we go.
For this analysis, I’ll be going through my process on my instances for The Jira Guy. That way, you can see what this looks like in a real scenario.
Sensitive Data anyone?
So, let me save you a step here. Are you in a regulated industry? These include industries like Healthcare, education, government work, or the financial sector. And if you are, you will likely have some regulations that apply to you. These take various forms (HIPAA, FERPA, FEDRAMP, SOX), but the fundamental uptake is that you, as the admin, are ultimately responsible (legally) for safekeeping the data stored in your Jira instance.
This requirement means you need to control your data and not having it floating in the cloud somewhere. So, your answer comes out real quick. You don’t have an option; you must use Jira Data Center. I know Atlassian is working on getting certified against these various regulations, but that doesn’t change where we currently are. And this situation sucks, as Data Center is not currently available below 500 users, but here we are.
So, let’s assume that you are not in a regulated industry, and therefore have a choice. The next step we need to do is figure out what we have, how many people are in those instances, and how we expect it to grow. I like to use My.atlassian.com to get a baseline.
As you can see here, I’ve listed all my current server products, their current tier, current license usage, and where I expect that to be in a year. Estimating growth can be tricky, but a best-guess is sufficient here.
Next, we need to get a measure of how many resources the system is using. The principal metric I am interested in here is how much space are the attachments taking in Jira and Confluence – as these are one of the regulated features in Jira Cloud.
To get this, I like to go to the system, and as root, run the following commands:
du -sh /*
du -sh /data/*
For Bitbucket, this isn’t as important to measure out.
Given the attachment pool for Jira or Confluence, we can make a few decisions right away. We can look at the attachment limits listed here and make some inferences.
|Product with Plans||Storage|
|Jira Core||Free||2 GB|
|Jira Software||Free||2 GB|
|Jira Service Desk||Free||2 GB|
So for my example, I’d be good at the Standard Tier for Jira Service Desk and Software, but for Confluence, I would need to use the Premium Tier.
Of course, if the cost of a higher tier at your user count is high enough, Data Center might be a worthwhile move. But this is why we do the analysis.
So, another thing to consider in your move is what Apps you are running. Unfortunately, not all Atlassian Apps are created equal, and each one has varying compatibility. That is to say, you might not be able to run a Server App on Data Center, and likewise, you might not find that App available on Cloud.
So the first step here is, you guessed it, taking stock. Go to each system you run, and make a list of which plugins are active on that instance. If you have any disabled, now might be a good time to uninstall them outright.
While you are looking up what you are running, also put down how vital that App is for your company. Is it a Must have or a nice to have? This determination will help you make some decisions here in a moment.
Now that you have a good idea of what is running, you have a bit of a tedious task ahead. You need to go to the Atlassian Marketplace and look up each App. We want to know which Apps are available for Cloud and which ones are available for Data Center.
At some point, you will run into a situation where an App you are running is not available for either Cloud or DC (or both!). This situation is where that Priority column comes in handy. Can you live without the App? How important is it?
As you can see from my list, most of my Apps are not available for Cloud, whereas I am only missing two for Data Center, and only one is listed as a must-have. At this point, I have two options: I can try to find an alternative, or I can re-evaluate how important it is. In this case, Reactions are nice, but they won’t kill the use case.
Now comes the “fun” part.
Do you like math and research? I hope so because that’s what’s next. We need to start looking at the pricing for the various options. To do this, I’d start looking at the pricing page on each of the products.
Take special note of the Cloud pricing as, by default, they give it to you in a “per user per month” figure – making the cost seem lower than it is. To fix this, I multiply the provided number by 12 and then again by the current number of users I have. When I get done, the figures look something like this.
These numbers are great to have, but they still aren’t a complete picture as Atlassian is offering a one-time “Loyalty Discount” if you upgrade to Data Center. These break down as follows:
Before July 1, 2021:
- Jira Software and Confluence (up to 1000 users): 25% discount from then-current published list price
- Jira Software and Confluence (1,001 users and above): 40% discount from then-current published list price
- Jira Service Desk, Bitbucket, Crowd (all user tiers): 40% discount from then-current published list price
Before July 1, 2022:
- Jira Software and Confluence (up to 1000 users): 15% discount from then-current published list price
- Jira Software and Confluence (1,001 users and above): 30% discount from then-current published list price
- Jira Service Desk, Bitbucket, Crowd (all user tiers): 30% discount from then-current published list price
Before July 1, 2023:
- Jira Software and Confluence (up to 1000 users)): no discount
- Jira Software and Confluence (1,001 users and above): 15% discount from then-current published list price
- Jira Service Desk, Bitbucket, Crowd (all user tiers): 15% discount from then-current published list price
So the earlier you move, the more you save. Combine that with the fact that Data Center’s prices are going up in Feb. 2021, waiting can cost you a LOT of money if you are leaning Data Center.
So applying these Numbers, I get the final picture of:
So now I have a complete picture. I know that I’ll be saving money this year with Data Center on every item but Bitbucket, and the price difference is close enough, I can justify the increased cost.
However, that’s this year. Next year, the bill will come soon enough. And with the price increases, what does that look like? I decided to extend the Excel out another row to see precisely that, and here’s what I came up with, using these tables from Atlassian.
Ouch. Well, we’ve already switched to Data Center based on last year’s number, so let’s look a bit closer. Yes, Cloud Standard is cheaper than the new prices. However, Your Jira instance already has 150 GB of attachments this year, and that’s only going to keep growing. You may need the Premium tier for that next year, or you might not. But eventually, you would cross that 250 GB Limit. And at that point, Data Center looks more favorable. So you can either go through two migrations in as many years or absorb the costs if you even still qualify for Standard next year.
So we’ve talked about Legal Requirements, Usage, Storage, Pricing, Discounts, and Future Price Increases. Now we get to talk about Intangibles. You can’t put a hard number on these factors, but they will have sway on how you choose.
For example, if your organization is “Cloud-First,” you will be looking to put as much into the Cloud as possible. You can’t put a number on that, but this will likely cause you to choose Atlassian Cloud over, say, hosting a Data Center instance in Azure.
Then there are the factors your users demand. Do they value Jira being available no matter where they are? Or do they rather Jira perform well no matter what? Each of these considerations would lead you to choose one platform over the other and will vary wildly from company to company.
Unfortunately, I cannot help you here without knowing your specific circumstance, but I did want to get you thinking about it.
And that’s it.
I wasn’t lying when I said a lot of factors come into play. Between App availability and requirements, legal data residency requirements, pricing, growth, usage, and even the things you can’t quantify, you have a lot to consider. However, sitting down and weighing each option should lead you to the best choice for your situation.
Remember, while you save more if you choose Data Center earlier, Jira Server will not go anywhere for three years, and the situation is very much still in development. So maybe Atlassian will consider a lower DC Tier. Or perhaps Cloud will be re-written to be much faster. As an independent blogger, I cannot tell you what’s going on inside Atlassian – I have the same view you do most of the time.
So – about the blog.
Last week…Just wow, guys. You shared the blog, helped spread it, and I still have to do a double-take at the resulting numbers. Seriously, this happened today.
Four thousand in a month. So, thank you so much. You all make this worth doing each week.
Last week, I was also contacted by someone high up at Atlassian. I won’t reveal contacts, but they stated they appreciated the post and that while Atlassian knew customers would be upset, they would hope that customers would eventually understand. And Atlassian felt my post went a long way towards that.
They also noted my concerns about having access to the Tools to make blog posts and offered to help. And as of yesterday, The Jira Guy’s Atlassian tools are sponsored and paid for through Server End of Life! I had joked once that if I could get my Atlassian bill paid for, I’d consider the blog a success. Well…here we are.
And while I still celebrate this good news, I haven’t forgotten that many of you out there are still confused, upset, and worried. I want to remind you that I intend to be your partner through this. I’ve already written a guide on setting up your own Jira Data Center instance, and once I can get approval for it, I intend to write a guide on Jira’s Cloud Migration Assistant. I’ve had my worries lifted so I can help you, and I won’t lose sight of that.
So, don’t forget to go ahead and subscribe if you found this post helpful. You can find the form for that below the post. I post new content every Wednesday at Noon EST, so also follow me on Twitter, Facebook, and LinkedIn to be alerted when new posts come up. And if you can and want to help fund what I’m doing here, head on over to Patreon and subscribe. You’ll get access to exclusive content I won’t be posting here, a chance to vote on upcoming articles, and a chance to join our monthly conference calls. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”