Ein bestehendes Softwareprojekt zu übernehmen ist anspruchsvoller als ein Neustart. Das System hat Nutzer, Daten, Abhängigkeiten und oft informelles Wissen, das in keinem Repository steht. Wer sofort Funktionen umbaut oder einen vollständigen Rewrite verspricht, erhöht zunächst das Risiko.
Eine gute Übernahme folgt einer anderen Reihenfolge: Zugriff herstellen, Betrieb verstehen, Risiken stabilisieren, dann gezielt modernisieren. Ziel ist nicht, den alten Code zu bewerten. Ziel ist, wieder verlässlich liefern und entscheiden zu können.
Woran Unternehmen merken, dass eine Übernahme nötig ist
Typische Auslöser sind:
- Der bisherige Entwickler oder Dienstleister steht nicht mehr ausreichend zur Verfügung.
- Releases sind selten, manuell oder mit hoher Unsicherheit verbunden.
- Kritische Teile des Systems versteht nur eine Person.
- Fehler werden behoben, kehren aber an anderer Stelle zurück.
- Neue Funktionen dauern unverhältnismäßig lange.
- Frameworks, Laufzeitumgebungen oder Abhängigkeiten blockieren notwendige Änderungen.
- Monitoring, Backups oder Wiederherstellungswege sind unklar.
Keiner dieser Punkte beweist automatisch, dass das System neu geschrieben werden muss. Sie zeigen, wo die Übernahme zuerst Klarheit schaffen sollte.
Phase 1: Handlungsfähigkeit herstellen
Bevor Architektur diskutiert wird, müssen die Grundlagen gesichert sein. Das neue Team braucht die Zugänge, mit denen Entwicklung und Betrieb tatsächlich funktionieren:
- Quellcode und Versionshistorie,
- Build- und Deployment-Systeme,
- Hosting-, Cloud- und Domainzugänge,
- Datenbanken, Backups und Wiederherstellungswege,
- Monitoring, Fehlerprotokolle und Alarmierung,
- Drittanbieter, API-Schlüssel und Lizenzverträge,
- Test- und Staging-Umgebungen,
- bekannte Ansprechpartner und bestehende Dokumentation.
Produktionszugänge werden dabei nicht wahllos verteilt. Rollen, Mehrfaktor-Authentifizierung, Protokollierung und ein nachvollziehbarer Freigabeweg gehören zur Übernahme. Fehlende Zugänge sind ein Projektrisiko und sollten als solches sichtbar sein.
Das erste Ergebnis ist eine Zugriffs- und Betriebslandkarte: Was existiert, wer kontrolliert es und was fehlt noch?
Phase 2: Ein technisches Lagebild erstellen
Eine Codeanalyse allein reicht nicht. Das Team betrachtet das System aus mehreren Perspektiven.
Produkt und Nutzer
Welche Abläufe sind geschäftskritisch? Welche Nutzergruppen sind betroffen? Welche Fehler wären nur lästig – und welche würden Umsatz, Betrieb oder Vertrauen gefährden?
Architektur und Daten
Wie sind Komponenten verbunden? Wo liegen Zustands- und Datenverantwortung? Welche Schnittstellen sind kritisch? Gibt es Migrationen, Hintergrundprozesse oder manuelle Eingriffe, die für den Betrieb unverzichtbar sind?
Delivery und Qualität
Lässt sich das Projekt reproduzierbar bauen? Welche Tests laufen wirklich? Wie gelangt eine Änderung von der lokalen Entwicklung nach Staging und Produktion? Wie schnell kann ein fehlerhaftes Release zurückgenommen werden?
Betrieb und Sicherheit
Welche Fehler treten wiederholt auf? Sind Backups nicht nur vorhanden, sondern wiederherstellbar? Welche Abhängigkeiten sind veraltet? Wo liegen Geheimnisse und persönliche Konten? Welche Alarmierungen führen zu einer klaren menschlichen Aktion?
Das Ergebnis ist kein 80-seitiges Audit. Es ist eine priorisierte Liste aus Stabilitätsrisiken, Wissenslücken und Modernisierungsmöglichkeiten – jeweils mit Auswirkung und nächstem Schritt.
Phase 3: Stabilisieren, bevor modernisiert wird
Modernisierung ist leichter, wenn Releases berechenbar sind. Deshalb kommen häufig zuerst unspektakuläre Maßnahmen:
- einen reproduzierbaren Build herstellen,
- eine belastbare Staging-Umgebung schaffen,
- kritische Nutzerwege mit Tests absichern,
- Fehler- und Betriebsdaten sichtbar machen,
- Backups und Wiederherstellung prüfen,
- Deployment und Rollback dokumentieren,
- dringende Sicherheits- oder Abhängigkeitsrisiken begrenzen.
Diese Arbeit erzeugt vielleicht noch keine neue Funktion. Sie senkt aber das Risiko jeder folgenden Änderung. Der Fortschritt sollte trotzdem sichtbar sein: durch demonstrierte Deployments, getestete Wiederherstellung, messbare Fehlerreduktion oder einen dokumentierten Release-Weg.
Phase 4: Den Modernisierungspfad wählen
Erst mit einem belastbaren Lagebild lässt sich entscheiden, wie viel Veränderung sinnvoll ist.
Schrittweise Modernisierung
Die meisten Systeme profitieren von gezielten Eingriffen: einzelne Komponenten ersetzen, Schnittstellen stabilisieren, Tests ergänzen, Datenzugriffe entkoppeln oder ein veraltetes Frontend schrittweise erneuern. Das System bleibt nutzbar und jede Änderung kann separat bewertet werden.
Abgrenzung eines neuen Moduls
Wenn ein Bereich stark bremst, kann ein neues Modul neben dem bestehenden System entstehen. Eine klare Schnittstelle begrenzt die Abhängigkeit vom alten Code. Entscheidend ist, dass Datenhoheit und Übergangsprozess explizit geregelt sind.
Vollständiger Rewrite
Ein Rewrite ist nur dann belastbar, wenn der geschäftliche Nutzen die Übergangsrisiken rechtfertigt und der alte Funktionsumfang verstanden ist. Häufig unterschätzen Teams versteckte Regeln, Sonderfälle und Datenmigration. Ein Rewrite braucht deshalb einen stufenweisen Ablöseplan, nicht nur eine neue technische Zielarchitektur.
Die ersten 30 Tage sinnvoll strukturieren
Ein realistischer Einstieg kann so aussehen:
Woche 1: Zugänge und kritische Abläufe
Repository, Umgebungen, Betrieb und Verantwortlichkeiten werden erfasst. Das Team identifiziert die wichtigsten Nutzerwege und akuten Risiken.
Woche 2: Reproduzierbarkeit
Build, lokale Entwicklung, Staging und zentrale Tests werden nachvollzogen. Fehlende Schritte werden dokumentiert oder automatisiert.
Woche 3: Erste Stabilisierung
Das Team bearbeitet ein begrenztes Risiko mit sichtbarem Ergebnis – etwa einen unsicheren Deployment-Schritt, einen wiederkehrenden Fehler oder einen kritischen ungetesteten Ablauf.
Woche 4: Modernisierungsentscheidung
Auf Basis der gewonnenen Evidenz werden die nächsten Arbeitspakete priorisiert. Der Kunde sieht, was stabil ist, was gefährlich bleibt und welche Investition welchen Nutzen verspricht.
Der genaue Ablauf hängt vom System ab. Wichtig ist der Takt: Jede Woche sollte die Unsicherheit sinken und die Handlungsfähigkeit steigen.
Wie Loopjet die Übernahme organisiert
Deutsche Lead Engineers führen technische Bestandsaufnahme, Architekturentscheidungen und Projektkommunikation. Das eingespielte Team in Malaysia setzt Stabilisierung und Modernisierung in klaren Paketen um. Code-Reviews, Tests und kurze Demonstrationszyklen gehören zur Delivery.
Der bisherige Dienstleister oder interne Entwickler wird – wenn möglich – strukturiert einbezogen. Gute Übergabe ist keine Schuldzuweisung. Sie sichert Wissen, das sonst teuer neu entdeckt werden müsste.
Was Sie für eine erste Einschätzung brauchen
Für das erste Gespräch genügen:
- Zweck und Nutzer des Systems,
- aktuelle technische Umgebung, soweit bekannt,
- der konkrete Anlass für die Übernahme,
- die größten bekannten Betriebs- oder Delivery-Probleme,
- verfügbare Zugänge und Ansprechpartner,
- äußere Termine oder Risiken.
Ein vollständiger Repository-Zugriff ist für die erste Einordnung nicht erforderlich. Sensible Daten sollten erst in einem geregelten Prüfprozess geteilt werden.
Das richtige Ergebnis der Übernahme
Eine erfolgreiche Übernahme endet nicht mit „Das neue Team kennt den Code“. Sie ist erreicht, wenn:
- Änderungen reproduzierbar entwickelt und ausgeliefert werden können,
- kritische Risiken bekannt und priorisiert sind,
- Betrieb und Zuständigkeiten nachvollziehbar geregelt sind,
- Wissen nicht mehr an einer einzelnen Person hängt,
- das nächste Modernisierungspaket fachlich und technisch begründet ist.
Dann ist das System wieder steuerbar. Erst jetzt lässt sich verantwortungsvoll entscheiden, was erhalten, ersetzt oder neu gebaut wird.
Beschreiben Sie kurz das System und den Anlass für die Übernahme.