Every business has at least one — the developer who built the system, who remembers why things were done a certain way, who knows which parts to never touch without a very good reason. They're so deeply embedded in the day-to-day that nobody has really thought about what happens if they leave.

Then one day, they do. And what follows is not a technical problem — it's a business crisis with technical symptoms.

After working with legacy .NET systems for over 11 years, I've seen this play out many times. The pattern is almost always the same. Here's what actually happens, and what you can do before it does.

The First 48 Hours

A bug gets reported. Something small, maybe. Staff can't process a certain transaction, or a report isn't generating. Someone asks: "Who do we call?"

And the answer is: the person who left.

In those first two days, everyone is scrambling to find any documentation, any notes, any handover material. Usually there isn't much. The system is still running, but nobody knows why it runs, or how long it will keep running without intervention.

The First Month

The new developer (internal or external) starts digging through the code. What they find is not a system they can read — it's an archaeology project. Code written in different styles across different years. Business logic buried in database stored procedures that don't have obvious names. Configuration values nobody can explain.

In one system I took over, a critical piece of business logic was split across three different files with no obvious connection between them. There were no comments explaining the relationship. The only way to understand it was to trace execution manually through the entire flow. What should have been a 2-hour fix took two full days, just to understand the problem — not solve it.

• The new developer spends 70–80% of their time reading code, not writing it
• Business decisions get delayed because nobody can answer "can the system support this?"
• Urgent fixes are made with low confidence — the developer isn't sure what else they might break
• Staff start working around system features because nobody is sure if they still work correctly

The Long-Term Damage

The crisis phase passes. The system stabilises. But the long-term cost is still accumulating.

Without someone who understands the full picture, every new developer adds their own interpretation of how the system works. Workarounds pile on top of workarounds. Decisions get made without knowing what already exists. Eventually you have a system where three different developers have each added their own version of the same functionality — because none of them knew the other two had done it.

Technical debt compounds faster without a foundation of shared knowledge. And the next developer who leaves takes a little more of that knowledge with them.

Signs Your System Is Already at Risk

You don't have to wait for someone to resign to assess your exposure. These are the warning signs:

• Only one or two people can answer detailed questions about how the system works
• Changes always have to go through a specific person because "only they know how"
• No documentation exists beyond the code itself — or what does exist is years out of date
• If that person was unavailable for two weeks, your team would genuinely struggle
• New developers take months to become productive because there's no structured onboarding to the system

What Real System Documentation Looks Like

Documentation is not just comments in code. A developer who has left can't clarify their comments — so documentation needs to capture why decisions were made, not just what the code does.

What actually protects a business is:

• Data flow documentation — how data moves through the system, what triggers what
• Decision records — why key architectural choices were made, what alternatives were considered and rejected
• Danger zones — specific areas of the code that are fragile, and what to watch out for
• Business logic documentation — the rules the system enforces, written in plain English, not just in code
• Environment and deployment notes — how the system is set up, what it depends on, how to deploy changes safely

How to Get There Without Disrupting Operations

The good news: you don't need a perfect handover to protect yourself. You need a structured starting point.

The most practical approach is a dedicated system understanding engagement — a focused period where an experienced developer reads through the system, maps what it does, documents the critical paths, and produces a written assessment. This is not about rewriting anything. It's about creating the knowledge base that lets your business survive the next transition without a crisis.

It also has a secondary benefit that most businesses don't expect: once the system is properly documented, onboarding new developers becomes dramatically faster — from months to weeks. The time investment pays back on the very first hire.

Have questions about your specific situation? Get in touch for a free consultation.