Dont Fix What Isnt Broken

When a software vendor releases a new version of their product, one’s first instinct is to adopt the new version. Ideally, the upgrade should go through a change management process. Somebody has to look at the release notes for the new version, prepare a list of the changes, the benefits, how it will (negatively) impact the existing deployment, the risks involved, and how the risks will be mitigated.

If the only change between two versions is a trivial label change, then one shouldn’t be fixing what isn’t broken. The risk of introducing a bug would be greater than any benefits from the upgrade. The urge to always run the latest version should be questioned when running a system that requires downtime to be minized.