Code Audit vor Projektübernahme im KMU worauf du achten solltest

Der bisherige Dienstleister ist verschwunden, der Code liegt in einem Git-Account, die Produktion läuft auf einem Server außerhalb eurer Zuständigkeit. Vertrieb wartet auf ein Feature. Support sammelt Fehlermeldungen. Und du sollst entscheiden, ob ihr weiterbaut oder neu startet.

Ein Code Audit vor Projektübernahme ist in so einer Lage der Sicherheitsgurt, der dich nicht fesselt, sondern festhält, wenn es ruckelt. Ohne eine Checkliste wird die Entscheidung schnell zum Bauchgefühl, das später teuer wird, weil kleine Lücken im Alltag große Kreise ziehen können.

Ich rate zu einer geordneten Durchsicht, bevor irgendwer an Servern arbeitet oder Commit-Rechte verteilt. Erst die Basis, dann Handeln. In Projekten sehen wir, wie viel Ärger das spart, weil Zugänge geordnet sind, der aktuelle Stand reproduzierbar baut, Architektur und Abhängigkeiten verständlich werden und der Betrieb einen Plan hat. Diese Reihenfolge zwingt zu einer nüchternen Bewertung und gibt dir die Freiheit, bewusst Ja oder Nein zu sagen, statt dich in ungeplanten Rettungsaktionen zu verheddern.

Zugänge und Rechte sichern, bevor jemand den Server anfasst

Ohne vollständige Zugänge bleibt jedes Audit ein Torso. Bevor der erste Terminalbefehl fällt, legst du die organisatorische Ebene gerade. Das beginnt bei der Eigentümerschaft des Quellcodes, denn nur eine Eigentümerrolle erlaubt es, andere zu verwalten und spätere Übergaben rechtssicher zu machen. Achte darauf, dass das Repository eurer Organisation gehört, nicht dem Privataccount eines Entwicklers oder einer einzelnen Agenturadresse.

Gleiches gilt für die Build-Pipeline, also den automatisierten Bauprozess: Wer darf Pipelines ändern, Secrets hinterlegen oder Deployment-Keys austauschen. Wenn diese Punkte unklar sind, liegen Risiko und Tempo nicht bei dir. Hosting-Zugänge kommen als nächstes, mit Cloud-Konten, Serverzugängen, Container-Registry für Images, Datenbankverwaltung und Dateispeicher. Dazu Einträge beim Domain-Registrar sowie die Zertifikatsverwaltung, damit ablaufende Zertifikate nicht überraschend zum Betriebsstopp führen.

Hier geht es nicht nur um Zugangsdaten. Ziel ist die Kontrolle in deinem Haus. Zwei-Faktor-Authentifizierung auf eure Geräte, Wiederherstellungscodes sicher hinterlegt, alte Zugänge entzogen. So verhinderst du, dass ehemalige Vertragspartner unbemerkt Systeme erreichen. Lizenzen gehören ebenfalls auf den Tisch, darunter Abos für Drittdienste, verwendete Fonts und Icons sowie Bibliotheken mit Registrierungspflicht. Wer ist Vertragspartner, wer zahlt, welche Fristen, welche Übertragungsrechte. Lege ein Übergabeprotokoll an, das präzise festhält, was übergeben wurde und in welchem Zustand, damit niemand später darüber streitet.

Erst wenn Zugänge, Rechte und Eigentum gesichert sind, lohnt der Blick in die Technik. Alles andere ist Kosmetik.

Code Audit vor Projektübernahme: lauffähiger Stand und reproduzierbarer Build

Der nächste Schritt ist handfest und ohne Abkürzungen. Baue die Anwendung lokal, ohne geheime Handgriffe aus Köpfen. Ein gutes Zeichen sind ein verständliches Readme, ein Setup-Skript oder Containerdefinitionen, die Abhängigkeiten, Datenbankmigrationen und Umgebungsvariablen in einem Rutsch adressieren. Kein Copy und Paste aus Chatverläufen. Kein Schieberegler nur beim Vorgänger.

Starte mit einem frischen Rechnerbild oder einer sauberen Entwicklungsumgebung. Folge dann der Anleitung, so wie eine neue Kollegin es tun würde, die das Projekt zum ersten Mal sieht und keine Altlasten mitschleppt. Scheitert der Build an fehlenden Werkzeugen, veralteten Paketquellen oder privaten Artefaktservern, gehört das auf die Risikoliste und zwar sichtbar. Findet sich eine Beispieldatei für Umgebungsvariablen, die sensibel benannte Schlüssel erklärt, ist das ein Pluspunkt. Stehen dort nur Platzhalter, muss nachgearbeitet werden, bevor jemand über Features nachdenkt.

