I didn’t really understand what a good infrastructure handoff looked like until I had to work without one.
About a year and a half apart, I ended up on both sides of the same transition, in two different countries. In one direction, I was the one leaving — handing my systems to someone else. In the other, I was the one walking in cold.
What I Walked Into
Late last year, I joined a new environment and inherited a stack that spanned VMware, NetBackup, Zabbix, CyberArk, Rapid7, Trellix, SentinelOne, Solid Step, Hitachi storage, and Dell hardware — across multiple client environments at once.
Servers existed that nobody could explain the purpose of anymore. I’d find one, ask around, and get nothing — the person who might have known was long gone, and there was no ticket, no change log, no note anywhere that said why it was built or whether it still mattered. Accounts had full administrative permissions with no record of who granted them, when, or for what reason. I couldn’t tell which of those I was safe to touch and which I wasn’t, so for a long stretch the answer was: touch nothing, until I could prove it was safe to.
Contact points were the same story. There was no list of who to call for which vendor, which system, which client. Every one of those had to be tracked down from scratch, one system at a time.
It took me roughly four months to reconstruct context that should have taken an afternoon to hand over.
What I Left Behind
About a year and a half before that, I was on the other side of the same kind of transition — leaving a role in Germany after more than a decade there.
Before I left, I took the folders I’d been maintaining and broke them down further — by system, by client, by purpose — and wrote an overview document explaining what lived in each one and why. Cisco networking, the Synology NAS setup, IT procurement contacts, all of it mapped out so the next person wouldn’t have to guess.
At the time, it didn’t feel like anything special. I thought that was just what a normal handoff looked like.
Then I became the person receiving one.
The Difference Was the Why
Comparing both experiences, the gap was never really about how much documentation existed. It was about whether it explained why, not just what.
A permissions export will tell you who has access. It won’t tell you whether that access should still exist, or who to ask if you’re not sure. That gap — between what’s written down and what’s actually understood — is where an infrastructure handoff either holds up or falls apart six months later.
What I Do Differently Now
- When I create a server or grant standing access, I leave a short note about why it exists. It doesn’t need to be a document — I just don’t want the next person reconstructing the reason from scratch, the way I had to.
- I keep vendor and system contacts in one place and update it as things change. Five half-current lists are worse than one simple one.
- When I make a change, I write down why while I still remember it. Six months later, even I might not.
Bottom Line
A handoff isn’t really about transferring systems. It’s about transferring the reasoning behind them. I’ve now seen what it costs to receive one without that, and what it takes to give one that actually holds up. I know which side I’d rather be on.
Related reading:
- I Thought VMware Snapshots Were My Recovery Plan
- My Zabbix Proxy Was Down
- The Day Our Backup Server Went Down
Frequently Asked Questions
What’s the single biggest thing to document during a handoff?
Not the current state — the reasoning behind it. A list of servers and permissions is easy to export. Why each one exists, and whether it’s still needed, is the part that disappears the moment the person who knew it leaves.
How do you handle a handoff when there’s no time to prepare one properly?
Even a short, honest note — “I don’t know why X exists, but I never touched it” — is more useful than silence. Flagging the unknowns explicitly saves the next person from mistaking an orphaned server for a critical one.