We Inherited a .NET Codebase Nobody Understands — Where Do We Start

Inheriting an undocumented .NET codebase is one of the more common situations in enterprise software. The instinct in the first few days is usually wrong in one of two directions: rewrite it immediately, or freeze everything until you understand it completely. Neither works. The first produces a rewrite that underestimates scope and reproduces bugs from the original. The second means nothing gets done for months.

Here's a structured approach to the first 60 days.

Before you judge the code

Codebases that have been running in production for years are usually more functional than they appear. The naming is inconsistent. The architecture doesn't match any pattern you'd recognize from a course or a book. There's a stored procedure doing work that belongs in the application layer. But it's running, and something it does is valuable enough that the organization has kept it alive.

That context matters before you start making architectural judgments. The question isn't whether the code is good — it's what the system actually does and what depends on it.

Getting oriented

Start by getting the application running locally. This sounds basic, but on an inherited codebase it frequently takes a week — missing connection strings, undocumented configuration, a database schema that's drifted from the code, a dependency on a service that only exists in production. The friction you encounter during this process is diagnostic. It tells you about the state of the codebase before you've read a single line of it.

Once it's running locally, trace the main user workflows. Don't read the code top to bottom — follow what a user does when they log in, submit a form, run a report, or trigger an integration. This gives you a functional map of the system before you have a technical one, and it anchors everything you read afterward.

Finding where the risk is

Not all parts of a codebase carry equal risk. Some modules are touched constantly and hold significant business logic. Others haven't been changed in years and don't need to be. Before you decide what to work on, you need to know:

Where the business-critical logic lives. Billing, integrations with external systems, state-changing operations that can't be reversed. If something here breaks, the business knows immediately.

Where the technical debt is most concentrated. Usually somewhere that will need to change soon — a module that's growing, an integration being extended, a component in the critical path of whatever comes next.

What the test coverage is. The answer on an inherited legacy codebase is often "minimal" or "none," but knowing what exists — even a handful of integration tests — tells you where the previous team felt confident and where they didn't.

This tells you where to focus your attention and where you can safely leave things alone for now.

What to avoid in the first 60 days

Don't propose a rewrite. Not because it might not eventually be the right answer, but because you don't know enough to make that case accurately. Rewrites proposed before a team understands the existing system consistently underestimate scope, miss edge cases the original handled, and reproduce bugs that took years to find the first time.

Don't update NuGet packages or change the target framework until you understand how the application is deployed and tested. Dependency changes in a legacy codebase have non-obvious effects, and without adequate test coverage, you won't know what broke until it's in production.

Don't assume that code that looks wrong is wrong. There are often reasons for choices that aren't visible until you understand the history — a vendor quirk, a compliance requirement, a bug that burned the team three years ago. Understand before you change.

Building the foundation

The goal in the first 60 days is to build enough understanding to make informed decisions. That means documenting what you learn as you go — deployment steps, external dependencies, the business logic in stored procedures, the integrations with quirks, the parts of the system that the previous team was clearly nervous about touching.

By the end of 60 days, you should be able to walk someone through how the system behaves, name the two or three things that most need to change, and say why each one matters. That's the foundation for a real modernization plan — not a reaction to the state of the code, but an informed assessment of what the system needs.