How to audit a .NET codebase you've inherited

The aim of an audit isn't to judge the code. It's to answer three questions: can we rebuild and redeploy this safely, what could hurt us, and what should we do first? Work through the steps in order, write down what you find as you go, and change nothing in production until the end.

1. Get it building from source

If you can't build it, you can't fix it. Get a copy of the source code into a repository your business controls, then try to build it on a clean machine, not the old developer's laptop.

• Find the solution: the .sln (or newer .slnx) file lists the projects. Check every project it references actually exists.
• Find the target frameworks: modern SDK-style projects declare them in <TargetFramework> or <TargetFrameworks>, for example net8.0. Older .NET Framework projects use <TargetFrameworkVersion>, for example v4.7.2.
• Check the SDK: a global.json file pins the .NET SDK version. dotnet --list-sdks shows what you have installed.
• Restore packages: run dotnet restore then dotnet build. For .NET Framework projects that use packages.config, restore with nuget restore and build in Visual Studio or MSBuild.
• Look for private feeds: a nuget.config may point to a private package feed or a network share. If that feed sits in an account you can't reach, you have a problem worth knowing about now.

Every manual step you need to get a working build is a finding. Write each one down.

2. Compare the source with what's deployed

The most dangerous assumption is that the code you've been given is the code that's running. It's common for the live server to hold fixes made directly on it and never committed.

• Compare file dates and assembly versions on the server with your own build.
• Look for loose source files on the server. Older ASP.NET "Web Site" projects and App_Code folders compile on the server, so someone may have edited code in place.
• Compare the server's configuration files with the ones in source control.

If parts of the live system have no matching source at all, decompiling the deployed assemblies with a tool such as ILSpy can recover readable code. Treat that as a last resort: it loses comments and original names for local variables, and you should check your licence position before relying on it.

3. Inventory dependencies and frameworks

For SDK-style projects, the .NET CLI will list what's out of date and what has known vulnerabilities:

• dotnet list package --outdated
• dotnet list package --vulnerable --include-transitive

These commands don't read packages.config, so for older .NET Framework projects review the packages in Visual Studio's NuGet package manager or work through packages.config by hand. Note any package that is abandoned, has no newer version for your target framework, or was copied in as a loose DLL with no package at all.

Then check each target framework against Microsoft's support dates:

• .NET 8 and .NET 9 both reach end of support on 10 November 2026. See .NET 8 end of support: what to do.
• .NET 10 is a long-term support release, supported until November 2028.
• .NET 7 and earlier are already out of support.
• .NET Framework 4.7 and later follow the support lifecycle of the Windows version they run on, so the server's operating system matters too. 4.6.2 loses support on 12 January 2027, and 4.6.1 and earlier are already out of support.

Check current dates on Microsoft's official .NET support policy.

4. Configuration and secrets

Read web.config (and its transform files) for .NET Framework, or appsettings.json and its environment-specific variants for modern .NET. List every connection string, API key, SMTP password, payment key and machine key.

• Note which secrets are committed to source control. Removing them from the latest version isn't enough: they stay in the repository's history.
• Note which are only on the server, so they're not lost if it fails.
• Plan to rotate anything the previous developer could have seen, then move secrets into proper storage such as environment variables, user secrets for development, or a key vault.

5. The database

• Schema: is it in source control, through Entity Framework migrations, a database project or SQL scripts, or does it only exist in the live database?
• Logic in the database: stored procedures, triggers and SQL Agent jobs often hold business rules the application code doesn't show. Script them out and keep them with the code.
• Version: check the database server's version against its support dates too.
• Backups: find out where they go, how often, and how long they're kept. Then restore one to a separate server and check the application runs against it. A backup nobody has restored is a hope, not a backup.

6. Deployment and hosting

Find out exactly how code reaches production: a build pipeline, a publish profile in Visual Studio, or files copied by hand. Then record where it runs and everything around it:

• IIS on a Windows server, Azure App Service, a container platform or something else, and who controls the account.
• SSL/TLS certificates: who issues them, when they expire and whether renewal is automatic.
• Scheduled tasks, Windows services, console apps and background jobs. These are easy to miss and often do important work overnight.
• Anything else on the same server that the application depends on.

The goal is a deployment you can repeat from source, ideally automated, with a way to roll back.

7. Security quick checks

• How users log in, how passwords are stored, and whether admin areas are properly protected.
• The vulnerable packages found in step 3.
• HTTPS everywhere, with HTTP redirected.
• Whether logs or error pages expose personal data, passwords or stack traces. Under UK GDPR, logs full of customer details are a liability in their own right.

This isn't a penetration test. It's a quick look for the problems that most often cause real harm.

8. Tests and observability

Run any automated tests that exist and note how many pass. Many inherited systems have none, which isn't a disaster but means changes need more care. Then find out how you'd know something was wrong: error logging, alerts, uptime monitoring, or nothing until a customer phones.

9. Write it down: a risk register

Turn your notes into a short risk register. For each finding, record what it is, what could happen, how likely it is, and what to do about it. Rank it by business impact, not technical interest. An expiring certificate or an untested backup outranks messy code every time.

What the result should look like

At the end you should have:

• source code you control that builds cleanly and matches production
• every account, secret and server documented, in your business's name
• a tested backup and a repeatable deployment
• a ranked list of risks with a recommended next step for each

That next step is usually stabilising the system and upgrading it to a supported framework, not starting again. A rewrite is rarely the right first answer: it's expensive and risky, and it throws away years of business rules that already work. For .NET Framework systems, a staged migration is normally the safer route.

Need a hand?

I've built and supported ASP.NET applications for more than 20 years, including a job, stock and invoicing system that has been in daily use for more than 11 years, and I've rescued a failing e-commerce site left behind by someone else. My fixed-price takeover audit, from £1,500, works through every step above and gives you a written report you keep. If you already know the system just needs bringing up to date, my .NET upgrade audit focuses on the upgrade path and costs the work.

Book a takeover audit