Once or twice a year, existing Athena workstations need to update to a new release. This includes changes to Athena software, but may also include an update to a new release of the vendor OS.
The update process is completely automated for workstations in general-use clusters and non-customized private Athena workstations. The workstation waits until nobody is logged in, runs a script called update_ws to check conditions for a successful update, kills off certain daemons, and then runs a do_update script which performs the actual update.
For private workstations, the automatically-run update_ws merely prints out a message saying a new release is available. Private workstation maintainers have to run the update_ws script from a shell prompt to get the actual update to happen.
The actual update involves moving certain old files aside (not removing ones that might be customized), then dumping lots of new files in place. Private workstations customized with the mkserv program have such customizations restored at the end of the update.
No manual intervention is needed for the clusters, so the cluster group is generally not a customer of this process, so long as it actually works and no manual intervention is required.
The only significant use of servers is against AFS fileservers, so the server ops group is not a heavy customer of this process.
The real cost in this process is in the devlopment group. Updates to new underlying vendor OS's have to be done with special care. Some developers have ideas for improving the update process, but overall the work involved in engineering an update is significantly less than the work involved in engineering an install.