The most common legacy software crisis isn't a system failure. It's a person leaving. The developer who built the system — who was the only one who understood it — retires, resigns, or simply becomes unavailable. And suddenly a business-critical application becomes a mystery.

Why this matters

Business software built or maintained by a single developer carries enormous institutional risk. Everything about how the system works lives in one person’s head:

• Why certain calculations work the way they do
• What the edge cases are and how the system handles them
• Which parts of the code matter and which are historical artefacts
• What will break if you change something

When that person leaves, the risk doesn’t go away. The software keeps running — until it doesn’t. And when something breaks or needs to change, there’s nobody to ask.

What I do

I work from the software itself — the running application, the database, the executable files — to reconstruct the knowledge that was lost.

• Document what the application does in plain language
• Identify and explain the business rules embedded in the software
• Map the data structures and explain how data flows through the system
• Identify fragile points — what's most likely to break and what the impact would be
• Produce a handover document that a new developer can actually use
• Assess the options for modernization or replacement

The best time to do this

Before the developer leaves, if that’s still possible. A structured knowledge transfer while the developer is still available produces much better outcomes than recovery after the fact.

But I work in both situations. If the developer has already left, I work from what remains.

What I need

• Access to the running application
• Access to or a copy of any source code
• The ability to talk to anyone who uses the system daily
• If the developer is still available for even a short time, that’s valuable — but not required

---