Ontwikkelaar weg? .NET-applicatie overnemen

Als de ontwikkelaar of het bureau achter een bedrijfsapplicatie verdwijnt, blijft de applicatie meestal nog een tijd draaien. Dat is precies het gevaarlijke. Niets lijkt kapot, totdat een certificaat verloopt, een server een update nodig heeft of een klant een fout vindt die niemand kan oplossen.

Dan opent iemand de repository, en de laatste vermelding luidt ongeveer zo:

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

Een overname is een volgorde van stappen, en die volgorde doet ertoe: eerst stelt u veilig wat van u is, dan zoekt u uit wat u werkelijk hebt, dan stabiliseert u het, en pas daarna beslist u wat u er op lange termijn mee doet. Dit is die volgorde, stap voor stap, zoals wij hem uitvoeren wanneer we een .NET-systeem overnemen.

48 uurVeiligstellen wat van u is
Eerste weekUitzoeken wat u hebt
Eerste maandStabiliseren
DaarnaBehouden, moderniseren of herbouwen

De eerste 48 uur: stel veilig wat van u is

Zorg er, nog voordat het technisch wordt, voor dat het bedrijf de sleutels in handen heeft en niet één persoon. Loop deze lijst door met degene die nog beheerderstoegang heeft.

Broncode. Waar staat de repository: GitHub, Azure DevOps, GitLab, Bitbucket? Is de organisatie van uw bedrijf of van het persoonlijke account van de ontwikkelaar? Maak vandaag nog een volledige kopie, met alle branches en tags.
Domein en DNS. Het account bij de registrar hoort op naam van uw bedrijf te staan en uw e-mailadres te gebruiken. Bureaus registreren domeinen voor klanten vaak op hun eigen naam.
Hosting en cloud. Azure-abonnement, AWS-account, virtuele server of eigen hardware: van wie is het, wie betaalt ervoor, wie kan inloggen? Voeg een tweede beheerder uit uw eigen bedrijf toe.
Databases en back-ups. Download nu een recente back-up en controleer of die echt terug te zetten is.
Inloggegevens en secrets. Connection strings, API-sleutels voor betaal-, e-mail- en sms-diensten, TLS-certificaten, app-registraties in Microsoft Entra ID. Zet alles op een rij wat de applicatie nodig heeft om te draaien.
Build en deployment. CI/CD-pipelines in Azure DevOps of GitHub Actions en de secrets die erin zijn opgeslagen. Als deployen handwerk was, schrijf dan precies op hoe het ging.
Licenties. Commerciële componentbibliotheken en tools staan vaak op het e-mailadres van de ontwikkelaar. Laat ze overzetten naar het bedrijf.
Het contract. Controleer van wie de code is en of u recht hebt op de broncode. Is dat onduidelijk, leg het dan nu schriftelijk vast, zolang de relatie nog werkt, en vraag zo nodig een jurist.

Pas als u overal beheerderstoegang hebt, haalt u de toegang van de vorige ontwikkelaar weg en wijzigt u elk secret dat hij kende. In omgekeerde volgorde kunt u uzelf buitensluiten van uw eigen systeem.

Is de ontwikkelaar nog bereikbaar, betaal dan voor een paar uur opgenomen overdracht: waar alles staat, hoe er wordt gedeployd, wat kwetsbaar is. Het is de goedkoopste verzekering die u ooit zult kopen.

Is het bureau failliet of wordt het opgeheven, neem dan zo vroeg mogelijk contact op met de curator of vereffenaar. Repositories, cloudaccounts en domeinen kunnen samen met het bedrijf verdwijnen.

De eerste week: zoek uit wat u werkelijk hebt

Hier zitten de verrassingen.

Bouw op een schone machine. Clone de repository op een net ingerichte machine en bouw alleen met wat er in de repository staat. Mislukt dat, dan hebt u het eerste ontbrekende stuk gevonden: een privé-NuGet-feed, een met de hand in een map gekopieerde DLL, een omgevingsvariabele die alleen op de oude laptop bestond.
Vergelijk met productie. Draait productie de code uit de repository? Hotfixes die rechtstreeks naar de server zijn gekopieerd en instellingen die met de hand in IIS of de Azure-portal zijn gewijzigd, komen vaak voor. Vergelijk versies, configuratie en de uitgerolde bestanden.
Deploy naar een testomgeving. Zolang u een wijziging niet veilig kunt uitrollen, kunt u niets veilig repareren.
Maak een inventarisatie.
- de .NET-versie en of die nog wordt ondersteund (ondersteuning voor .NET 8 en .NET 9 stopt op 10 november 2026)
- verouderde en kwetsbare pakketten
- externe diensten en koppelingen
- werk dat buiten de applicatie draait: SQL Server Agent-jobs, geplande taken in Windows, achtergronddiensten
- logging en monitoring, als die er al is
- tests: hoeveel er zijn en of ze slagen
Zoek naar tijdbommen. Dingen die op een bepaalde datum stukgaan: TLS-certificaten, client secrets in Microsoft Entra ID (die verlopen uiterlijk na 24 maanden), API-sleutels met een vervaldatum, licentieverlengingen, domeinverlengingen.
Praat met de gebruikers. Vraag wat er stukgaat, wat ze omzeilen en wat ze niet meer melden omdat het nooit werd opgelost.

