The Person Who Ran Your System Left: A 30-Day Plan

Summary: When the one person who understood your system leaves, use the first 30 days in this order: secure access and credentials, inventory what exists, stop the immediate risks, document the current state (AI-assisted code reading helps), check it with the people who use the system, then decide whether to keep, repair, or replace it. Do not rewrite anything yet.

Contents

1. What should you do first when the system owner leaves?
2. What does the 30-day order of work look like?
3. Week 1: how do you secure access and take inventory?
4. Where do you get documentation when nobody wrote any?
5. Why must AI-generated documentation still be checked with users?
6. Keep, repair, or replace: what should the decision rest on?
7. When does this approach not fit?
8. FAQ

1. What should you do first when the system owner leaves?

Secure access first. Do not try to fix or fully understand the system yet. If it is running, let it run. What leaves with the person is rarely the source code. It is everything outside the code: accounts registered under a personal email, two-factor codes tied to their phone, and the monthly manual tasks nobody wrote down.

This is common in small and mid-sized companies. One person built the system years ago, it worked, so nobody asked questions. On their last day the company finds out that nobody knows which server it runs on, where the domain is renewed, or who receives the error alerts.

If the person is still reachable, ask for one or two hours before they go. One question beats a long handover document: "Where does this system usually break, and what do you do when it does?" If they are already gone, the rest of this article still applies. It just takes longer.

2. What does the 30-day order of work look like?

A 30-day system takeover has six steps, ordered from the risk of losing things for good to the risk of misunderstanding them. The table is a checklist you can use as a frame. You can do most of the first rows yourself without an engineer.

The windows overlap, and they should. Securing access and stopping risks do not wait for each other.

3. Week 1: how do you secure access and take inventory?

In week one, regain full admin control and list every component of the system, including the ones that look unimportant. You do not need to know how it works yet. You need to know what it consists of and who holds the keys.

Work through it in groups:

1. Accounts and permissions. Server or cloud provider, source code repository, domain registrar, the email service that sends automated mail, monitoring tools. For each one, write down who owns it and how it is recovered. If an account is under the departed person's name, move it to the company while you can still reach them.
2. Expiry dates. Domain, SSL certificate, software licenses, server rental contracts. Systems that have run for years more often die from a forgotten expiry date than from a code bug.
3. Scheduled jobs. Month-end reports, nightly data sync, backups. They usually live in server configuration, not in the source code, so reading the code will not reveal them.
4. Connections to other systems. Accounting software, payment gateways, partner systems, files exchanged over FTP.

At the same time, set one simple rule: nobody changes the system until it is understood. A "quick cleanup" made without knowing the structure is how a working system becomes one nobody dares to touch.

4. Where do you get documentation when nobody wrote any?

When no documentation exists, the source code is the only reliable record of what the system does, and AI reading the code can produce a current-state document far faster than reading it by hand. Tools such as Claude Code read an entire project's codebase and answer questions about it, according to Anthropic's public documentation.

For a current-state document, we ask AI concrete questions: which screens and functions exist, what data is stored where, which file holds each calculation rule, which outside services the system calls. The result is a draft for a person to check, not a final document.

VAON has done this on real projects: building a description of the current system from its source code before deciding whether to fix it or rebuild it. We have no measurements of time saved yet, so we give no figures. What we are sure about is the order. With a current-state description first, cost and scope can be discussed on solid ground. This is also the content of entrance A in VAON's 仕様確定フェーズ (Spec Lock Phase): reading the code, interviewing the people who run the system, and measuring.

One caution before any code goes into an AI tool: check your internal policy and contracts to see whether it is allowed. VAON does not put a customer's code into AI tools until the customer has given permission.

5. Why must AI-generated documentation still be checked with users?

Documentation built from source code tells you what the system does, not why, so every item has to be checked with the people who use it for their daily work. The code is only part of what they rely on.

Five places where code-derived documentation tends to drift:

• Reasons. The code shows "orders above 500,000 yen need manager approval". It does not show why that number.
• Dead rules. A branch still sits in the code although the business dropped it long ago. AI will describe it as live.
• Logic outside the code. Master data in the database, configuration of the real environment, manual steps, third-party systems.
• Long-standing bugs. A bug that has existed for years can be recorded as a "spec". Users have lived with it so long they think it is how the system works.
• Things nobody opens. A screen that exists in the code but that nobody uses.

A simple way to check: pick two or three real users, open each item in the document, and ask "do you still do this, and is this how you do it?" Write the answer next to the item: correct, wrong, or no longer used. A 60-minute session with the person who runs the process often exposes things the source code never shows.

6. Keep, repair, or replace: what should the decision rest on?

The keep, repair, or replace decision should rest on three things you can check: whether the system still serves today's business process, what the risk of keeping it is, and what leaving it as is costs. "This code feels old" is not enough reason to replace it.

For large systems, replacing parts without stopping the old one is described in our article on modernizing a legacy CMS with zero downtime. If you choose to rebuild with an offshore team, read about offshore development without depending on one bridge engineer (BrSE). The current-state documentation step is covered in more detail in building a current-state spec from source code with AI.

7. When does this approach not fit?

This approach does not fit when the system is broken right now, when the source code is gone, or when code may not be put into AI tools. Each case needs a different response.

• The system is down or corrupting data. Recovery comes first, not documentation. Documentation waits.
• The source code is gone. Only a compiled build remains, or the code lived on a personal machine that was wiped. You then have to reconstruct from the running system and its data, which takes longer and gives lower confidence.
• Code may not go into AI. The AI step does not run and the code reading goes back to being manual. It still works, just slower.

Also, 30 days assumes a system of moderate size. One with many modules and many years of history may need longer in the step of checking with users, and you should accept that rather than shorten the step.

8. FAQ

The owner has left. What should I do on day one? List every account tied to the system (server, domain, code repository, email, monitoring) and find out who owns each. If the former owner is reachable, ask them to transfer ownership or give you the recovery method before their own accounts are shut down.

Should we rewrite the whole system right away? No. Without a current-state document you do not know everything the system does, so a rewrite tends to miss functions that users need and nobody remembers. Document and check with users first, then decide.

Can we trust documentation that AI writes from source code? Enough to use as a draft, not as a final document. AI tells you what the system does but not why, and it may record a long-standing bug as a specification. Each item needs a business user to confirm it as right or wrong.

What if our source code may not go into AI tools? You can still do the work. The AI code-reading step is skipped and an engineer reads the code by hand, which takes longer. VAON only puts code into AI tools after the customer has given permission.

Where can VAON help? In writing the current-state documentation and deciding whether to keep, repair, or replace, through entrance A of the 仕様確定フェーズ. It runs 1 to 2 weeks at a fixed price quoted in advance, and you can stop after it.

Is your system living in the head of someone who has left? The first 60-minute call includes our CEO, needs no preparation, and carries no obligation. We listen to where you are and point out the first step. Book a free 60-minute consultation

References

• Anthropic, Claude Code overview (Claude Code reads a project's codebase, edits files, and runs commands): https://code.claude.com/docs/en/overview (checked Oct 17, 2026)