I asked around, "what's a patch compared to an upgrade?"
The upgrade is generally considered more invasive, larger and comes at a higher risk. It may or may not have a big reward. The reason for the upgrade may be external, internal, and feature-centric or security related. Operationally, an upgrade requires greater amount of testing, planning and more complete change control planning procedures.
Patching is viewed as a smaller change. Only one or a few very specific variables are altered. The risk is generally considered low, but with a high reward, as the problem at hand will be quickly fixed. Patches are generally installed with less testing and often are implemented during a normal change window.
Don't both a patch and an upgrade represent the same operational risk?
The perception is seemingly clear. Call something a patch and it will get rolled out quicker than an upgrade. Case in point here at nCircle. Our internal Information Technology Patch Tuesday SLA is 8 hours. The IT team has agreed to test and ready for deployment "patches" within 8 hours of their release. In general, the acceptance and installation of said patches throughout the organization is less than 24 hours later. The net is that within 24 hours of patch Tuesday, we have nearly 100% of all end points patched. Now compare Patch Tuesday with the end of life for FreeBSD 4.11. FreeBSD 4.11 was our IT sanctioned Unix server common operating environment. Version 4.11 went end of life on January 31st 2007. Even with more than 6 months of notices and hands-on help, we still have business units who haven't been able to fully migrate.
Sure the "upgrade" from 4.11 to 6.x is much more complicated and complex than a "patch", but there is more at hand. There is a hesitancy and procrastination. For most, the upgrade of FreeBSD is perceived at painful and with little reward. Meanwhile, installing a few Microsoft patches is easy and comes with a big security reward.
Change == Risk
One would think that any change at all represents risk. Patch or upgrade, both introduce change. It's not our job to be risk adverse, but to be risk managers. Are we doing our users a disservice by calling anything a patch? What if we called it "Change Tuesday", I guess that's better than "Time to introduce risk to your computer in hopes of being able to better manage risk at some unknown point in the future so I don't loose my job".
