Bestehende Software übernehmen: So gelingt der Entwicklerwechsel

Die meisten Anfragen zu diesem Thema kommen nicht aus einer entspannten Lage. Der Entwickler ist weg, die Agentur soll gewechselt werden, oder es traut sich intern seit Monaten niemand mehr, an einer bestimmten Stelle etwas zu ändern. Manchmal kommt dazu, dass niemand im Unternehmen genau sagen kann, wo die Anwendung eigentlich läuft und wem welche Zugänge gehören.

Das ist unangenehm, aber es ist normal. Und es ist reparierbar.

Wichtig ist mir vorweg eines: Eine Übernahme bedeutet nicht, am ersten Tag möglichst viel Code umzuschreiben. Zuerst kläre ich, wie das System tatsächlich funktioniert, welche Abhängigkeiten bestehen und wo echte Risiken liegen. Erst danach lässt sich seriös entscheiden, was bleiben kann und was verändert werden muss. Das klingt weniger spektakulär als ein Neustart. Für Ihr Unternehmen ist es fast immer die wertvollere Arbeit.

Wann eine technische Übernahme nötig wird

Die Ausgangslagen unterscheiden sich, das Grundproblem ähnelt sich:

• Der bisherige Entwickler ist nicht mehr erreichbar oder nicht mehr an Bord.
• Eine Agentur oder ein Freelancer soll abgelöst werden.
• Eine intern entstandene Anwendung braucht professionelle Betreuung.
• Ein Prototyp soll von jemandem weitergeführt werden, der ihn in den Betrieb bringt.
• Niemand weiß mehr genau, wie Deployment, Datenbank und externe Dienste zusammenspielen.
• Neue Funktionen sind nötig, aber jede Änderung erzeugt Fehler an anderer Stelle. Die entscheidende Frage lautet dann nicht, ob der Code schön ist. Sie lautet: Können wir dieses System kontrolliert weiterentwickeln und zuverlässig betreiben?

Schritt 1: Zugänge und Rechte klären, bevor irgendetwas anderes passiert

Ohne Zugriff ist alles Weitere Theorie. Je nach Anwendung gehören dazu:

• Quellcode und Versionsverwaltung
• Hosting- und Cloud-Accounts
• Datenbank und Backups
• Domains und DNS
• CI/CD und Deployment
• App-Store-Zugänge
• E-Mail-, Zahlungs- und sonstige externe Dienste
• Secrets, API-Schlüssel und Umgebungsvariablen Dieser Punkt wird gern als Formalität behandelt. Tatsächlich entscheidet er darüber, ob Sie Ihre eigene Anwendung unabhängig betreiben können. Ein Repository allein ist noch keine Übergabe.

Wenn die Trennung vom vorherigen Dienstleister nicht einvernehmlich verläuft, wird dieser Schritt zum kritischen Pfad. Prüfen Sie deshalb früh, ob die Nutzungsrechte am Code vertraglich tatsächlich bei Ihnen liegen und ob Accounts auf Ihr Unternehmen laufen oder auf eine Privatperson. Ich bin kein Anwalt, aber ich habe gesehen, wie viel Zeit verloren geht, wenn diese Frage erst nach dem Kündigungsschreiben gestellt wird. Bei Unsicherheit lohnt sich eine kurze anwaltliche Einschätzung, bevor die Zusammenarbeit endet.

Schritt 2: Das System reproduzierbar zum Laufen bringen

Eine Anwendung, die nur auf einem bestimmten Rechner startet, ist nicht übergeben. Ich muss sie lokal bauen, starten, testen und kontrolliert ausliefern können, ohne jemanden anzurufen.

Hier zeigen sich fast immer die ersten Lücken:

• Die Dokumentation ist veraltet.
• Abhängigkeiten sind nicht mehr verfügbar oder nicht mehr gepflegt.
• Konfigurationen wurden irgendwann direkt auf dem Server geändert.
• Datenbankänderungen sind nicht versioniert.
• Das Deployment besteht aus undokumentierten Einzelschritten.
• Entwicklung, Test und Produktion unterscheiden sich unkontrolliert. Das Ziel ist kein perfektes Handbuch. Das Ziel ist ein wiederholbarer Ablauf, der nicht vom Gedächtnis einer einzelnen Person abhängt.

Schritt 3: Die fachliche Logik verstehen

Code erklärt, wie etwas umgesetzt wurde. Er erklärt nicht, warum.

Deshalb frage ich in dieser Phase mehr, als ich lese:

• Welche Prozesse sind geschäftskritisch?
• Welche Nutzerrollen gibt es tatsächlich, nicht nur laut Konzept?
• Welche Daten dürfen unter keinen Umständen verloren gehen?
• Welche Sonderfälle treten im Alltag auf, die niemand vorgesehen hat?
• Welche externen Systeme liefern oder erwarten Daten?
• Welche Fehler sind ärgerlich, und welche kosten Sie richtig Geld? Wer nur den Code betrachtet, optimiert mit hoher Wahrscheinlichkeit an der falschen Stelle. Diese Fragen beantworten meist nicht die Entwickler, sondern die Menschen, die täglich mit der Anwendung arbeiten.

