Entwickler weg? .NET-Anwendung übernehmen

Wenn der Entwickler oder die Agentur hinter einer Geschäftsanwendung verschwindet, läuft die Anwendung meist noch eine Weile weiter. Genau das ist gefährlich. Nichts wirkt kaputt, bis ein Zertifikat abläuft, ein Server ein Update braucht oder ein Kunde einen Fehler findet, den niemand beheben kann.

Dann öffnet jemand das Repository, und der letzte Eintrag lautet ungefähr so:

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

Eine Übernahme ist eine Abfolge, und die Reihenfolge zählt: Erst sichern Sie, was Ihnen gehört, dann finden Sie heraus, was Sie tatsächlich haben, dann stabilisieren Sie es, und erst dann entscheiden Sie, wie es langfristig weitergeht. Hier ist diese Abfolge Schritt für Schritt, so wie wir sie durchführen, wenn wir ein .NET-System übernehmen.

48 StundenSichern, was Ihnen gehört
Erste WocheHerausfinden, was Sie haben
Erster MonatStabilisieren
DannBehalten, modernisieren oder neu bauen

Die ersten 48 Stunden: sichern, was Ihnen gehört

Bevor es technisch wird, sorgen Sie dafür, dass das Unternehmen die Schlüssel hält und nicht eine einzelne Person. Gehen Sie diese Liste mit demjenigen durch, der noch Administratorzugang hat.

Quellcode. Wo liegt das Repository: GitHub, Azure DevOps, GitLab, Bitbucket? Gehört die Organisation Ihrem Unternehmen oder dem privaten Konto des Entwicklers? Erstellen Sie noch heute eine vollständige Kopie mit allen Branches und Tags.
Domain und DNS. Das Konto beim Registrar sollte auf Ihr Unternehmen laufen und Ihre E-Mail-Adresse verwenden. Agenturen registrieren Domains für Kunden oft auf den eigenen Namen.
Hosting und Cloud. Azure-Abonnement, AWS-Konto, virtueller Server oder eigene Hardware: Wem gehört es, wer bezahlt, wer kann sich anmelden? Fügen Sie einen zweiten Administrator aus Ihrem eigenen Unternehmen hinzu.
Datenbanken und Backups. Laden Sie jetzt ein aktuelles Backup herunter und prüfen Sie, ob es sich tatsächlich wiederherstellen lässt.
Zugangsdaten und Secrets. Connection Strings, API-Schlüssel für Zahlungs-, E-Mail- und SMS-Dienste, TLS-Zertifikate, App-Registrierungen in Microsoft Entra ID. Listen Sie alles auf, was die Anwendung zum Laufen braucht.
Build und Deployment. CI/CD-Pipelines in Azure DevOps oder GitHub Actions und die darin gespeicherten Secrets. Wenn das Deployment manuell war, schreiben Sie genau auf, wie es ablief.
Lizenzen. Kommerzielle Komponentenbibliotheken und Tools sind oft auf die E-Mail-Adresse des Entwicklers registriert. Lassen Sie sie auf das Unternehmen übertragen.
Der Vertrag. Prüfen Sie, wem der Code gehört und ob Sie Anspruch auf den Quellcode haben. Wenn das unklar ist, lassen Sie es sich jetzt schriftlich bestätigen, solange die Beziehung noch funktioniert, und fragen Sie bei Bedarf einen Anwalt.

Erst wenn Sie überall Administratorzugang haben, entfernen Sie den Zugang des früheren Entwicklers und ändern jedes Secret, das er kannte. In umgekehrter Reihenfolge können Sie sich aus Ihrem eigenen System aussperren.

Wenn der Entwickler noch erreichbar ist, bezahlen Sie ein paar Stunden aufgezeichnete Übergabe: wo alles liegt, wie deployt wird, was fragil ist. Das ist die günstigste Versicherung, die Sie je kaufen werden.

Wenn die Agentur insolvent ist oder aufgelöst wird, wenden Sie sich so früh wie möglich an den Insolvenzverwalter oder Liquidator. Repositories, Cloud-Konten und Domains können zusammen mit dem Unternehmen verschwinden.

Die erste Woche: herausfinden, was Sie tatsächlich haben

Hier stecken die Überraschungen.

Auf einem sauberen Rechner bauen. Klonen Sie das Repository auf einen frisch eingerichteten Rechner und bauen Sie nur mit dem, was im Repository liegt. Schlägt das fehl, haben Sie das erste fehlende Teil gefunden: einen privaten NuGet-Feed, eine von Hand in einen Ordner kopierte DLL, eine Umgebungsvariable, die es nur auf dem alten Laptop gab.
Mit der Produktion vergleichen. Läuft in der Produktion der Code aus dem Repository? Hotfixes, die direkt auf den Server kopiert wurden, und Einstellungen, die von Hand im IIS oder im Azure-Portal geändert wurden, sind häufig. Vergleichen Sie Versionen, Konfiguration und die ausgelieferten Dateien.
In eine Testumgebung deployen. Solange Sie eine Änderung nicht sicher ausliefern können, können Sie nichts sicher reparieren.
Bestandsaufnahme machen.
- die .NET-Version und ob sie noch unterstützt wird (Support-Ende für .NET 8 und .NET 9 am 10. November 2026)
- veraltete und verwundbare Pakete
- externe Dienste und Schnittstellen
- Arbeit, die außerhalb der Anwendung läuft: SQL-Server-Agent-Jobs, geplante Aufgaben in Windows, Hintergrunddienste
- Logging und Monitoring, falls es überhaupt welches gibt
- Tests: wie viele es gibt und ob sie durchlaufen
Nach Zeitbomben suchen. Dinge, die an einem bestimmten Datum ausfallen: TLS-Zertifikate, Client Secrets in Microsoft Entra ID (sie laufen spätestens nach 24 Monaten ab), API-Schlüssel mit Ablaufdatum, Lizenzverlängerungen, Domainverlängerungen.
Mit den Nutzern sprechen. Fragen Sie, was kaputtgeht, was sie umgehen und was sie nicht mehr melden, weil es nie behoben wurde.