Voor uw ontwikkelaars de commando’s die de eerste vragen beantwoorden:

git log -1 --format="%ci %an"                           # laatste commit en wie hem maakte
dotnet --list-sdks                                      # welke .NET-SDK's zijn geïnstalleerd
dotnet list package --outdated                          # pakketten met nieuwere versies
dotnet list package --vulnerable --include-transitive   # pakketten met bekende kwetsbaarheden

# wanneer het TLS-certificaat verloopt
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -enddate

# wanneer de client secrets van app-registraties in Microsoft Entra ID verlopen
az ad app list --all --query "[].{app:displayName, secretsExpire:join(', ', passwordCredentials[].endDateTime)}" -o table

De eerste maand: stabiliseer voordat u iets verandert

Monitoring en alerts. Application Insights of OpenTelemetry, plus een uptimecheck, zodat u van problemen weet voordat uw klanten bellen.
Geteste back-ups, niet alleen ingestelde.
Basisbeveiliging. Wijzig secrets, verplaats ze uit de repository naar een kluis, werk kwetsbare pakketten bij, vernieuw certificaten op tijd.
Tests rond wat geld oplevert. Leg vast hoe afrekenen, facturatie en rapportage zich vandaag gedragen, voordat u eraan komt.
Een README die een nieuwe ontwikkelaar kan volgen: hoe u bouwt, start, deployt en terugdraait.
Los de drie dingen op waarover gebruikers het meest klagen. Hun vertrouwen hoort bij de overname.

In een typische ASP.NET Core-applicatie zijn monitoring, een health check en secrets in een kluis maar een paar regels in Program.cs:

builder.Configuration.AddAzureKeyVault(                 // secrets uit Key Vault in plaats van uit appsettings.json
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential());

builder.Services.AddOpenTelemetry().UseAzureMonitor();  // requests, afhankelijkheden en exceptions in Application Insights
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();                 // kan de applicatie haar database bereiken?

var app = builder.Build();

app.MapHealthChecks("/health");                         // het adres dat de uptimecheck aanroept

Beslis daarna: behouden, moderniseren of herbouwen

Situatie	Meestal de juiste keuze
De code werkt en de bedrijfslogica klopt	Behouden, onderhouden, onderweg verbeteren
Het werkt, maar het framework wordt niet meer ondersteund of elke wijziging gaat traag	Stap voor stap moderniseren: upgraden, refactoren, onderdelen vervangen
De code past niet meer bij hoe het bedrijf werkt en de technologie is een doodlopende weg	Herbouw overwegen, met oud en nieuw naast elkaar

Een volledige herbouw is zelden het juiste eerste antwoord. Hij gooit jaren aan opgeloste fouten en uitzonderingen weg die nooit iemand heeft opgeschreven, en zet de ontwikkeling maandenlang stil. Joel Spolsky noemde opnieuw beginnen vanaf nul al in 2000 de ergste strategische fout die een softwarebedrijf kan maken. Dat geldt grotendeels nog steeds.

Waarschuwingssignalen die een overname duurder maken

alleen gecompileerde bestanden, geen broncode
productie komt niet overeen met de repository
wachtwoorden en sleutels in de repository gecommit
geen back-ups, of back-ups die nooit iemand heeft teruggezet
één server met handmatige deployments
een framework zonder ondersteuning: .NET Core 3.1, .NET 5 tot en met 7, of .NET Framework zonder plan
commerciële componenten zonder overdraagbare licenties
een zelfgebouwd framework dat alleen de vorige ontwikkelaar begreep

Niets hiervan is een reden tot paniek. Elk ervan is een reden om voor de eerste week meer tijd in te plannen.

Hoe u hier nooit meer terechtkomt

Accounts in eigendom van het bedrijf voor alles: code, cloud, domein en het e-mailadres waarop ze staan, met minstens twee beheerders.
Secrets in een kluis, niet in de code of in iemands hoofd.
Geautomatiseerde build en deployment, zodat een release niet afhangt van de laptop van één persoon.
Een README en een runbook die iemand anders dan de auteur echt heeft gevolgd.
Voor bedrijfskritische systemen van externe leveranciers een escrowregeling voor de broncode in het contract.

Hoe lang het duurt

Voor een typische bedrijfsapplicatie: toegang veiligstellen duurt een paar dagen, de inventarisatie ongeveer een week en het stabiliseren een paar weken. Wat u in de eerste week vindt, bepaalt de rest.

Bronnen

Things You Should Never Do, Part I, Joel Spolsky
App-referenties toevoegen en beheren in Microsoft Entra ID, Microsoft Learn
dotnet list package, Microsoft Learn