One of the pervasive properties of software is change. Whether this change comes from regular enhancements or environmental updates, it is one that should be considered strategically for production software. Thus, the balance of upgrades vs. stability needs to be considered as your solution ages.
Easy Upgrades
Modern software environments provide features that make upgrades easier than in the past. A great example of this is WordPress and other “plugins supported” solutions. The goal is to make administration of these sites easy and quick. Thus, you often can upgrade a plugin or even the core software to the latest version with the click of a button.
This ease extends to core environments as well. There are a lot of automated update tools available to keep all of your software up to date. The most well known of these is the windows update tool provided in many recent Windows OS versions.
Impacts to Stability
This ease of administration is excellent. However, it is also hazardous. An upgrade may break your entire site and lose sales. As scary as that sounds, even worse side effects can happen. Data may get corrupted, backups can become invalid, and fulfillment can be sent to the wrong address. These worst-case scenarios are not exactly typical, but they can happen. Upgrading your system can turn a steady running and reliable system into a nightmare.
These concrete impacts are just one facet of the considerations. Updates may change the user experience. Something as trivial as moving a menu item can cause user headaches and negative backlash. For some great examples of this, look at some of the Facebook changes over the years that caused a massive outcry from their user base.
Managing Upgrades vs. Stability
It may seem that these risks point to leaving your software in its original state as long as possible. Fewer changes should lead to higher stability. This is only partially true. A stable system is more accessible to hack and may be steadily approaching a point of no return. In the latter case, this can be a point where the system lacks the resources to support the user base or amounts of data within the system.
There are also license considerations and support. Older software may not be supported by vendors entirely or at all. Thus, we need to find that balance. Here are some high-level steps that can be taken to keep your solution up to date while minimizing risk.
Scheduled or Periodic Updates
Vendors do not release updates on the same schedule. However, you can set a timetable for when you will apply updates so you can keep those updates on a plan suitable to your business. I recommend updates on a frequency of two to four times a year.
Test, Test, Test
It is recommended that you have multiple environments during implementation. This is even more important once you “go live.” The value of these other environments is that they allow you to create an identical version of your production system for testing. Thus, nearly all of the risk can be assumed by a “test” environment instead of production. This is not a silver bullet, but it is pretty darn close.
Backup, Backup, Backup
Before any update is made, make sure the whole system is backed up. This will allow for roll-back in case an update is not viable.
Avoid Bleeding Edge
When you follow the suggestions above, it should help you buy some time before implementing an update. This should be embraced and used to allow you to pass the risk on to other customers. They can perform the update, and their feedback will help you avoid problems and reduce risk. In effect, waiting on an update allows others to be your guinea pig.
The Bottom Line
These are general suggestions, but embracing them can be very useful. There is always going to be a challenge in finding the balance of upgrades vs. stability, but when you reduce risk, it makes success more likely. Following the steps noted here can provide a win-win situation where you have current software and a stable experience for your customers.