Schritt 4: Risiken priorisieren statt aufzählen

In jeder gewachsenen Anwendung finden sich technische Schulden. Das allein ist kein Grund zur Beunruhigung, sonst wäre jedes Projekt der Welt in Alarmbereitschaft. Entscheidend ist, welche davon Betrieb, Sicherheit oder Weiterentwicklung konkret gefährden.

Ich sortiere Befunde deshalb immer in drei Gruppen:

Kritisch: gefährdet unmittelbar den Betrieb oder sensible Daten. Offen zugängliche Daten, fehlende oder nie getestete Backups, ein Deployment, das sich nicht wiederholen lässt.

Wichtig: sollte zeitnah gelöst werden, blockiert den Betrieb aber nicht heute. Fehlende Tests für zentrale Abläufe, veraltete Abhängigkeiten, schwer wartbare Kernbereiche.

Später: sinnvoll, aber ohne akuten wirtschaftlichen Nutzen. Eine Anwendung braucht keinen ästhetisch perfekten Code, bevor eine dringend benötigte Funktion umgesetzt werden darf.

Diese Einteilung ist der eigentliche Kern meiner Arbeit bei einer Übernahme. Sie verhindert, dass daraus ein unbegrenztes Aufräumprojekt wird, und sie gibt Ihnen eine Grundlage, um zu entscheiden, was Sie zuerst bezahlen wollen.

Muss eine fremde Codebasis neu entwickelt werden?

Meistens nicht. Und wer Ihnen im ersten Gespräch zum kompletten Rewrite rät, ohne das System zu kennen, empfiehlt vor allem sich selbst ein längeres Projekt.

Ein Neubau ist dann sinnvoll, wenn die bestehende Grundlage zentrale Anforderungen dauerhaft verhindert oder eine schrittweise Modernisierung wirtschaftlich nicht mehr vertretbar ist. Das kommt vor, ist aber die Ausnahme.

Der pragmatischere Weg sieht so aus:

1. Betrieb absichern.
2. Kritische Risiken beseitigen.
3. Tests für die wichtigsten Abläufe ergänzen.
4. Neue Funktionen kontrolliert entwickeln.
5. Problematische Bereiche nach und nach ersetzen. So entsteht früh wieder fachlicher Nutzen, und die technische Grundlage wird mit jeder Änderung belastbarer, statt zwölf Monate lang nur teurer.

Welche Dokumentation bei einer Übergabe wirklich hilft

Hunderte Seiten braucht niemand. Wertvoll sind die Informationen, die Entscheidungen und Abläufe erklären:

• Systemübersicht mit den wichtigsten Komponenten
• Anleitung für lokale Entwicklung und Deployment
• Beschreibung der Umgebungen und externen Dienste
• Datenmodell und die zentralen Geschäftsregeln
• bekannte Risiken und offene Entscheidungen
• Zuständigkeiten und notwendige Zugänge Dokumentation soll den nächsten Entwickler handlungsfähig machen. Sie muss keinen Literaturpreis gewinnen.

Woran Sie eine gelungene Übernahme erkennen

Nach der ersten Analyse sollten Sie keine unsortierte Mängelliste bekommen. Sie sollten Antworten bekommen:

• Ist der aktuelle Betrieb ausreichend abgesichert?
• Welche Risiken müssen zuerst gelöst werden?
• Lässt sich auf der bestehenden Architektur weiterentwickeln?
• Welche Zugänge oder Informationen fehlen noch?
• Wie sehen die nächsten sinnvollen Arbeitspakete aus?
• Mit welchem Aufwand ist ungefähr zu rechnen? Wenn Sie diese sechs Fragen beantworten können, ist aus einer fremden Codebasis wieder ein planbares Produkt geworden. Das ist der Punkt, an dem der unangenehme Teil vorbei ist.

Übernahme ist mehr als Code lesen

Eine gute Übergabe verbindet Software Engineering mit Kommunikation und Projektsteuerung. Es geht darum, Unklarheit systematisch abzubauen und Verantwortung wieder eindeutig zuzuordnen.

Das gilt für klassisch entwickelte Individualsoftware genauso wie für Anwendungen, die in kurzer Zeit mit KI-Unterstützung entstanden sind. Wie ich diese Entwicklung einordne, steht hier: Software bauen war noch nie so einfach. Gute Software bleibt schwierig. Wenn Ihre Anwendung auf Supabase läuft, finden Sie die technischen Prüfpunkte im Detail in der Supabase-Go-Live-Checkliste.

Sie wollen eine bestehende Anwendung übernehmen lassen oder vor der Weiterentwicklung einordnen? Schreiben Sie mir kurz über das Kontaktformular, worum es geht und was Sie an Zugängen bereits haben. Im Produktionscheck bekommen Sie eine priorisierte Einschätzung nach kritisch, wichtig und später. Wenn Sie danach eine vollständige Übernahme wollen, besprechen wir das direkt.