So Long, Server

First, I should note a bit of a disclaimer: Opinions in this blog have been and always will be mine – and in no way represent the feelings of Coyote Creek Consulting or anyone other than me.  

Well, the writing has been on the wall for a while – but it seems that dreaded day is here. Last Friday, Atlassian announced that they would sunset the Server products. Starting next February, Atlassian will no longer sell new Server licenses. Three years after that, they will stop all support for Server products, including bug fixes and security updates. Afterwards, your options are Jira Cloud – which will be the only option for smaller teams – and Jira Data Center. 

I want to hate this decision.

On an emotional level – this is a gut-punch. I often say I try to be one of Atlassian’s biggest cheerleaders, but this week it’s been hard to be that. I started on Server because, for the longest time, that was our only deployment model. I still run a Server instance for Jira and Confluence in my home lab to support this blog. It’s how I’m able to capture a lot of the screenshots that I require for the blog posts. My licenses will come up for renewal before the price increases take effect, so I’ll be good for another year or so. After that – well, let’s hope I can get sponsorship. 

However, after running the numbers, I can’t hate it entirely. In the end, it will save most customers something. A few will pay more, and a few others are left out in the cold, but most people will save money. I will add this – if you plan on moving to Data Center, it will behoove you to go ahead and buy your licenses as soon as possible rather than wait for Feb. 2021. Those price increases are sharp, just saying.

So – let’s talk about those numbers.

I should note a few things here. First, I am only looking at the base Jira Software product, with no add-ons. This is not completely realistic, but it’s good enough for a comparison. I do intend to have an overview of how you can do a detailed analysis of your instance to figure out if Cloud is right for you next week. But for now, this will be good enough.

For Cloud, it is using the Standard Plan. I should also note that Data Center’s license model has a lot more tiers than Server does. So even though you might be on a 10K Server license today, it doesn’t mean you will have to go up to a 10K DC License. You might be able to get away with a 5K license if you have less than 5000 users, which would save you half that cost. Hence the asterisk.

Source: Future DC Pricing. Markup calculated as New Price / Old Price * 100

However, with a few exceptions, most people will save money versus their current Server Prices, so long as they are free to choose Cloud or Data Center. I fully get that not everyone is free to choose, but I’ll get to that in a moment.  

Now let’s get into it. As best I can tell, for the big three – that is Jira Software and Core Server, as well as Confluence Server – the prices are not increasing if you pay list price. If you are on a discount plan, your costs will increase, but that’s not most of us. The other Server products will see an increase, though, so it might make sense to review Atlassian’s docs for yourself.  

But back to the big three, the only costs that will increase are on the $10 Starter Package – which is going away entirely next February. That means you’d have to pay the next tier up – which is a hefty jump indeed. This one saddens me the most, as this tier is invaluable for people learning to become an Atlassian System Administrator. I’m sorry, but the Cloud is no substitute in this regard, just by the nature of being what it is.  

While this loss is sad, We can at least take a look at other scenarios to figure out how it will impact you moving forward.

So, About that Cloud thing you mentioned the other week.

Look, I don’t know how plainly to put it. Right now, if you are under 250 users, and Cloud is a viable option for you, you will save money on the Standard Plan over either Server or Data Center. This “break point” shifts when the new pricing goes into place such that anyone under 1000 users is now the winner.  

Now, I don’t care for Atlassian’s Cloud Product because it has its problems. No use lying about it, and that’s not what you come here for. However, Atlassian is investing heavily in it, and I don’t think the problems are unsolvable. And I’ve been given some sneak previews from Atlassian – exciting features are coming soon. So yeah, between Server’s End of Life and Data Center’s lack of smaller tiers, Jira Cloud is something to look into.  

However, not everyone has that luxury. This group was my first thought as I read through the announcement, and they still are. And I don’t think Atlassian is paying enough attention to them.  

