One person wrote the software, deployed it, held every password, and answered every question about it. Now they are gone: resigned, retired, unreachable, or worse. The system is still running, which makes it tempting to treat this as a hiring problem to solve next month. It is not. It is a continuity problem with a clock on it, and the clock is set by things you do not control: subscription renewals, certificate expiry dates, an expiring card on an account nobody else can see, and a scheduled job that will fail on a date you have not thought about yet.
Work through the first section before you do anything else, including talking to recruiters.
The first 48 hours
Everything here is something you can do as the owner of the accounts, using your own administrative rights or your provider's documented account-recovery process for the legal owner of a business account. If you find something you cannot recover through those channels, note it and escalate it to your counsel and your providers rather than improvising.
- 1
Write down every system you know the software touches: hosting, source control, the database, email or SMS sending, payment processing, the domain registrar, any API the software calls. You will find more later; start with what you know.
- 2
Establish who owns each account. Look for accounts registered to a personal email address rather than a company one. Those are the ones that cause trouble, so start the ownership transfer with the provider today.
- 3
Check the payment method on every account. A card belonging to someone who no longer works there will fail at renewal and take the service with it.
- 4
Locate the source code and take your own copy today. Clone the repository somewhere the company controls, and confirm the copy is complete rather than assuming it is.
- 5
Find the backups, then restore one into a scratch environment and open it. This is the single highest-value hour of the whole exercise.
- 6
Inventory anything that runs on a schedule: nightly imports, invoicing runs, report emails, data syncs. These fail quietly and are usually discovered by a customer.
- 7
Identify where alerts and error notifications currently go. If the answer is the departed person's mailbox, redirect them to somewhere a current employee reads.
- 8
Freeze non-essential change. Until someone understands the system, every well-meant modification is an uncontrolled experiment on a live business.
Risk areas, in the order they bite
The immediate action column is what protects you this week. The longer-term fix column is what stops this being an emergency the next time someone leaves.
| Risk area | Immediate action | Longer-term fix |
|---|---|---|
| Accounts registered personally | List them and begin the provider's ownership-transfer process for each | Every account owned by a company identity, with billing on a company payment method |
| Expiring payment methods | Replace the card on every account you can reach today | One billing owner in finance who receives every renewal notice |
| Domains and certificates | Confirm expiry dates and enable auto-renewal | Registrar lock, company contact details, and a calendar reminder independent of any person |
| Backups | Restore one to a scratch environment and confirm it opens with current data | Scheduled restore tests with a written result, at least quarterly |
| Source code | Clone it to company-controlled storage and verify it is complete | Company-owned repository, with the contract stating the code is yours |
| Deployment ability | Find out whether anyone still at the company can release a change | At least two people who have personally deployed within the last quarter |
| Scheduled jobs | Inventory what runs, when, and what it touches | Monitoring that alerts a team address when a job does not complete |
| Undocumented rules | Interview the daily users while the details are fresh | A living operations document maintained as part of normal work |
Why the lull is the dangerous part
Software does not notice that its author left. A well-behaved system will run for weeks or months without intervention, and that stability is read as evidence that the situation is under control. It is not. It is the absence of any event that requires a human, and events arrive on their own timetable.
The usual sequence is that nothing happens for six weeks, then three things happen at once: a certificate expires, a vendor deprecates an API version, and a customer reports that invoices stopped sending on the first of the month. Now you are debugging an unfamiliar system under time pressure, and the person who could have answered a question in ninety seconds took another job in March. The window in which their help is cheap and available is short, and it closes quietly.
What is recoverable and what is genuinely severe
Most of these situations look worse in week one than they turn out to be. It helps to separate the two categories early so you spend your worry accurately.
Usually recoverable
- No documentation. Unpleasant, but the code and the database are documentation of a sort, and the users hold the rest.
- Unfamiliar or unfashionable technology. Someone who knows it can be found; the language is rarely the hard part.
- Messy code. Ugly code that works is a maintenance cost, not an emergency.
- No formal deployment process. Reconstructing how a release reaches production is tedious but tractable.
- Accounts under a personal email, where the provider has an ownership-transfer process for the business that pays the bill.
Genuinely severe
- No backups, or backups that have never been restored and turn out to be empty, partial, or years stale.
- Source code that exists only on a machine you do not have, with the running system as the sole surviving copy.
- Infrastructure inside a personal cloud account with no company relationship to the provider and no payment method you control.
- A production database with no schema documentation, no naming conventions, and business logic embedded in triggers or stored procedures nobody knew existed.
- Undisclosed third-party costs running on a personal card, where the first sign of a problem is a service switching off.
If you are in the second list, the priority is not understanding the system. It is getting a copy of everything (code, data, configuration) into storage the company controls, before anything else expires.
Reconstructing what was never written down
The instinct is to read the code first. Do it third. The code tells you what the system does; it does not tell you which parts matter, and a stranger reading an unfamiliar codebase cold will spend a week learning what the office manager could have said in an hour.
Start with the people who used it
Sit with the two or three people who touched the system every day and have them show you their actual work, including the parts they are slightly embarrassed by. The spreadsheet someone keeps because a report is wrong, the record they always edit twice, the screen everyone knows to avoid on Fridays. Each of those is an undocumented behavior, and together they map the parts of the system the business genuinely depends on.
Then read the data
The database is the most honest description of the business that exists. Table and column names reveal the model the system was built around. Row counts and date ranges show what is used and what was abandoned. Fields that are always empty are features nobody adopted, and fields holding values the schema never intended are workarounds with a story behind them.
Then read the code, in the order the money flows
Trace the highest-value workflow end to end (an order, a job, an invoice) rather than trying to comprehend the whole codebase. Follow it through the interface, the logic, the database writes, and any external call. One traced workflow gives you the shape of the system, the conventions the author followed, and enough grounding to make a first safe change.
Write down what you learn as you learn it. The person doing this work becomes the new single point of failure within about a month if the findings stay in their head.
Who takes it over
There are three realistic options, and the common mistake is choosing one when the right answer is usually two of them in sequence.
A paid handover with the person who left
If the departure was not acrimonious, a bounded consulting arrangement is the cheapest information you will ever buy. Keep it narrow and time-boxed: a fixed number of hours, a written list of questions, a walkthrough of deployment, and a documented answer for each item rather than an open-ended retainer. Anything touching their existing agreements, notice period, or intellectual property belongs with your counsel before you make the offer.
Hire a replacement
This is the instinct, and it is often the right destination and the wrong first move. Hiring takes months you do not have, and a single new hire recreates precisely the arrangement that produced this situation. It also asks a new employee to inherit an undocumented system with no one to ask, which is a difficult first ninety days and a common reason the replacement leaves too.
Bring in an outside team
A small external team is well suited to the stabilization phase specifically: taking custody of access, verifying backups, documenting the system, making the first careful changes, and keeping the business running while you decide what you want long term. The engagement should be scoped to produce documentation and a working deployment path that an internal hire can pick up, not to make you dependent on a different single point of failure.
The structural fix, so it does not happen again
Once the immediate risk is contained, spend a small amount of effort making the next departure ordinary. None of this requires a large team.
- Every account, domain, and repository is owned by a company identity, with billing on a company payment method and an owner in finance who sees the renewals.
- Credentials live in a shared password manager the business administers, not in one person's browser.
- At least two people have personally deployed a change to production in the last quarter. Not read the instructions, but done it.
- A restore from backup is tested on a schedule and the result is written down.
- A short operations document covers what runs, when, what breaks, and who to call, kept current as part of normal work rather than as a project.
- Alerts and error notifications go to a team address that more than one person reads.
- Contracts with any developer, employed or contracted, state that the company owns the code and that documentation and handover are part of the work.
The goal is not to eliminate reliance on skilled people. It is to make sure that when one of them leaves, you lose their judgement and their speed, but not your ability to operate.
Common questions
- Our system is still running fine. Is this actually urgent?
- Yes, though not for the reason it feels. The software will keep running until something external changes: a certificate expires, a card is declined, a vendor retires an API. The urgent work is securing access and verifying backups while everything is calm, because each of those tasks becomes significantly harder once a service has already switched off.
- What do we do if critical accounts are under a personal email address?
- Contact each provider and start their documented ownership-transfer process for the business that pays for the service; most have one, and it typically requires proof of company ownership and billing. Do this in parallel across every account rather than one at a time, because the process can take weeks. If a provider will not transfer an account, treat it as a matter for your counsel rather than attempting any workaround.
- Should we ask the person who left to come back as a consultant?
- If the relationship allows it, a narrow paid handover is usually the least expensive way to recover the knowledge, and it should be bounded, with set hours, a written question list, and specific deliverables such as a deployment walkthrough. Reconstructing the same information later typically costs several times more in engineering time. Any question about their notice period, existing agreements, or intellectual property belongs with your counsel before you make an offer.
- How long does it take an outside engineer to become useful on an unfamiliar system?
- For a small business system with a single author, expect a week or two to reach the point of making safe, small changes, and four to eight weeks before someone is comfortable with the whole thing. Access to the daily users shortens this more than any other factor. Availability of the original developer, even for a few hours, shortens it further.
- Should we rewrite the system now that nobody understands it?
- Almost never as a first response. A rewrite decided in the middle of a continuity emergency is being driven by unfamiliarity rather than by a business case, and it usually discards working behavior that nobody has documented yet. Stabilize, document, and operate the existing system for a few months first; if a rewrite is still justified after that, you will be able to specify it properly.
- What is the minimum we should have in place to avoid this next time?
- Company-owned accounts with company billing, credentials in a shared password manager, a backup that has been restored and verified, and at least two people who have deployed to production. That list takes days rather than months to establish and removes most of the severity from any future departure.