What to Do When Your .NET Developer Leaves Without Documentation

The correct action in the first thirty days after an undocumented departure is reconnaissance, not cleanup. Four inventories establish what the system consists of, and every one of them must be complete before a change is made.

What the organization lost is the reasoning behind years of decisions: why the data model is shaped as it is, why an integration behaves as it does, what the workarounds are compensating for. The code remains and the system runs. The context that made it maintainable did not transfer.

The condition you are in

Most undocumented .NET systems are not badly written. They are unexplained.

A developer who built a system over several years holds facts that never reached a README:

• The nightly scheduled task must complete before the reporting service starts
• The stored procedure named sp_UpdateUser2, not sp_UpdateUser, is the one in production
• The third column in tbl_ImportLog is never populated, and dropping it breaks an SSIS package
• One application pool must be recycled in a specific order relative to another

The dangerous inference at this point is that a running system is an understood system. Continuous operation demonstrates that nothing has changed, not that anyone knows why it works.

The four inventories

Make no changes during this phase. The instinct to clean up (rename confusing identifiers, restructure data access, update packages) is reasonable and premature. A map comes first.

What is running in production. Not what is believed to be running. Pull the actual IIS configuration, enumerate Windows services on every server, and open Task Scheduler. Record application pool identities and the account each service runs under, because those accounts are frequently the only remaining record of what a component is permitted to touch.

What the database contains. Schema, foreign keys, indexes, triggers, jobs, and views. Note the tables with fifty million rows and the tables untouched for three years. On systems of this age, the database frequently describes what the system does more completely than the application code, because logic migrated into stored procedures over time.

What the external dependencies are. Third-party APIs, payment processors, government agency endpoints, FTP drops, email services, certificate authorities. Anything that fails if an endpoint changes, a credential rotates, or an account lapses. For each one, record where the credential lives and when it expires.

What the deployment process is. Whether it is manual or automated, who can execute it, what the steps are, and whether a staging environment exists. Attempt a deployment to a non-production environment during this phase. The steps that live outside the documented process only surface when someone tries to follow it.

This is reconnaissance rather than code review. The output is a written description of what exists, produced before anyone makes a change that causes an outage.

Where the recoverable history lives

The code is the least difficult part to recover. The reasoning is harder, and it exists in places outside the repository.

Sources in order of yield:

• Version control history. Commit messages are the closest thing to a decision record on most of these systems. A message explaining why a special case was added is worth more than the code implementing it.
• Issue tracker history, including closed and archived items. The ticket that prompted a strange piece of code usually states the business reason.
• Email and chat archives, searched against the names of external systems and vendors. Integration quirks are typically negotiated over email.
• The users. They cannot explain how the system works and they know exactly what it does, including which screens are wrong and what they do instead.

Spending time on these before forming assumptions about why the system behaves as it does is materially cheaper than forming the assumption and testing it in production.

When to bring in outside help

If the system supports critical operations and no one internally has deep .NET experience, engage help before an incident rather than after.

A two-week codebase assessment costs a fraction of an emergency response, and the emergency response is performed under worse conditions by people learning the system while it is down.

A complete assessment leaves the organization able to explain the system's behavior, name where risk is concentrated, and choose between maintaining and modernizing on evidence. It does not recover everything the developer knew. It produces a defensible baseline, which is the requirement for making any subsequent decision.

Building the record forward

The objective is not to reconstruct the previous developer's knowledge. It is to establish a documented foundation the next person can work from.

Write down each discovery as it is made: deployment steps, integration behavior, business logic residing in stored procedures, scheduled tasks and their ordering constraints, and the constructs that look wrong and are not. The record built during this period is what the next person inherits, and it is built at the only time the organization is paying attention to it.