Simply put, specific segments cannot move to Atlassian Cloud. Here in the United States, these include teams in the Financial Sector, Healthcare, Government work, and Education. The requirement here is almost always regulatory, which means this isn’t a preference. They are required by law to host their data.  

And this would be fine if Atlassian would provide lower tiers for Data Center. But as it stands, they won’t. So if a team happens to be smaller than the 500 user mark, they now have to pay for way more licenses than they need to meet regulations.  

And what about Data Center?

Look – the price increases set to take place for Data Center are going to hurt. Most are around a 200% increase in price. If you choose to move to Jira Data Center, you will be paying more over what you paid for Server after February. Just that, plain and simple. If you can lock in your license before then, you will be saving a good chunk of change for the year. So my recommendation is lock in those licenses early if you are thinking about going this route.

The good news here is you don’t have to redo your architecture to take advantage of a new DC license. You can drop it into your current Jira Server instance in place of its server license, and you’ll instantly unlock the new features associated with Data Center. From there, you can take your time to build out your infrastructure to make it a true Data Center instance – or not. All depending on your needs.  

Another thing to consider on Data Center is your license model is different. On Server, your license is perpetual. That means if you let it lapse, you can still run and use Jira just fine. You won’t be able to upgrade it to a new version or get Support from Atlassian, but it will still work. Honestly, I’ve heard from some companies that run their Atlassian tools like this – only getting a new Server license when they plan to do an upgrade and only doing an upgrade every few years. 

However, in Data Center, that’s is not the case. If you let your Data Center license lapse, your instance locks up, and you cannot use it until you get a new one. This is because Atlassian considers its Data Center license to be a “subscription,” which you need to pay annually. Just something to think over if you haven’t looked at DC before. 

Viral Marketing

So – as I mentioned last week, I can be something of a marketing nerd. And I’ve loved Atlassian’s strategy they’ve employed for years now. They’d start small in a given company. Maybe a guy used Jira at his old job, and he recommends it to his team. They adopt it, build on it, and it works for them. The next team over sees their success, adopts Jira, and it grows. Before you know it, an entire department is using it. But then Legal notices what it can do and wants in. So does HR. And Accounting. Now your full company is using Jira, and you have a large instance.  

This process is honestly how I see Jira adopted most often. It’s not a top-down decision; it’s a bottom-up grassroots movement. However, will this process still work if the teams start on Jira Cloud, where the license costs are per user? I don’t know if one team manager will want to foot the bill for another team using “their” platform. It seems Atlassian might be thinking more of the top-down approach is the future. Or they have data that says this isn’t a problem. As I said, I don’t know, but I’m going to pay attention to what I hear from the ground.

Remember, you have time.

Look, this announcement feels sudden. But don’t let it spook you. Jira Server will still be here for over three years. This period gives you plenty of time to evaluate all your options and move there before Jira Server has its End-of-Life.   

However, hasty and emotional decisions are rarely good ones. It’s one reason why I wanted to wait to say much publicly until I could calm down, get the emotion out of it, and figure out the real story here. Trust me when I say that my outlook on Friday was a lot more panicked than it is as I write this today.  

So stop, take a breath, and relax. You’ve got this. If you are on a Server instance, it’s not the end of the world. It’s just the start of the next leg of your journey. 

Questions from you

Considering I made no secret of today’s topic to everyone, I figured I’d open it up to Social Media to see if they had any questions. And of course, you guys came through. So let’s see what your concerns are?

“Did Atlassian make a good call to announce this change considering, that cloud is still very much not a mature platform yet?” – Vitalijus Šerpytis

Do I think this timing is ideal? No – not at all. Look, we are still in a massive global pandemic, the economy is in a global downturn as a result, and to have this enormous change on what most companies consider a vital resource during this time is…less than ideal.  

However, I also don’t think they necessarily had a choice. In a previous article, I made note that Atlassian is a relatively small company for their outsized reach and influence. And this small company has been splitting its attention between Server, Data Center, and Cloud for a while now.

