Upgrading to the Latest Code Might Not Be a Good Idea

You pride yourself on keeping your servers in tip top form. Security is priority number one or maybe second only to functionality, and it is your job to sit in the middle making choices about when to update your servers.

However, just because an update exists, do we need to install it? Better yet, do you have a way to test the updates before going live? Sounds obvious, but as an advisor to many customers, this basic tenant is waved off, especially in the social products like IBM Connections and IBM Sametime.

I know this firsthand because I have experienced it at a few customers over the last year or two and could easily have been avoided. If you already understand all of this, then go on and read a different post, but if you are a newbie or someone who wants to understand this problem further, please read on.

Unlike the big eCommerce sites where downtime could be a potential loss of millions, internal applications get short changed.
“We do backups”, “We have VMs”, “it’s just <insert whatever application name>”.

I ask, so you feel confident the update will work and all will be good, right? IT says sure, executives say sure, I just pray that they are right. After 20 years of working with IT infrastructures, you know that updates are not always working as promised. People talk about bricking their phone, well when you brick your server, I guarantee, heads.will.roll.

We know how bad it can get when it all goes bad. Vendors are not perfect and their QA teams do not live inside your architecture and cannot test for every possibility. If you are sitting on a production only system with no development or staging platforms, I ask, have you checked your backups lately? When the patch goes bad is really not the time to find out the restore process is broken. This is also a good time to discuss change management procedures and guidelines. I have worked with companies that have a change management application workflow, then calls and meetings before getting approval, for 2 months down the road. I have also worked with some that have a simple spreadsheet or document to complete and that works well too. You need a plan, without a plan, you have nothing but hope and prayer and my experience is IT people tend to be less interested in a supreme deity, but greatly respect Mister Murphy and his law, so you better know what you are doing.

When you go to update these products and something goes bad, you may be looking at a long recovery time. Reading the details and verifying what patch levels are allowed will save you tons of time in troubleshooting, also keeps your one platform alive longer. As I train sales people to say this, it seems appropriate here as well, if you don’t know enough to find the information on your own, then ask someone who does, or even call IBM. If you need a good place to start, use this IBM Site.

The application sitting on WebSphere probably has some updates too, and with those updates come new information about which fix packs to load and what version to use for the various options. This is one time to definitely read the readme file. The ICS(Lotus) products tend to be very explicit about version levels and patches, more so than some other applications.

As an IBM Champion for ICS, and previously one for WebSphere, I know firsthand how the rest of the world looks at the ICS applications and hopefully this will keep you from falling into a PMR quagmire or requiring me or other Business Partners getting involved in a cleanup situation.

1 Like
Recent Stories
IBM Open Sources WebSphere Liberty Code to Support Java Microservices and Cloud-Native Apps

Development Simplified: Leverage a Single Database for Structured and Unstructured Data

Physical v Logical Backup with Oracle