What to Do When the Developer Who Built Your Software Leaves

When the developer who built a business-critical application leaves, the immediate problem is rarely the code alone. The bigger risk is losing the knowledge of how the software is built, deployed, supported and connected to the rest of the business.

The right response is not to rush into a rewrite. It is to make the system understandable and supportable again.

1. Secure access before knowledge disappears

Start with the practical foundations: source control, build pipelines, cloud accounts, certificates, domains, databases, deployment credentials, third-party services and documentation. Confirm that these belong to the organisation rather than depending on an individual developer’s account.

For a .NET application this often means checking Git repositories, NuGet dependencies, Visual Studio or build requirements, SQL Server access, Azure resources, configuration and secrets, scheduled processes and any external APIs.

2. Prove that somebody else can build and deploy it

A repository is not the same thing as a recoverable application. A useful early test is whether a new engineer can take a clean environment, build the software, run it and understand how a release reaches production.

• Can the application be built from source?
• Are all dependencies still available?
• Can a non-production environment be created or restored?
• Is the database schema versioned and understood?
• Is deployment repeatable, or does it rely on undocumented manual steps?

If the answer to any of these is no, that is useful information. It gives you a concrete stabilisation backlog before the next urgent business change arrives.

3. Map what the software actually depends on

Older business applications often have a much wider footprint than expected: scheduled jobs, file transfers, payment providers, email services, Windows services, shared databases, reporting tools, SOAP endpoints and integrations known only to a few people.

Documenting these relationships matters because a seemingly small change can break a process outside the application’s obvious boundary.

4. Separate urgent support risk from technical debt

Do not turn the takeover into an attempt to fix every historical problem. First identify what could stop the business operating: unsupported infrastructure, fragile deployments, missing backups, expiring certificates, critical defects, single points of failure and integrations nobody can safely change.

Technical debt can then be prioritised according to business impact rather than age or aesthetic preference.

5. Add enough tests and observability to make change safer

A legacy .NET application does not need perfect automated test coverage before anybody touches it. Start around the behaviours that matter most. Characterisation tests can capture existing behaviour, while better logging and monitoring can make failures easier to diagnose.

The goal is confidence: knowing whether a change has affected an important business process and being able to understand production problems when they occur.

6. Decide whether to maintain, improve or modernise

Once the application is understood, the options become clearer. Stable areas may need nothing more than sensible maintenance. High-change areas may justify refactoring or extracting behind an API. Unsupported framework versions may need an upgrade. A few components may be candidates for replacement.

This is where an incremental legacy .NET modernisation strategy is usually more useful than assuming the whole application must be rebuilt.

A software takeover should reduce uncertainty first

The first objective after a developer leaves is not transformation. It is ownership. You want another engineer to be able to understand the system, support it, deploy it and make a small change without relying on knowledge that has walked out of the door.