Docker oder andere Container helfen, weil sie eine Umgebung kapseln, sind aber kein Ersatz für klare, überprüfbare Schritte. Prüfe außerdem, welcher Branch oder Tag den Live-Stand widerspiegelt. Gibt es Skripte für Datenbankmigrationen, die reproduzierbar funktionieren. Lässt sich alles in einer Testumgebung mit anonymisiertem Datenstand starten. Sobald lokal ein lauffähiger Stand existiert, spürt man die Codebasis: Entweder wirkt sie nachvollziehbar und ruhig, oder jede kleine Änderung verursacht Nebenwirkungen, die du später im Support wiederfindest.

Architektur und Abhängigkeiten verstehen: Datenflüsse, Dienste, Lizenzen

Bevor Änderungen geplant werden, brauchst du ein Bild der Anwendung. Welche Module gibt es, welche Dienste laufen getrennt, wo liegen Datenbanken und Dateispeicher, welche externen APIs hängen dran. Ein typischer Fluss im Tagesgeschäft: Auftragsannahme im Portal, Validierung, Übergabe in die Warenwirtschaft, E-Mail an den Kunden, Rechnung an die Buchhaltung, Status zurück ins Portal. Dazu kommen häufig ein Zahlungsdienst und ein Versanddienstleister, die eigene Anforderungen und Fehlerfälle mitbringen.

Solche Skizzen zeigen Kopplungen und Engpässe. Alarme gehen an, wenn kritische Teile nur in einer Ecke leben, die an vielen Stellen gleichzeitig berührt wird. Stark verschachtelte Abhängigkeiten machen jeden Fix riskant, weil eine Änderung an einer Stelle drei weitere Stellen trifft. Bibliotheken, die nicht mehr gepflegt werden, erhöhen das Ausfallrisiko. Oder ein einziger, zentraler Dienst orchestriert alles, wächst bei jeder Erweiterung weiter und bremst das Team bei jeder Kleinigkeit aus.

Hier beginnst du, technische Schulden zu bewerten, statt ein diffuses Gefühl zu haben, dass etwas wackelt. Lizenzen gehören in denselben Blick: Welche Open-Source-Komponenten sind im Einsatz, welche Pflichten zur Nennung oder zum Offenlegen bestehen, welche Einschränkungen gelten im gewerblichen Betrieb. Nutzt die Oberfläche Fonts oder UI-Kits, die an ein Projekt gebunden sind. Viele Risiken stecken in Verträgen und Lizenzen, nicht im Code selbst. Wenn klar ist, welche Bausteine das System tragen und wo Abhängigkeiten liegen, planst du, wo du entkoppelst, was ersetzt wird und was stabil bleibt.

Qualität im Alltag prüfen: Tests, Logs, Fehlerszenarien, Sicherheit

Eine Codebasis, die du übernehmen willst, muss im Alltag handhabbar sein. Gibt es automatisierte Tests, die beim Bauen laufen und an den richtigen Stellen anschlagen. Niemand verlangt akademische Vollabdeckung. Wichtig sind Tests für zentrale Geschäftsregeln und heikle Randfälle, weil sie Aktualisierungen absichern und den Mut geben, Fehler vor dem Kunden zu fangen.

Logs sind das zweite Sicherheitsnetz, ohne das Support im Nebel stochert. Sie brauchen Ereignisse mit Kontext, also Zeitpunkt, Anfrage, ID, Entscheidung und Ausnahme. Wenn aus dem Support ein Fehlerbericht kommt, muss sich der Weg bis zur Ursache nachzeichnen lassen. In Projekten sehen wir häufig, dass Entwickler direkt im Live-System korrigieren, weil die Loglage dünn ist. Das schafft kurzfristig Ruhe, verlagert die Kosten aber nach hinten.

Sicherheit erkennst du an wenigen, belastbaren Merkmalen. Ein Rechtekonzept trennt Rollen und Berechtigungen, statt überall Sonderfälle zu bauen. Eingabevalidierung stoppt schmutzige Nutzereingaben, bevor sie tief in die Anwendung dringen. Geheimnisse wie Passwörter und Tokens liegen nicht im Klartext in Repositories oder Konfigurationsdateien. Updates von Abhängigkeiten laufen regelmäßig, bekannte Sicherheitslücken werden adressiert. Fehlen diese Basics, planst du zuerst hier Arbeit ein. Neue Features warten, bis das Fundament trägt.

