Modern problems require modern solutions. A problem might come up that your software isn’t equipped to handle. This is why enterprises around the globe are spending billions of dollars more today than they did a decade ago.
It’s never a good idea to leave anything to chance, especially if we’re talking about essential software. Keeping critical infrastructure software up to date means it’s more stable and more secure with the latest bug fixes. Of course, this has to be done without affecting your customers.
However, this may be easier said than done, especially if you have several years of backlogged software updates. The whole upgrade process has to be carefully planned and monitored. Some best practices have to be kept in mind.
Plan Your Actions
Achieving a zero-impact upgrade to critical software requires the utmost attention to detail. You need to know exactly where you are and where you’re going. You also need to make sure that you understand every step you’re taking to achieve your goal.
- Catalog Your Current State: The first step to planning is to know the state of your software. You have to know where you are, in order to get to where you want to go.
Check which version of the software you’re running and how old it is compared to the latest version. Your outdated software might prevent you from submitting bug reports if it’s no longer a maintained version.
- Read the Changelog and Ask Questions: This next step is as time-consuming as it is important. You’re probably aware that most open software has a changelog that’s available for public consumption. You’ll have to read it all. The changelog is a treasure trove of information and may even point back to specific pieces of code that implement the change.
It will be time-consuming, and several breaks will be in order to ensure productivity. You may find that you don’t need most of the features and bug fixes you’re reading about, but now you know that much more about the software you’re managing in your infrastructure.
Remember to take down notes and questions or comments you may have while you’re reading through it all. You may be surprised to find a minor feature you never knew existed that may be very helpful in your current situation. Or you may find a fix for that one minor, but unfixable, bug that your team had to frustratingly find a workaround.
Write it all down in your notes. That way you have your own little changelog that you can further trim into only the most crucial things. You can then decide if the minor things belong to the same scope or should be added to the backlog for later.
- Test Out Your Theories and Think of Edge Cases: Having a plan is well and good but you’ll have to try it out eventually. But, if it’s execution is done directly in an important environment, you’re doing it wrong.
Similar to a software development life cycle, software upgrades need to be tested prior to actual execution. While brainstorming edge-case scenarios, take into account what might be different and cause problems in the other environments.
Document Everything
This one goes without saying, but remember to document everything. Reading and documenting everything may sound like a lot of work, but when you need to pick up that work after a long weekend, you’ll be happy that you did.
Document each and every single step, any caveats or issues you encountered, in a way that you can still understand later. This will help your team perform the upgrades and it also provides documentation to other readers who are interested in how the upgrade process was done.
Execute Your Plan
After you’ve done all that, it’s time to finally execute your plan. By this time, you should have already tested your plan so much that you know it will work without a shadow of a doubt.
Still, it’s common for something unexpected to pop up and you may need to do some live debugging to fix it. Execute your plan with that expectation and assurance that your preparation will hold up to any situation.
As always, remember to document everything as you may want to refer back to your documentation for the next upgrade or while debugging something later.
Conclusion
Upgrading critical infrastructure software can be difficult if you don’t have a good plan. Check your current state, read the changelog, pay attention to every detail, write down notes, ask questions, test your plan, test it again and document everything. At the end of the day, you’ll be glad that you put in all that upfront work.