And yes, we know Cloud has been getting the lion’s share of the investment for a while now, too. It’s where all the new “cool” features are premiered. However, Atlassian Cloud does have some fundamental problems. You know it, I know it, and you better be sure Atlassian knows it. And at their current setup, they don’t have the resources to fix that.  

Atlassian also sees data that says most new people to their products are starting in Cloud. This fact tells them two things: A) Their future depends on Cloud, and B) They don’t have the resources to fix Cloud and support Server and support DC.   

Between Server and Data Center, Server’s been trending downwards, while DC upwards. Of course, this trend exists – people are migrating away from Server to Data Center and Cloud, so it’s going to go down, but the data still is what it is. 

So given all the facts above, if you had to make the hard choice, which would you make? As I’ve stated, I think this decision does ignore some critical use cases, but I can at least understand the decision.

“How can customers trust Atlassian is going to offer DC going forward given all their actions in the last few years?” – @jonjonbling

Hmm, just asking all the hard questions. Look, I am not a part of Atlassian, so I cannot say what they are going to do with any certainty. However, Server and Data Center have a fundamental difference that makes Data Center more attractive to keep onboard: DC is a subscription license.

For Server, you pay once for your license; then, you pay a smaller “Maintenance” fee every year after for access to upgrades and Support. If you don’t plan to upgrade and don’t feel you need support, don’t pay Maintenance. You can still use your Jira instance because you’ve already brought your license. 

However, with Data Center, you pay the full price every year to continue using your Jira instance. It’s a subscription, so if you don’t pay it, you don’t get to use Jira. This pricing model brings in a lot more money to the company. It might be cynical of me, but when in doubt, follow the money. Atlassian has a lot more incentive to keep Data Center alive than Server, so it will likely be around as their “On-Prem” offering. 

Here’s to a better week coming up.

This week has been a long one. I don’t know what the future may hold for the Atlassian Ecosystem or this Blog, but I know that we are adaptable, so we’ll do what’s needed to move ahead. So, I’m not going anywhere, and I’ll do my best to guide you through what’s coming up.  

However, you can help now me out. If you are financially able and find this Blog helpful, consider becoming a Patreon and supporting what I do here. Depending on your monthly contribution, you can get access to a Members-only discord, exclusive content that I will not be posting publically, as well as recognition on the Blog. Higher tiers can even participate in a Monthly AMA Conference Call or even a private one on one (virtual) meeting with me. Patreon is very much an experiment, but if you find it useful, please consider supporting the Blog.

What are your thoughts? Are you angry, worried, or looking forward to the changes? Is your organization planning to migrate to another platform? If so, which one? Leave a comment on Social Media with your thoughts and help the algorithms distribute the Blog. You can find me on FacebookTwitter, and LinkedIn, where you can find new posts, community news, and interesting tidbits. You can also put your email down below to get new posts delivered directly to your inbox. But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”

So it’s time for a JIRA Server Upgrade

So, I was recently contacted by a good friend. He isn’t a JIRA Admin, at least by trade, but he’d kind of found himself in the role anyways. He’s facing an upcoming upgrade, and wanted to know if I wanted a side gig helping out.

Unfortunately, as I’m a consultant in my day job, there was some concerns about me doing the same thing on the side, so I had to decline. However, that doesn’t mean I can’t help out.

A JIRA upgrade is no trivial manner, but they happen everyday somewhere. If you know what you are doing, you can even automate it – to a point. I obviously don’t recommend automating a production upgrade, but for testing it wouldn’t be a terrible idea.

For this I’m going to use my JIRA Test instance. It’s running on CentOS and MySQL 5.7, and is currently running JIRA 8.4.3. For this I’ll be targeting the latest Enterprise release 8.5.3. Your system may vary a bit, but so long as you are on linux it should still be the similar enough that you can follow the post.