Betrieb und Wartung klären: Monitoring, Backups, Deployments, Zuständigkeiten

Ohne klares Betriebsmodell übernimmst du Verantwortung, aber keine Kontrolle. Monitoring gehört nach vorn, mit Kennzahlen zu Verfügbarkeit, Fehlern und Last. Benachrichtigungen müssen euch erreichen, nicht nur ein hübsches Dashboard füttern. Backups existieren und lassen sich zurückspielen, nicht nur theoretisch. Bei uns endet das gern in einer Wiederherstellungsprobe, die zeigt, dass eine neue Instanz aus einem Backup hochfährt und das System wieder bedienbar ist.

Deployments brauchen einen definierten Weg. Wer darf ausrollen, wie wird vorab geprüft, welcher Rollbackpfad greift, wenn nach dem Release etwas hakt. Ein Änderungsprotokoll stellt sicher, dass das Team weiß, was live ging und was noch wartet. Parallel dazu braucht es einen Plan für Updates des Betriebssystems, der Datenbanken und der Laufzeitumgebungen, damit nicht in einem ungünstigen Moment das Fundament wegrutscht.

Zuständigkeiten sind kein Formalismus. Wer reagiert, wenn das Monitoring anspringt, welche Vertretung existiert, welche Reaktionswege gelten. Welche Dienstleister sind beteiligt, welche Verträge sichern Erreichbarkeit. Erst wenn Betrieb und Wartung geregelt sind, fügt sich die Lösung in euren Alltag, statt E-Mail-Ketten und Chat-Pings zu erzeugen, die niemand einordnet. Mehr zu Aufgaben und Kosten findest du hier: was zu Wartung und Betrieb in KMU gehört.

Entscheidung und Fahrplan: übernehmen, stabilisieren oder neu aufsetzen

Am Ende dieser Durchsicht steht eine bewusste Entscheidung. Hilfreich sind Go- und No-Go-Kriterien sowie ein kurzer Fahrplan, der Risiken zuerst entschärft. Mir reicht dafür oft ein knappes Protokoll mit Befunden, Risiken, Maßnahmen und einer Empfehlung, damit alle denselben Stand lesen und nicht in Meinungen versinken. Danach geht es darum, ob ihr die Fremdarbeit weiterführt oder Grenzen zieht, die ihr nicht überschreitet.

Eine kompakte Checkliste für die Entscheidung hilft:

• Der Code baut lokal und in einer frischen Umgebung ohne Sonderwissen aus dem Vorgängerteam

• Alle geschäftskritischen Zugänge und Eigentumsrechte sind bei euch, inklusive Domain und Deployment

• Architektur und Datenflüsse sind dokumentiert und nachvollziehbar, Engpässe sind benannt

• Monitoring, Backups und Einspielweg sind funktionsfähig, ein Rückweg ist definiert

• Grundlegende Sicherheits- und Teststandards sind vorhanden oder kurzfristig herstellbar

Trifft das zu, kannst du die fremde Codebasis übernehmen und gezielt stabilisieren. Fehlt mehr als ein Punkt, ist die Gefahr groß, in eine Endlossanierung zu rutschen, die Team und Budget bindet. Dann lohnt sich ein Blick auf Alternativen. In manchen Fällen ist es wirtschaftlicher, neu zu beginnen oder Teile zu ersetzen, statt jeden Winkel zu retten. Wenn du neu beginnst, lohnt sich zuerst ein sauberes Anforderungsdokument: Lastenheft für individuelle Software im KMU erstellen: was wirklich rein muss. Manchmal reduziert ein sauberer Datenaustausch die notwendige Sanierung, weil vorhandene Systeme bleiben können und nur reden lernen müssen.

Brauchst du eine zweite, nüchterne Meinung. Wir sehen uns dein Projekt in einem kurzen Audit an und sagen dir offen, ob wir übernehmen würden, was es dafür braucht oder wovon wir abraten. Hier anfragen: Projekt-Rettung.

Wer bei uns solche Audits macht, stellen wir im Team vor. Und wenn du selbst Lust auf solche Projekte hast: Offene Stellen findest du unter Karriere.