[stevear]

When you do a server side upgrade you are essentially doing an upgrade on behalf of every person who uses your product and it's sometimes difficult to roll-back. This is a really good reason to treat server side upgrades differently.

Once you are bit by a bad update you will be very shy about doing it again without a good cause. As an example, we updated to Recent Version - 1 of critical server software and had the thing crashing constantly thereafter. So then we upgraded to Recent Version and had a new bug that was introduced that was causing equal troubles. But now we were stuck and had to wait for next version to fix the bug. Made a really good case for not changing what works.

[maccman]

This is just as true for client side upgrades, for example in the App Store. As an app developer you're upgrading every client out there, and it's much harder to revert.

Just as you test on the client side, you should have a staging cycle which tests releases before you deploy them.

[jules]

The advantage you have as a web or app store developer is that if you make a mistake, you can always correct it by shipping a new version. Just imagine the stress that's on the Windows Update or Chrome update teams. If an update to Windows Update itself or to Chrome update itself turns out to be wrong, millions of users could be stuck with a non-upgradeable piece of software and each user would be forced to fix it manually.