And yes, I am aware of you windows folks out there. I do owe you an install and upgrade guide too. But I only have one windows server license – and well…it’s in use. So that will have to wait for another day.

Data Center?

So, this guide here today is for JIRA Server. There are a few extra steps in a Data Center Upgrade, but the benefit to Data Center is you can upgrade without downtime, as you upgrade each node one at a time. So, I’ll cover a Data Center upgrade next week.

When you need an expert

So, my day-job is as an Atlassian Partner and Consultant. So – it’s my job to help people with their JIRA problems. And sometimes that includes helping people plan and execute their JIRA upgrades. So trust me, sometimes experts are needed.

So, when do you need an expert? Well…that depends. How confident are you in doing this yourself? Do you foresee problems you don’t know how to fix? What’s your support plan?

I’ve learned a lot by doing upgrades myself and getting help when I ran into a problem I couldn’t fix. But I had the benefit of working with Atlassian Premiere Support, and every time I came across a problem I’d work closely with them to learn what went wrong, what it’s supposed to do, and how to fix it.

That being said, I’ve been known to live off of adrenaline, and some people’s tolerance for this sort of thing is…less. Ultimately, there are no hard rules I can give you for when you need help. It comes down to your unique situation. But if you feel you do need help, don’t be afraid to reach out to an Altassian Partner. That’s what we are here for.

Planning it out

So, you want to go forward with the upgrade. What’s next? What are the questions you want to answer?

Well, the first question is “When should you upgrade?” This depends on your teams, but I find a good rule of thumb is to try to get an upgrade in every six months. This not always going to happen, but you shouldn’t let it go more than a year out. Updates to JIRA Server not only include new functionality, but a multitude of bug and security fixes as well.

However, you don’t always get your way. When I was working with Development teams, I’d always avoid an upgrade leading up to and immediately after a release. This is a time your teams depend on JIRA most, and having it down just isn’t an option, even for an hour.

Next question you have to answer is “What Version am I upgrading too?” To determine this, I’ll spend an hour or two with the JIRA Release notes. Not only will I go over each feature release, taking notes on which new features are available, but I’ll also look at each feature release’s upgrade notes for gotcha’s and changes. As I’ve stated in previous post, I give a heavy preference to an Enterprise Release.

After this, you should ask yourself “Will I need to upgrade anything else?” It doesn’t happen often, but sometimes Atlassian will deprecate support for a particular Database or JRE Version. So you should check the Supported Platforms Section to see if your systems are still good. Assuming you are, you can move on to testing. If not, take the time to get your supporting systems up to a supported version, then proceed.

And the last question you should be asking is “How will this affect my Addons/Apps?” Not every app is compatible with every version of JIRA. In order to account for changes in the JAVA API between different versions, a particular version of an app will only be compatible with a particular set of versions of JIRA.

Thankfully JIRA manages all this for you. You can even get a report of what apps will be compatible with the version of JIRA you are going to. Go to Manage Apps -> Manage Apps -> JIRA Upgrade Check

Here, you can select another release of JIRA, and it will give you a list of what apps are good to go as is, what apps will be good to go if updated, and what apps are not available for that version of JIRA. This will give you a heads up on what changes you need to make to be ready.

Now an App upgrade should be treated with the same respect as a JIRA Upgrade – even though it is far easier. App upgrades can change features your teams depend on, so always do them first in test and have your teams review that functionality to make sure it works as expected.

Test Test Test

So you have all the questions answered, what’s next? Well, Testing! Wait, is this déjà vu ?

Yep, I actually did cover how to go about testing last week. You should go back and read that. 😉

I’ll take a backup of my test instance, and upgrade it, then figure out what breaks. Then I’ll figure out how to fix that, document the fix, reset the instance, and test the full upgrade – including fix – again. I’ll rinse and repeat until I have a fully documented upgrade with no bugs.

