Disaster recovery was one of my responsibilities at the major national retailer, and we’d some disasters, and that’s how the truth about inventories comes out. During one recovery effort, we were hunting for a machine. It existed, systems were talking to it, work depended on it, and we couldn’t find it. Not in the server room, not in the racks, not anywhere a server was supposed to be.
We found it under a user’s desk in accounting.
The user was no help on how it got there, and why would she be? Her account was simple: one of your guys came over six months ago and stuck it here. Somebody in IT, identity lost to history, had needed a home for a machine. There was no place in the server room. He solved the problem the way tired people solve problems. Wherever it fits. And under that desk sat a critical server, running homegrown software probably ten years out of date, humming along in the dark.
What the desk server actually was
Count the failures stacked on that one machine. It wasn’t in the disaster recovery plan, so the recovery I was responsible for would have silently omitted a system the business depended on. It wasn’t in the transformation plan either: our modernization program, which touched literally everything else, had never touched it, because the plan was built from an inventory and the inventory didn’t contain it. It wasn’t patched, not monitored, not backed up on any schedule anyone could name, and physically accessible to anyone who could reach a desk in accounting.
None of this was anyone’s decision. That’s the uncomfortable part. No one chose to run a critical system on decade-old software under a desk. The situation assembled itself from small expediencies and then persisted because nothing forced anyone to look. Unknown systems don’t age like known systems, on a maintenance schedule. They age like the contents of a wall you sealed up years ago.
How does a system escape the inventory?
The desk server’s biography is worth reconstructing, because it’s the biography of every shadow system. It began legitimately: a real business need, real software written for it, a real machine deployed. It escaped at the moment of placement, when “no room in the server room” met “just put it here for now,” and for now did what it always does. It survived because it worked; systems that fail get found, and this one hummed along for years precisely because it never demanded attention.
And it was orphaned by turnover, when whoever placed it left or forgot, taking the last copy of its existence out the door in their head.
Need, expediency, reliability, turnover. No villain appears anywhere in that sequence, so policy alone never prevents it, there’s no decision point at which anyone chose wrongly enough to stop. The only reliable counter requires no memory and assigns no blame. Periodic discovery, enumerating what’s actually on the network, then confronting the official list with it.
We found a critical server under a desk in accounting, running decade-old software, missing from every plan. Survey before you transform.Share on X
Why survey your systems before a transformation?
The lesson I took, and the one I hand to every executive planning a transformation: really survey your systems. Know where every machine is, what it runs, what depends on it, before you draw the plan. Not the inventory the spreadsheet claims. The inventory the walls and desks actually contain, verified by scanning the network and physically walking the spaces, because our desk server would have appeared on a network scan years earlier if anyone had reconciled scan results against the official list.
A transformation plan built on an incomplete inventory isn’t a plan for your company. It’s a plan for the company the spreadsheet describes, and the gap between those two companies is where the post-transformation surprises live: the critical process that breaks because it depended on a machine nobody migrated, the security incident on a system nobody was patching, the recovery that fails because the plan never knew what it was recovering.
The question that finds desk servers
Every organization above a certain age has at least one of these, and executives are reliably certain theirs doesn’t. The test costs one meeting. Ask your IT leadership: when did we last reconcile a full network discovery scan against our official asset inventory, and how many devices were on the network that weren’t on the list? If the answer is a number, you have a team that hunts desk servers. If the answer is confidence without a number, you have desk servers.
And if you’re an executive writing about transformation, put your desk server in the book. Every practitioner reading it’s found one, and nothing buys credibility with that audience faster than admitting where yours was.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
