Gewachsene Software hat oft einen schlechten Ruf. Sie gilt als alt, kompliziert, schlecht dokumentiert und schwer veränderbar. In vielen Unternehmen ist sie aber gleichzeitig eines der wertvollsten Systeme: Sie enthält Fachwissen, Daten, Sonderfälle, Kundenlogik und jahrelange Entscheidungen.
Deshalb ist der Reflex „Wir bauen alles neu“ gefährlich. Ein Neubau klingt sauber, planbar und befreiend. In der Praxis unterschätzt man dabei fast immer, wie viel implizites Wissen im bestehenden System steckt. Funktionen, die wie technische Altlasten aussehen, sind oft Antworten auf echte Sonderfälle. Datenstrukturen, die niemand schön findet, enthalten gewachsene Geschäftsregeln. Kleine Workarounds bilden manchmal genau die Abläufe ab, auf die Mitarbeiter oder Kunden angewiesen sind.
Eine gute Übernahme beginnt deshalb nicht mit Neuschreiben, sondern mit Verstehen.
Erst verstehen, dann verändern
Bei einer Software-Übernahme geht es zuerst um Orientierung. Welche Teile des Systems sind kritisch? Welche Daten sind unersetzlich? Welche Schnittstellen hängen daran? Wie wird deployed? Wer nutzt welche Funktion? Welche Fehler sind bekannt? Welche Arbeiten sind riskant?
Diese Fragen wirken unspektakulär, sparen aber später viel Geld. Wer zu früh umbaut, verschiebt oft nur die Unsicherheit. Wer zuerst versteht, kann gezielt entscheiden: Was bleibt? Was wird stabilisiert? Was wird ersetzt? Was kann weg?
Die ersten Wochen entscheiden
In den ersten Wochen einer Übernahme sollte nicht möglichst viel Featurearbeit passieren. Wichtiger sind belastbare Grundlagen:
- lokale Entwicklungsumgebung herstellen
- Zugänge und Verantwortlichkeiten klären
- Backup- und Recovery-Situation prüfen
- Deployment nachvollziehbar machen
- kritische Abhängigkeiten erfassen
- Monitoring und Fehlermeldungen sichtbar machen
- erste Tests für zentrale Abläufe ergänzen
- die wichtigsten Fachbegriffe dokumentieren
Das Ergebnis ist noch kein sichtbarer Relaunch. Aber es ist der Unterschied zwischen Arbeiten im Nebel und Arbeiten mit Karte.
Tests dort nachziehen, wo Risiko liegt
Bei gewachsenen Systemen fehlen oft Tests. Trotzdem muss man nicht sofort eine perfekte Testabdeckung herstellen. Sinnvoller ist ein risikobasiertes Vorgehen.
Tests sollten zuerst dort entstehen, wo Fehler teuer sind: Zahlungsflüsse, Datenimporte, Rechte, Veröffentlichungen, Schnittstellen, zentrale Berechnungen, kritische Nutzeraktionen. Gute Tests schaffen Bewegungsfreiheit. Sie machen es möglich, technische Schulden schrittweise abzubauen, ohne jedes Mal Angst vor Seiteneffekten zu haben.
Dokumentation als Arbeitsmittel
Dokumentation ist bei Übernahmen kein Selbstzweck. Niemand braucht ein hundertseitiges Dokument, das nach zwei Monaten veraltet ist. Nützlich sind kurze, lebendige Informationen:
- Wie startet man das Projekt lokal?
- Wie wird deployed?
- Welche Systeme hängen zusammen?
- Welche Jobs, Cronjobs oder Queues gibt es?
- Welche Datenmodelle sind fachlich wichtig?
- Wo liegen bekannte Risiken?
- Welche Entscheidungen wurden getroffen und warum?
Diese Dokumentation sollte während der Arbeit entstehen, nicht danach.
Neubau nur mit gutem Grund
Natürlich kann ein Neubau sinnvoll sein. Manche Systeme sind technisch, fachlich oder wirtschaftlich am Ende. Aber auch dann sollte der Neubau nicht aus Frust entstehen, sondern aus einer klaren Entscheidung.
Gute Gründe für einen Neubau können sein: falsche Grundarchitektur, nicht mehr wartbare Technologie, fehlende Sicherheitsbasis, massive Performance-Grenzen oder ein fachlich verändertes Geschäftsmodell. Selbst dann ist häufig ein schrittweiser Übergang besser als der große Schnitt.
Die bessere Frage
Die Frage lautet nicht: „Alt oder neu?“
Die bessere Frage lautet: „Welche Veränderung reduziert Risiko und erhöht Handlungsfähigkeit am schnellsten?“
Manchmal ist das ein Test. Manchmal ein Deployment-Fix. Manchmal eine Datenmigration. Manchmal die Ablösung eines Moduls. Manchmal ein Neubau. Aber die Antwort sollte aus dem System, dem Ziel und dem Risiko entstehen - nicht aus Reflex.
Fazit
Legacy-Software ist nicht automatisch ein Problem. Problematisch wird sie, wenn niemand sie versteht, niemand sie sicher verändern kann und niemand Verantwortung übernimmt.
Eine gute Übernahme macht ein bestehendes System wieder arbeitsfähig: verständlicher, stabiler, testbarer und entwickelbarer. Genau darin liegt oft der größte Wert.