Most IT arrangements in small businesses start with a relationship.
A contractor who handled the setup years ago and kept handling things as they came up. A former employee with the technical background who became the informal point of contact. A service provider who was there from the beginning and never stopped being useful.
The relationship works. Things get handled. Problems get solved. For years, maybe for decades, this is just how IT runs at the company.
And then the person’s situation changes.
It is rarely dramatic. They move on to something new. Their schedule fills with other commitments. They are still technically reachable, but response times stretch from hours to days. They are no longer really managing anything, just responding when something breaks. And then eventually they are not really reachable at all.
What Lives in One Person’s Head
The problem is not the person leaving. The problem is what they took with them.
In a properly documented IT environment, a transition is an inconvenience. Credentials are stored in a secure system. Processes are written down. The environment is mapped. A new provider can get up to speed in a few days because the information exists outside any individual memory.
In an informally managed environment, a transition is a reconstruction project. The credentials are wherever the contractor put them, if they were documented at all. The configurations are understood by the person who set them up and nobody else. The backup is working, or at least it was the last time anyone checked, which was a while ago.
When the person who knows all of this becomes unavailable, you are not starting from where you left off. You are starting from zero, without history, without documentation, and often with real deadlines already attached to the problem.
The Single Point of Failure
In systems design, a single point of failure is any component whose absence causes the entire system to stop functioning.
For businesses running informal IT, the person who knows everything is that component. It does not matter how reliable they have been. The moment their availability changes, the system fails, not because they did anything wrong, but because the system was never designed to function without them.
A business continuity approach that depends on one specific person staying available is a bet, not a plan. Most of the time the bet pays off. The contractor is reachable. Things continue to run.
The question worth asking is what happens when the arrangement stops working and whether the answer to that question is something you can accept.
What Documentation Actually Means
Documentation is one of those words that sounds like overhead until you need it.
A properly maintained IT documentation system is a set of records that answer the questions every new IT person needs when taking over an environment: what are the credentials for the core systems, where does the backup run and when was it last verified, what devices are under management, what vendors does the company work with, what does the onboarding process look like for a new team member. Building it is a straightforward effort, and the value starts the moment the first credential gets recorded somewhere the company actually controls.
When that information exists, a transition is a handoff. When it does not, it is a reconstruction project paid for at emergency rates during the worst possible moment.
The documentation does not need to be perfect. It needs to exist outside the head of one person. That is the entire requirement. Completeness and organization improve over time, but the value begins the moment the first credential gets recorded somewhere the company actually controls.
The True Cost of ‘He Knows Where Everything Is’
Here is what the informal arrangement actually costs when things go wrong.
The transition period during which the environment is partly managed and partly unknown typically runs four to eight weeks. During that time, a newly onboarded IT partner is discovering the environment rather than managing it. Every credential that has to be reset, every system that has to be re-enrolled, every configuration rebuilt from scratch is labor that would not have been necessary if the documentation had existed.
That discovery phase also tends to arrive at the worst possible moment. A new hire starting. A critical project deadline. A team member departing. The IT gap does not arrive in isolation.
The total cost includes the emergency IT work, the leadership time diverted to the situation, the delayed onboarding, the risk exposure during the gap, and the operational stress of running the business on incomplete information. That cost compounds every day the gap exists.
Building a System That Outlasts Any Individual
The goal is not to find a contractor who will never leave. The goal is to build an environment that does not need them to stay.
That means credential management that puts access in the company’s hands, not in a personal account on a personal device. It means processes written down and followed the same way each time. It means devices enrolled under company accounts the company controls, not personal accounts that walk out the door when the person does.
None of this is exotic. All of it is straightforward to build once someone makes it their job to build it.
The only thing preventing most small businesses from having it is that the informal arrangement kept working long enough that nobody got around to building the real one. The businesses that make this transition intentionally do it because someone looked at the situation and asked: what happens when the one person who knows everything is no longer available?
If the answer is ‘we have a problem,’ the time to address it is before the problem arrives.