As someone who's taken over any amount of legacy junk, I now operate on this basis:
- If it's junk, I'll tell you so, and expect you to replace it.
- If you don't replace it, I have little interest.
I've always left behind documentation, experienced staff, etc. whenever I've had to put in a bodge, but nobody seems to care very much.
Every time I take over a place, nothing useful is documented (and documented the weird and wonderful, including the rationale for that, is far more important than telling me the exact spec of your server, or how you organise your IP subnets). In the last place I took over there was an entire community FM radio station hiding in a cupboard that nobody really knew anything about.
So when I take over, as I touch things, I document them. I force staff to document stuff they know, especially if it's a "Oh, look, I'm the only one who remembers how this works, let me just fix it quickly for you" kind of arrangement.
If it's not documented, it's not something I deal with. Not until it's been documented. Force me to take it over and job #1 is documenting it... for me and future replacements. And in that process, if you're documenting and thinking "WHWHWHWHHYYYY?!?!?" then you should be telling them they need to change it, and moving down that path, and accepting no responsibility for it failing in between that moment and the moment of replacement.
And, yes, it's the weird stuff like this that absolutely NEEDS documenting. And why it exists. That backstory is important. Why didn't you just go the simple way? I need to know. There might be a very good reason for that.
If you're not leaving behind a Wiki / Sharepoint / Whatever full of consistent documentation, with rationale, then you've failed in your job managing that system. If the next guy has to pick up the pieces and either doesn't know it's there, only discovers it later (or when it goes wrong) and has no idea why it's doing that, you've failed in your documentation AND handover.
It really doesn't take that long to spin up a Wiki and start bashing out a page for each piece of software, a page for each server/VM, a page for each system and its dependencies, a page for renewals and expiries, a page for suppliers, licensing, etc. and you can literally do it as you go. Every time you have to do something, think "Is that documented?" and if it's not make a blank page with a TODO message on it (I use MedaWiki and a category for "Incomplete Pages"). Then when it's quiet or you have even a couple of minutes, grab a random unfinished page and add to it. You don't need to complete it, just add to it. Every time you do that weird thing you have to do every year but always forget how to do... write a page on it.
And at a pace of 1 small page a day, you have over 300 pages of documentation done in a year just as one guy. 300 systems, servers, quirks, softwares, etc. It's really not hard. With a team, you can blat out thousands of pages.
And then it all pays back that one day you have to handover, train a new member of staff, or disaster strikes. "Now... how did we build that cluster, I remember we had to do something with the registry to make the RAID controller work, what was it again..." "Oh look, there it is. All written down by someone like me who accounted for all the pitfalls in the process, and knows exactly what I need to know and what order to do things in, and why we DON'T do that step first even though it appears logical to me."
Past me is a really nice guy who helps me out a lot, and is psychic - he always knows what I'll be asking when something goes wrong, and telling me to ignore THAT menu even though it looks tempting because the option I actually want is OVER THERE instead with a similarly-named option. He's a smart guy.
Past-predecessors are almost universally a bunch of inconsiderate twats.