This is always a bit of work, but I’d much rather break it in testing than in production. The last thing you want is to come into work the Monday after the upgrade to find a line at your desk. Trust me on that one.

Once you are happy with your test system upgrade, now comes the wait. You should give a week or two for end users to test the new version of JIRA before you put it into production. Not every user will test things out, but those that care the most will. So give them a chance to find what you might have missed.

Doing an Upgrade on System

So, this is the main event. Whether you are doing it as a test, or in production, the process should be the same. That being said, I suggest you practice it in test first to get a good feel for doing it yourself.

Now I shouldn’t have to say this after last week’s post, but here it goes. Backup now. Even if it is a test, give yourself an easy way back to a pre-install state. If you must do it manually, backup JIRA’s Home Directory and take a database dump. IF you can, just take a snapshot of the VM. But make sure you can undo this upgrade easily if you need to.

Either way, you will need to get the download first. Go to Atlassian’s JIRA Download Page. Once there, find the “All Versions Link”, then navigate to your chosen version.

Once you click the “Download” link, you will select “Linux 64 Bit” from the dropdown, click the check box to approve the EULA, then download the software. After this, you will need to transfer this file to your server via your favorite method.

Once on your system, you should have a file named “atlassian-jira-software-<version>-x64.bin”. We will make this file able to be run as a program using a chmod command. Be sure you are running the commands that follow as root.

chmod 755 ./atlassian-jira-software-*-x64.bin

Before we start the upgrade, we will need to shutdown JIRA.

systemctl stop jira

And once it’s stopped, we can initiate the upgrade

./atlassian-jira-software-<version>-x64.bin

The first option we face is just making sure we intended to start the installer. Take a second here and confirm the version matches what you are intending to upgrade to, then click “Enter”

After this, it will ask you the operation you intend to undergo. The Installer will detect that JIRA is installed on the system, and set the default option here to 3, which is upgrade. So press “Enter” to proceed.

The next option will ask you to confirm your installation directory. Take a second here and confirm this is correct. If it is, press “Enter” to proceed. If it is not, enter the correct directory, then proceed by pressing “Enter”

The next screen will ask you to backup your home directory. Technically, you should have already done this before you started (right?). Therefore, I often skip this step as it can eat up valuable time and disk space. And I already had a backup. But if you didn’t heed my earlier warning, this is your last chance to back up that information.

Next JIRA will check for modified files. These normally aren’t but two or three, with the most common suspect being <jira_install>/conf/server.xml. Open up a separate terminal window and copy these out of the install directory. Once you have these backed up, hit enter.

Next will give you a final checklist, and one last chance to back out. If you proceed from here, you are committing to changing the install directory, and will need to restore your backup to get back to a pre-test state. So hit “Enter” once to confirm you’ve completed the checklist, then hit “Enter” proudly once more. You are ready.

Here, JIRA will backup the current install directory, then replace it with a new one for the new version. For JIRA 8.5.3, it will not copy over any modifications you make, but we’ll get to that in a bit. Once done, it will ask if you if you want to start JIRA. Say “No”.

And JIRA is Upgraded….mostly. Time to deal with those modified files.

Re-adding modifications

So, you can just drop in the modified files you backed up during the install and have things right, correct?

https://gifimage.net/wp-content/uploads/2017/11/isnt-that-cute-but-its-wrong-gif-1.gif

Atlassian will on occasion make drastic changes to these files – changes that if not present, will cause JIRA not to run well – or at all. One such test I did on an upgrade, where I just copied over the files from a previous install, all I had from JIRA was a blank white page. Took me two days to figure out what I had did wrong.

Seriously, don’t be me. Or at the very least learn from my mistakes.

The easiest way we can tell how much has changed is with linux’s diff tool.

diff <backed up version of file> <current version from install directory>

If all you see are your modifications, then probably not a lot has changed. You should still use this as a road map to remake those modifications to the new files. Even a minor change can have an impact, no sense in risking it. Do this with all the files. Slow and steady keeps you out of trouble, after all.

