Table of Contents
TL;DR
During a disaster-recovery investigation, we found a critical server sitting under a user’s desk in accounting, running decade-old homegrown software, absent from the DR plan and the transformation plan alike. Someone in IT had put it there years earlier because there was no place for it. The user only knew “one of your guys stuck it here.” The lesson every transformation needs: survey your systems first, because you cannot transform what you do not know you own.
Disaster recovery was one of my responsibilities at the major national retailer, and we had some disasters, which is how the truth about inventories gets discovered. During one recovery effort, we were hunting for a machine. It existed, systems were talking to it, work depended on it, and we could not 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, had no place in the server room, and 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 was not in the disaster recovery plan, so the recovery I was responsible for would have silently omitted a system the business depended on. It was not 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 did not contain it. It was not 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 is 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 do not age like known systems, on a maintenance schedule. They age like the contents of a wall you sealed up years ago.
How a system escapes the inventory
The desk server’s biography is worth reconstructing, because it is 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, which is why policy alone never prevents it, there is no decision point at which anyone chose wrongly enough to stop. The only reliable counter is the one that requires no memory and assigns no blame: periodic discovery that enumerates what is actually on the network and confronts 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
Survey before you transform
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 is not a plan for your company. It is 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 does not. 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 were not 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 are an executive writing about transformation, put your desk server in the book. Every practitioner reading it has found one, and nothing buys credibility with that audience faster than admitting where yours was.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.