Your developer is gone: how to take over a .NET application without losing control

The developer or agency behind your .NET application is gone. What to secure in the first 48 hours, what to check in week one, and when a rewrite makes sense.

Vlado Pandžić

Vlado Pandžić · Founder · Senior .NET architect
Published · 7 min read

When the developer or agency behind a business application disappears, the application usually keeps running for a while. That is the dangerous part. Nothing looks broken until a certificate expires, a server needs an update, or a customer finds a bug that nobody can fix.

Then someone opens the repository, and the last entry reads something like this:

$ git log -1 --format="%cr · %an · %s"
1 year, 4 months ago · dev · quick fix, clean up later

Taking over is a sequence, and the order matters: first secure what you own, then find out what you actually have, then stabilise it, and only then decide what to do with it in the long run. This is that sequence, step by step, the way we run it when we take over a .NET system.

  1. 48 hoursSecure what you own
  2. Week oneFind out what you have
  3. Month oneStabilise
  4. ThenKeep, modernise or rewrite

The first 48 hours: secure what you own

Before anything technical, make sure that the company, not a person, holds the keys. Go through this list with whoever still has administrator access.

  • Source code. Where does the repository live: GitHub, Azure DevOps, GitLab, Bitbucket? Does the organisation belong to your company or to the developer’s personal account? Make a full clone today, with all branches and tags.
  • Domain and DNS. The registrar account should be in your company’s name and use your email address. Agencies often register domains for clients in their own name.
  • Hosting and cloud. Azure subscription, AWS account, virtual server or on-premises machine: who owns it, who pays for it, who can log in? Add a second administrator from your own company.
  • Databases and backups. Download a recent backup now, and check that it actually restores.
  • Credentials and secrets. Connection strings, API keys for payment, email and SMS providers, TLS certificates, app registrations in Microsoft Entra ID. List everything the application needs to run.
  • Build and deployment. CI/CD pipelines in Azure DevOps or GitHub Actions, and the secrets stored in them. If deployment is manual, write down exactly how it was done.
  • Licences. Commercial component libraries and tools are often registered to the developer’s email address. Have them transferred to the company.
  • The contract. Check who owns the code and whether you are entitled to the source. If it isn’t clear, get it in writing now, while the relationship still works, and ask a lawyer if you need to.

Only once you have administrator access everywhere, remove the former developer’s access and rotate every secret they knew. In the other order, you can lock yourself out of your own system.

If the developer is still reachable, pay for a few hours of recorded handover: where everything is, how to deploy, what is fragile. It is the cheapest insurance you will ever buy.

If the agency has gone out of business, contact whoever is winding it up as early as you can. Repositories, cloud accounts and domains can disappear together with the company.

Week one: find out what you actually have

This is where the surprises are.

  1. Build it on a clean machine. Clone the repository on a freshly set-up machine and build it using only what is in the repository. If it fails, you have found the first missing piece: a private NuGet feed, a DLL copied into a folder by hand, an environment variable that only existed on the old laptop.
  2. Compare it with production. Is production running the code from the repository? Hotfixes copied straight onto the server and settings changed by hand in IIS or the Azure portal are common. Compare versions, configuration and the deployed files.
  3. Deploy to a test environment. Until you can deploy a change safely, you can’t fix anything safely.
  4. Take inventory.
    • the .NET version and whether it is still supported (.NET 8 and .NET 9 lose support on 10 November 2026)
    • outdated and vulnerable packages
    • external services and integrations
    • work that runs outside the application: SQL Server Agent jobs, Windows scheduled tasks, background services
    • logging and monitoring, if there is any
    • tests: how many there are, and whether they pass
  5. Look for time bombs. Things that fail on a date: TLS certificates, client secrets in Microsoft Entra ID (they expire after at most 24 months), API keys with an expiry date, licence renewals, domain renewals.
  6. Talk to the users. Ask what breaks, what they work around, and what they stopped reporting because nobody fixed it.

For your developers, the commands that answer the first questions:

git log -1 --format="%ci %an"                           # last commit and who made it
dotnet --list-sdks                                      # which .NET SDKs are installed
dotnet list package --outdated                          # packages with newer versions
dotnet list package --vulnerable --include-transitive   # packages with known vulnerabilities

# when the TLS certificate expires
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -enddate

# when the client secrets of app registrations in Microsoft Entra ID expire
az ad app list --all --query "[].{app:displayName, secretsExpire:join(', ', passwordCredentials[].endDateTime)}" -o table

Month one: stabilise before you change anything

  • Monitoring and alerts. Application Insights or OpenTelemetry, plus an uptime check, so you hear about problems before your customers call.
  • Backups that are tested, not just configured.
  • Security basics. Rotate secrets, move them out of the repository into a vault, update vulnerable packages, renew certificates before they expire.
  • Tests around what earns money. Before you touch checkout, invoicing or reporting, pin down how they behave today.
  • A README a new developer can follow: how to build, run, deploy and roll back.
  • Fix the three things users complain about most. Their trust is part of the takeover.

In a typical ASP.NET Core application, monitoring, a health check and secrets in a vault come down to a few lines in Program.cs:

builder.Configuration.AddAzureKeyVault(                 // secrets from Key Vault instead of appsettings.json
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential());

builder.Services.AddOpenTelemetry().UseAzureMonitor();  // requests, dependencies and exceptions in Application Insights
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();                 // can the application reach its database?

var app = builder.Build();

app.MapHealthChecks("/health");                         // the address your uptime check calls

Then decide: keep, modernise or rewrite

Situation Usually the right call
The code works and the business logic is sound Keep it, maintain it, improve it as you go
It works, but the framework is out of support or every change is slow Modernise step by step: upgrade, refactor, replace parts
The code no longer matches how the business works, and the technology is a dead end Consider a rewrite, with old and new running side by side

A full rewrite is rarely the right first answer. It throws away years of fixed bugs and edge cases that nobody wrote down, and it freezes development for months. Joel Spolsky called rewriting from scratch the worst strategic mistake a software company can make, back in 2000. It still mostly holds.

Red flags that make a takeover more expensive

  • only compiled files, no source code
  • production doesn’t match the repository
  • passwords and keys committed to the repository
  • no backups, or backups nobody has ever restored
  • a single server with manual deployments
  • a framework out of support: .NET Core 3.1, .NET 5 to 7, or .NET Framework with no plan
  • commercial components without transferable licences
  • a home-grown framework that only the previous developer understood

None of these is a reason to panic. Each of them is a reason to budget more time for week one.

How to never be here again

  • Company-owned accounts for everything: code, cloud, domain, and the email address they are registered to, with at least two administrators.
  • Secrets in a vault, not in the code or in someone’s head.
  • Automated build and deployment, so releasing doesn’t depend on one person’s laptop.
  • A README and a runbook that someone other than the author has actually followed.
  • For business-critical systems built by outside suppliers, a source code escrow clause in the contract.

How long it takes

For a typical business application: securing access takes a few days, the inventory about a week, and stabilisation a few weeks. What you find in week one decides the rest.

Sources

© 2026 ProCoding — All rights reserved.Legal notice and privacySplit, Croatia