It may also be worthwhile to store these modified files within a git repo – that way you can track what has changed with each upgrade across time. I’ve done it with various productions systems over the years, and it certainly cannot hurt.

After you’ve done this for all modified files, you are clear to start JIRA:

systemctl start jira

For the first start after a new install, I like to follow the logs to see if anything goes wrong.

tail -f <jira_home>/log/atlassian-jira.log

Assuming all is well, we can now log into JIRA’s UI to do the next step.

A note about modified files in JIRA 8.6 and above

As I noted when I looked at JIRA 8.6, the JIRA installer will start looking at your modified files and where it can, copy over the modifications to the new install. To be honest, I don’t like it.

If you’ve been in this business for any length of time, you too likely have a rather healthy skepticism to anything that happens “Automagically”. Even doing this, I’d be one to copy the modified files out during the install and compare the old ones to the new ones.

That being said, I admittedly haven’t done a JIRA 8.6 install yet, and their docs didn’t provide much detail on how the process works, so it could be fine. Just a warning to you in the future that an ounce of caution here might be worth a pound of cure later.

Updating Plugins

When you first get onto JIRA, it will warn you again about those modified files. Ignore the warnings to continue onto JIRA. From here, log in, then go to the Admin Console -> Manage Apps.

Come on Rodney – that isn’t good…

Given how App compatibility works, it’s likely you will have a few to upgrade. Take this time and upgrade these as well. Just click “Update” next to each one.

Be aware when you upgrade the “Atlassian Universal Plugin Manager”, you will need to refresh this page to proceed. That alone usually makes that plugin my first target.

Also be aware that any plugin update will require you to do a re-index. You don’t need to do a re-index for each update, but be sure you do one after you finish.

Wait…that’s not right…OH SHI

Now this guide assumes everything went well. As I’ve stated, everything doesn’t always go well. Hopefully this is in test and you have time to work it out. Even if it’s not, just take a second, and breathe, and relax. This isn’t ideal, but you got this.

IF this is in test, collect any logs files or support packets you can to your local system, then reset your instance back to before you started the upgrade. Try it again to confirm you did everything as you expected to. IF the problem reoccurs, you now have a pattern, and two data points.

Then open a ticket with Atlassian Support, and include everything you have, including a detailed account of the system you are running on, the version you were on, the version you are upgrading too, and all the files you got from the system.

If this is production, get what files you can, and execute your back out plan now. Restore the system to before the upgrade using the backups you have taken (don’t forget to also restore the Database) and bring it back up on the previous version of JIRA. There is no shame of backing out of a bad upgrade. There is shame on keeping your teams without JIRA “while you figure it out.”

Take those artifacts and open a ticket with Atlassian. Because this was production, and an issue that (presumably) didn’t pop up in Testing, it can often get a higher Business Impact than a test system problem.

And that’s it?

Yes, really, that’s it! You have JIRA Server running on a new version! Whether this is test or production, the above instructions should be sufficient to get you across the finish line.

At this point in my career, I’ve honestly lost track of how many Upgrades I’ve done. Using the method outlined above, I can usually complete an upgrade cycle – from kickoff to production upgrade complete, in about three weeks. Most of this time is to give end users a chance to test new features before they hit production.

So…humble brag. January is now the best month the blog has had to date, both in page views and visitors.

I cannot thank you all enough for coming by each week to see what I’m writing about. January has been an interesting month for me, with a lot going on. But being able to sit down at some point each week and share with you something about this tool has been both affirming and stabilizing. So thank you. Now lets see if we can make February even better!

Don’t forget that if you need help, we have a discord community. Stop by, ask questions, and chat with fellow Atlassian Admins: https://discord.gg/mXuRsVu

And until next time, this is Rodney, asking “Have you updated your JIRA Issues today?”