Für Ihre Entwickler die Befehle, die die ersten Fragen beantworten:

git log -1 --format="%ci %an"                           # letzter Commit und wer ihn gemacht hat
dotnet --list-sdks                                      # welche .NET-SDKs installiert sind
dotnet list package --outdated                          # Pakete mit neueren Versionen
dotnet list package --vulnerable --include-transitive   # Pakete mit bekannten Schwachstellen

# wann das TLS-Zertifikat abläuft
echo | openssl s_client -connect yourapp.com:443 -servername yourapp.com 2>/dev/null | openssl x509 -noout -enddate

# wann die Client Secrets der App-Registrierungen in Microsoft Entra ID ablaufen
az ad app list --all --query "[].{app:displayName, secretsExpire:join(', ', passwordCredentials[].endDateTime)}" -o table

Der erste Monat: stabilisieren, bevor Sie etwas ändern

Monitoring und Alarme. Application Insights oder OpenTelemetry plus ein Verfügbarkeits-Check, damit Sie von Problemen erfahren, bevor Ihre Kunden anrufen.
Getestete Backups, nicht nur eingerichtete.
Sicherheitsgrundlagen. Secrets ändern, aus dem Repository in einen Tresor verschieben, verwundbare Pakete aktualisieren, Zertifikate rechtzeitig erneuern.
Tests rund um das, was Geld verdient. Bevor Sie Checkout, Rechnungsstellung oder Reporting anfassen, halten Sie fest, wie sie sich heute verhalten.
Eine README, der ein neuer Entwickler folgen kann: wie man baut, startet, deployt und zurückrollt.
Beheben Sie die drei Dinge, über die sich die Nutzer am meisten beschweren. Ihr Vertrauen gehört zur Übernahme dazu.

In einer typischen ASP.NET-Core-Anwendung sind Monitoring, ein Health Check und Secrets im Tresor nur ein paar Zeilen in Program.cs:

builder.Configuration.AddAzureKeyVault(                 // Secrets aus Key Vault statt aus appsettings.json
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential());

builder.Services.AddOpenTelemetry().UseAzureMonitor();  // Requests, Abhängigkeiten und Exceptions in Application Insights
builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>();                 // erreicht die Anwendung ihre Datenbank?

var app = builder.Build();

app.MapHealthChecks("/health");                         // die Adresse, die der Verfügbarkeits-Check aufruft

Dann entscheiden: behalten, modernisieren oder neu bauen

Situation	Meist die richtige Entscheidung
Der Code funktioniert und die Geschäftslogik stimmt	Behalten, warten, nebenbei verbessern
Er funktioniert, aber das Framework wird nicht mehr unterstützt oder jede Änderung ist langsam	Schrittweise modernisieren: Upgrade, Refactoring, Teile ersetzen
Der Code passt nicht mehr dazu, wie das Geschäft funktioniert, und die Technologie ist eine Sackgasse	Einen Neubau erwägen, mit Alt und Neu im Parallelbetrieb

Ein kompletter Neubau ist selten die richtige erste Antwort. Er wirft Jahre an behobenen Fehlern und Sonderfällen weg, die nie jemand aufgeschrieben hat, und friert die Entwicklung für Monate ein. Joel Spolsky nannte das Neuschreiben von Grund auf schon im Jahr 2000 den schlimmsten strategischen Fehler, den ein Softwareunternehmen machen kann. Das gilt im Großen und Ganzen bis heute.

Warnsignale, die eine Übernahme teurer machen

nur kompilierte Dateien, kein Quellcode
die Produktion stimmt nicht mit dem Repository überein
Passwörter und Schlüssel im Repository eingecheckt
keine Backups oder Backups, die nie jemand wiederhergestellt hat
ein einzelner Server mit manuellen Deployments
ein Framework ohne Support: .NET Core 3.1, .NET 5 bis 7 oder .NET Framework ohne Plan
kommerzielle Komponenten ohne übertragbare Lizenzen
ein selbst gebautes Framework, das nur der frühere Entwickler verstanden hat

Nichts davon ist ein Grund zur Panik. Jedes davon ist ein Grund, für die erste Woche mehr Zeit einzuplanen.

Wie Sie nie wieder hier landen

Unternehmenseigene Konten für alles: Code, Cloud, Domain und die E-Mail-Adresse, auf die sie registriert sind, mit mindestens zwei Administratoren.
Secrets in einem Tresor, nicht im Code oder im Kopf einer einzelnen Person.
Automatisierter Build und automatisiertes Deployment, damit ein Release nicht vom Laptop einer Person abhängt.
Eine README und ein Betriebshandbuch, denen jemand anderes als der Autor tatsächlich gefolgt ist.
Für geschäftskritische Systeme von externen Dienstleistern eine Klausel zur Hinterlegung des Quellcodes (Escrow) im Vertrag.

Wie lange es dauert

Bei einer typischen Geschäftsanwendung: Zugänge sichern dauert ein paar Tage, die Bestandsaufnahme etwa eine Woche, die Stabilisierung einige Wochen. Was Sie in der ersten Woche finden, entscheidet über den Rest.

Quellen

Things You Should Never Do, Part I, Joel Spolsky
Hinzufügen und Verwalten von App-Anmeldeinformationen in Microsoft Entra ID, Microsoft Learn
dotnet list package, Microsoft Learn