Unpopular advice: find a subtle way to make it crash, preferably stealthy, but if not possible, at least in a way that can be attributable to mild innocent incompetence instead of malice! Then there will be more and more interesting work to do for you and others, either rediscovering and properly documenting the config, or, hopefully, architecting and coding its replacement! In the aftermath, the organization will be…
>If it actually collapses bc of this, then it deserved to die anyway, you only helped accelerate the outcome and reduced the suffering
If you want to make an evolutionary "survival of the fittest" type of claim... Life is entirely about error correction (and reproduction + staving off death as long as possible). Engineers babbling to engineers is part of a business's error correction.. Duct tape and monkeypatching is part of the engineer's error correction..
A rogue engineer trying to invoke rapid deconstruction of his environment (a virus) is one of those errors -- Solution: engage, restrain, and eject.
The legitimate error correction is already happening, by means of hope & replace. Presumably because other business concerns make it so that actual shutdown would be a Terrible, Horrible, No Good, Very Bad idea.
>If it actually collapses bc of this, then it deserved to die anyway, you only helped accelerate the outcome and reduced the suffering.
A doctor can't help you if you die in minutes. They can save you if you die in hours. Time is a major part of error correction.
Oh damn, you've pushed out the nukes already.
>Some things and processes need to be "helped to fail faster", everyone will benefit from the renewal in the end, even if most will hate it ;)
Seems to me the main process requiring failure acceleration is this one employee's UAC expiration policy.