Imagine this: it is Monday morning, people cannot connect to a business-critical application, and the first suggestion is to call the person who set it up.
Someone says, “Ask Fisnik. He set this up.”
Fisnik is on holiday and he is not the problem. The problem is that the company has no reliable way to act without him.
The team knows the application is running on a server somewhere. There is a monitoring dashboard and a folder of documentation. But the details that matter right now, what changed last week, which other systems the application needs, and who can approve a fix, are scattered across old tickets and conversations.
Most companies have someone like Fisnik. It may be an internal engineer who has been there for years, or a specialist at an external provider. They are the person everyone trusts when a difficult issue appears. That is valuable expertise. It also creates a problem if the business can only function when that person is available.
A healthy dashboard does not tell the whole story
On an ordinary day, this dependence is easy to miss: backups finish, alerts get cleared, the applications people need are available, there is little reason to ask how someone else would handle a failure.
Then a certificate expires, a migration uncovers an undocumented connection, or an administrator leaves. The response team loses time looking for answers that used to be a phone call away.
The questions are usually practical:
Who owns the service?
Which database, identity service or network rule does it rely on?
Where is the current configuration?
Who can access the recovery tools?
And after a fix, how will anyone know that the people using the application can work again?
You do not need an elaborate risk model to see the issue. If those answers live with one person, their absence changes how quickly the team can respond.
Find out before the next incident
Pick one service that would cause real disruption if it stopped for a day. Ask the people who would respond to an outage to talk through what they would do if its usual expert could not be reached.
Start with the first few minutes: who notices the problem, who investigates it, and who is allowed to make a change? Then follow the service through its dependencies. If the application itself is healthy but nobody can sign in, where would the team look next?
Finally, ask them to find the instructions and access they would need. Do they know how to contact the right vendor? Can they locate a recent diagram, an approved recovery procedure and the information needed to restore the service? What would they test before telling the business the incident is over?
This can begin as a conversation around a table. There is no need to interrupt production to discover that a diagram is out of date or that no one knows who holds an administrative account. For the most critical services, the next step is a controlled technical exercise that checks whether the documented recovery path works.
Write down what the next person actually needs
Documentation often starts as a list of servers and IP addresses. Useful, but it does not explain how to keep a service running.
For a critical application, the next engineer needs a clear picture of what it does, who owns it, what it depends on, how changes are approved, where to find access, and what to check when something fails. Include the reasons behind unusual configurations. A rule that looks unnecessary in a diagram may be the reason an older integration still works.
Keep credentials in the appropriate secure system, with a documented way for authorised responders to obtain access. And let someone other than the original expert follow the instructions. Their questions will show what is missing far more quickly than another review of the document by its author.
Start small enough to finish
Trying to document the entire estate at once is likely to stall. Start with the few services whose failure would interrupt customers, employees or core operations. Give each one a named owner and a second person who can respond. Check the dependencies and access, walk through a realistic incident, and give someone responsibility for closing the gaps.
Repeat the exercise when a major change is made. A handover that was accurate before a migration may no longer describe the environment that is actually running.
The aim is to give the team enough shared knowledge and clear ownership to act when the usual expert is unavailable.
If this exercise raises more questions than answers, Hopp Solutions can help review the environment, map responsibilities and dependencies, and establish practical documentation and operating routines alongside your internal team.
