Handover Planning for 'Systems Only One Person Can Touch': Keeping Operations Running When Staff Resign

A "system only one person can touch" refers to a situation where a single individual—an in-house IT staff member, a former employee, or an outside acquaintance engineer—is the only one who understands how a system works, leaving no one else able to maintain or modify it. Many small and medium-sized businesses lack a dedicated IT department, so everything from self-made Excel macros and custom business systems to communication with outside contractors often ends up dependent on one person. This article organizes the risks that surface when that person resigns, the different actions to take before and after their departure, a concrete checklist of assets to hand over, and a neutral comparison of future operating options — keeping an in-house team, outsourcing maintenance, or rebuilding the system.

Dependence on one person is rarely intentional; it tends to emerge as a byproduct. In the early stages, development is often done quickly by a small team, and documentation gets pushed aside. When the same person keeps running operations for years without ever being replaced, tacit knowledge accumulates that exists only in that person's head. In some cases, companies also rely on outside freelancers or sole proprietors for development, only to lose touch with them later. Companies struggling with labor shortages often lack the capacity to bring in additional maintenance staff, which tends to entrench dependence on a single person. Labor shortages and dependence on individuals are closely linked issues, also discussed in SMB Labor Shortages and System Operations.

Dependence on a single person rarely causes visible problems during normal operations. The risk becomes apparent the moment that person can no longer act — due to resignation, leave of absence, or illness. If administrator credentials for servers or domains are tied to a personal email address and cannot be transferred, if the source code's location is unknown, or if procedures exist only as unwritten knowledge passed down verbally, even a minor fix can become impossible for anyone to handle after that person leaves.

- Loss of access: Administrator accounts, domains, and server credentials are tied to an individual and become inaccessible after they leave
- Halted development: Without source code or design documents on hand, bugs and requested changes cannot be addressed
- Halted decision-making: Without knowing the reasoning behind a given specification, no one can judge whether a change is safe to make
- Hidden cost increases: When a new staff member or outside vendor takes over with little handover material, simply understanding the current state can require unexpectedly large amounts of work

From a business continuity standpoint, this kind of dependence on one person is easiest to address as part of an IT business continuity plan (BCP). The basic approach is summarized in An Introduction to IT-BCP for SMBs.

What can be done before a resignation differs greatly from what is possible afterward. Before departure, information can be gathered directly from the person involved, so it tends to be more accurate. After departure, without that person's cooperation, the work becomes a matter of piecing together the situation from whatever records and access permissions remain — which takes more time and costs more.

The earlier a company begins this work, the more it can limit cost and uncertainty. It is best to set aside a dedicated handover period as soon as a resignation is announced, or as soon as an extended leave of absence becomes likely.

Once the handover is complete, how a company structures ongoing operations depends on its own circumstances. The main options generally fall into three categories: hiring a new staff member to keep operations in-house, outsourcing maintenance to an external vendor, or — if the system has aged significantly — rebuilding it. Each has its own strengths, and there is no single correct answer for every company.

When considering outsourced maintenance, it is worth checking whether the existing system can be handed over as-is and whether a vendor other than the original developer can support it. For points to consider when switching vendors, see Considerations When Switching Development Vendors; for a broader look at maintenance and operations, see The Complete Guide to System Maintenance and Operations.

- Source code: Where the repository is stored, whether it reflects the latest version, whether version control is in use
- Server and infrastructure information: Hosting provider, domain administrator account, how SSL certificates are renewed
- Passwords and credentials: Administrator account IDs, two-factor authentication settings, whether a password manager is shared
- Procedures and design documents: Operations manuals, incident response flows, system architecture diagrams
- Outside contractor contacts: Contact information and contract details for the vendor or sole proprietor who handled development
- Cost and contract information: Server costs, license fees, maintenance contract renewal dates

A "system only one person can touch" may seem convenient in ordinary times, but a single event — that person's resignation — can cause the risk to surface all at once. What matters is beginning the asset inventory as early as possible once signs of a resignation appear, and weighing the costs and risks of the three future options: keeping operations in-house, outsourcing, or rebuilding. For ongoing preparedness, see also The Complete Guide to System Maintenance and Operations.