Ein Legacy-System übernehmen — die ersten 90 Tage

Es gibt einen Moment in der Modernisierung, der mehr Angst auslöst als jeder andere: den Tag, an dem man die Verantwortung für ein System übernimmt, das man nicht gebaut hat und noch nicht versteht. Ab diesem Tag hängt an diesem System ein Geschäft, das läuft — und jeder Eingriff, jede Unachtsamkeit kann es stören, obwohl man noch nicht weiß, wie es funktioniert. Wer hier falsch beginnt, verspielt in wenigen Tagen das Vertrauen, das eine Modernisierung über Monate braucht.

Dieses Dokument behandelt diese erste Phase — die man oft die ersten neunzig Tage nennt — als eigenständige Disziplin. Sie ist nicht die Modernisierung selbst; sie ist das, was davor kommt: das System verstehen, sicher machen und beherrschbar, bevor man es verändert. Es ist framework-neutral gehalten, weil die Haltung von keiner Technologie abhängt. Wie man danach modernisiert, behandeln eigene Texte; hier geht es um den Anfang, an dem sich entscheidet, ob alles Weitere gelingen kann.

1. Warum die Übernahme der gefährlichste Moment ist

Die Übernahme ist gefährlich, weil zwei Dinge auseinanderfallen, die sonst zusammengehören: die Verantwortung und das Verständnis. Von der ersten Stunde an ist man verantwortlich für das, was das System tut — aber das Verständnis, das man bräuchte, um diese Verantwortung sicher zu tragen, hat man noch nicht. Man besitzt ein Haus, dessen Leitungen man nicht kennt, und es ist bewohnt. Jeder Handgriff kann etwas auslösen, das man nicht vorhergesehen hat, weil man die Verbindungen nicht kennt.

Die erste Phase hat deshalb eine klare innere Ordnung — vier Bewegungen, die aufeinander aufbauen:

Diese Lücke zwischen Verantwortung und Verständnis ist die eigentliche Gefahr der ersten Phase — und der Grund, warum sie eine eigene Disziplin verdient. Wer sie ignoriert und sofort zu arbeiten beginnt, als hätte er das System gebaut, handelt auf Annahmen, die niemand geprüft hat. Die Kunst der Übernahme ist, diese Lücke bewusst zu schließen, bevor man sie durch Eingriffe auf die Probe stellt. Man verdient sich das Recht zu ändern, indem man erst versteht.

Schema: Die Verantwortung ist vom ersten Tag an voll, das Verständnis wächst erst. Die Fläche dazwischen ist die Gefahrenzone — die erste Phase dient dazu, sie zu schließen.

Trade-off. Die Übernahme als eigene Phase zu behandeln bedeutet, mit dem sichtbaren Verändern zu warten — das fühlt sich nach fehlendem Fortschritt an, ist aber die Voraussetzung, überhaupt sicher voranzugehen.

Kosten. Die erste Phase liefert kein neues Feature; sie kostet Zeit, die nach außen wie Stillstand aussieht, und verlangt Geduld von allen, die schnelle Ergebnisse erwarten.

Wann wir anders entscheiden. Bei einem kleinen, gut dokumentierten System, das man in Tagen vollständig überblickt, darf die Phase kurz sein; ihre Länge wächst mit der Größe, dem Alter und der Undurchsichtigkeit des Systems.

2. Zuerst verstehen, nicht ändern

Der stärkste Instinkt bei der Übernahme ist zugleich der gefährlichste: sofort zu verbessern, was einem auffällt. Man sieht unordentlichen Code, eine fragwürdige Entscheidung, etwas, das man anders gemacht hätte — und die Hand zuckt zur Korrektur. Diesem Instinkt zu widerstehen ist die erste Disziplin der Übernahme. Denn was wie ein Fehler aussieht, ist in einem gewachsenen System oft eine Lösung für ein Problem, das man noch nicht kennt. Wer ändert, bevor er versteht, entfernt womöglich genau die Vorkehrung, die einen stillen Ausfall verhindert hat.

Die Haltung lautet deshalb: erst verstehen, dann ändern. In der ersten Phase ist das Verstehen die eigentliche Arbeit, nicht das Verbessern. Man liest, man beobachtet, man fragt — man baut sich ein Bild davon, was das System tut und warum es so ist, wie es ist. Jede Auffälligkeit wird notiert, nicht sofort behoben; die Liste der Fragen ist wertvoller als die Liste der schnellen Korrekturen. Das Recht, ein System zu ändern, verdient man sich durch das Verständnis, das die Änderung sicher macht.

Trade-off. Nicht sofort zu verbessern bedeutet, sichtbare Unschönheiten stehen zu lassen und die Ungeduld auszuhalten, etwas Offensichtliches nicht anzufassen.

Kosten. Man trägt eine Zeit lang die Mängel eines Systems, die man erkannt hat, ohne sie zu beheben — das verlangt Disziplin und die Bereitschaft, unfertig auszusehen.

Wann wir anders entscheiden. Wo eine Auffälligkeit ein akutes, verstandenes Risiko ist — eine offene Sicherheitslücke, ein drohender Datenverlust —, wartet man nicht; die Zurückhaltung gilt dem, was man noch nicht versteht, nicht dem, was klar gefährlich ist.

3. Sicherheitsnetze vor Eingriffen

Bevor man ein übernommenes System zum ersten Mal ernsthaft anfasst, spannt man Netze auf, die einen Fehler auffangen. Das Wichtigste ist die Fähigkeit, zurückzukönnen: geprüfte Sicherungen, von denen man weiß, dass man sie im Ernstfall wirklich zurückspielen kann — nicht solche, die es dem Namen nach gibt, aber nie erprobt wurden. Das Zweite ist die Fähigkeit, zu sehen: genug Beobachtbarkeit, um zu erkennen, wie sich das System verhält und ob ein Eingriff etwas gestört hat. Ein System, das man nicht zurücksetzen und nicht beobachten kann, darf man nicht verändern — man würde blind an etwas Unumkehrbarem arbeiten.

Diese Netze herzustellen ist oft die erste konkrete Arbeit an einem übernommenen System, und sie ist wertvoll, noch bevor man irgendetwas ändert: Sie macht das System beherrschbar. Wer weiß, dass er einen Fehler bemerken und rückgängig machen kann, arbeitet ruhig und sicher; wer es nicht weiß, arbeitet in Angst oder gar nicht. Die Sicherheitsnetze sind damit nicht Vorbereitung im Sinne von Aufschub, sondern die erste echte Verbesserung — sie erhöhen die Sicherheit des Systems, ohne seine Funktion anzutasten.

Trade-off. Erst Netze zu spannen bedeutet, vor dem ersten Eingriff Arbeit zu investieren, die nichts an der Funktion ändert — Aufwand, der sich erst im vermiedenen Schaden auszahlt.

Kosten. Geprüfte Sicherungen und ausreichende Beobachtbarkeit herzustellen kann in einem vernachlässigten System selbst mühsam sein und die eigentliche Arbeit hinauszögern.

Wann wir anders entscheiden. Wo ein System bereits verlässliche Sicherungen und gute Beobachtbarkeit mitbringt, überspringt man diesen Aufbau und prüft nur, dass die Netze wirklich tragen; fehlen sie, ist ihr Aufbau nicht verhandelbar.

4. Die Karte des Systems

Ein übernommenes System ist zunächst ein weißer Fleck, und die erste Phase dient dazu, ihn zu einer Karte zu machen. Diese Karte beantwortet einfache, aber entscheidende Fragen: Woraus besteht das System, welche Teile hängen voneinander ab, wovon hängt es außen ab, wo liegen die Daten, welche Wege nehmen die wichtigsten Vorgänge? Man zeichnet nicht jedes Detail, sondern die tragenden Linien — genug, um zu wissen, was man anfasst, wenn man etwas anfasst, und was mitschwingt, wenn man an einer Stelle zieht.

Die reichste Quelle für die Karte sind oft die Menschen, die das System bisher betrieben oder benutzt haben. Wer es gebaut hat, kennt die Gründe hinter den Eigenheiten; wer es bedient, kennt die Stellen, an denen es klemmt. Diese Gespräche führen schneller zu den vergessenen Rändern als die Analyse des Codes allein — vorausgesetzt, man fragt früh, solange das Wissen noch erreichbar ist. Mit jeder Woche nach der Übergabe verblasst das Gedächtnis der Beteiligten, und die Karte, die man heute leicht bekäme, muss man morgen mühsam aus dem System selbst rekonstruieren.

Besondere Aufmerksamkeit gilt den Rändern und den Abhängigkeiten, die niemand mehr im Kopf hat: der selten genutzte Dienst, die stille Verbindung nach außen, der Vorgang, der nur einmal im Monat läuft. Genau diese vergessenen Teile richten bei einem Eingriff den größten Schaden an, weil niemand mit ihnen rechnet. Die Karte macht sie sichtbar, solange man noch nichts verändert. Sie ist kein Dokument um seiner selbst willen, sondern das Werkzeug, mit dem man aus einem unbekannten System ein beherrschbares macht.

Trade-off. Die Karte zu zeichnen kostet Zeit im Verstehen, die man lieber ins Bauen stecken würde — gegen den Gewinn, nicht ins Unbekannte zu greifen.

Kosten. In einem großen, undurchsichtigen System ist das Kartieren mühsam und nie ganz vollständig; man muss mit einer Karte arbeiten, die Lücken hat, und diese Lücken kennen.

Wann wir anders entscheiden. Bei einem kleinen System, das ein Mensch vollständig überblickt, genügt eine grobe Skizze; die aufwändige Karte lohnt sich mit der Größe und der Zahl der vergessenen Ecken.

5. Charakterisierung statt Annahme

Bevor man das Verhalten eines Systems ändert, muss man wissen, wie es sich heute verhält — und zwar belegt, nicht vermutet. In einem fremden System ist das momentane Verhalten die einzige verlässliche Wahrheit: Es ist das, worauf sich das Geschäft eingestellt hat, mitsamt seinen Eigenheiten und selbst seinen kleinen Fehlern. Charakterisierung heißt, dieses Verhalten festzuhalten, bevor man es anfasst — als Bezugspunkt, gegen den man jede spätere Änderung prüfen kann. Man beschreibt nicht, wie das System sein sollte, sondern wie es ist.

Der Wert dieser Haltung liegt darin, dass sie Änderungen sicher macht. Wenn das heutige Verhalten festgehalten ist, sieht man sofort, ob ein Eingriff etwas verschoben hat, das man nicht verschieben wollte — auch eine Eigenheit, von der man nicht wusste, dass jemand sich auf sie verlässt. Ohne diesen Bezugspunkt ändert man auf gut Glück und erfährt von einer unbeabsichtigten Nebenwirkung erst, wenn ein Nutzer sie meldet. Charakterisierung verwandelt Annahmen über das System in belegtes Wissen — die Grundlage jeder verantwortlichen Änderung.

Trade-off. Das heutige Verhalten festzuhalten kostet Arbeit an etwas, das man ohnehin ändern will — gegen den Gewinn, jede Änderung gegen einen sicheren Bezugspunkt prüfen zu können.

Kosten. Charakterisierung verlangt, auch die Eigenheiten und kleinen Fehler des Systems zu erfassen, nicht nur sein Idealverhalten — mehr Mühe, als das Offensichtliche zu beschreiben.

Wann wir anders entscheiden. Für einen Teil, den man ohnehin vollständig ersetzt und dessen altes Verhalten niemand erhalten will, spart man sich die Charakterisierung; sie gilt dem, was bleibt und dessen Verhalten stabil bleiben muss.

6. Die ersten sicheren Änderungen

Wenn die Netze gespannt, die Karte gezeichnet und das Verhalten festgehalten sind, beginnt man zu ändern — aber klein und umkehrbar. Die ersten Eingriffe sind bewusst niedrigriskant: eine Verbesserung, deren Wirkung man vollständig überblickt, an einer Stelle, die man versteht, mit einem klaren Weg zurück. Man sucht nicht die größte Wirkung, sondern den sichersten Beweis, dass man das System beherrscht — dass man ändern kann, ohne etwas zu brechen. Jeder gelungene kleine Eingriff vergrößert das Verständnis und das Vertrauen; jeder misslungene wäre, klein gehalten, billig zu korrigieren.

Schema: Die erste sichere Änderung kommt zuletzt, nicht zuerst — sie ruht auf allem davor und beweist, dass es trägt.

Diese ersten Änderungen haben eine doppelte Aufgabe. Nach außen zeigen sie, dass die Übernahme vorangeht und das System in guten Händen ist — sie stellen das Vertrauen her, das die eigentliche Modernisierung braucht. Nach innen sind sie die Probe darauf, ob die Vorarbeit trägt: ob die Netze halten, die Karte stimmt, das festgehaltene Verhalten den Bezugspunkt liefert. Erst wenn diese kleinen, sicheren Eingriffe verlässlich gelingen, ist die Übernahme abgeschlossen und die Modernisierung kann beginnen. Man geht vom Verstehen ins Verändern über, nicht mit einem Sprung, sondern mit einem tastenden, umkehrbaren ersten Schritt.

Trade-off. Klein und sicher zu beginnen bedeutet, auf die große, sichtbare erste Wirkung zu verzichten — gegen den Gewinn, das Beherrschen zu beweisen, bevor man etwas Großes wagt.

Kosten. Die ersten Änderungen liefern wenig sichtbaren Fortschritt für den Aufwand; ihr Wert liegt im bewiesenen Beherrschen, nicht im Ergebnis selbst.

Wann wir anders entscheiden. Wo ein akutes Problem drängt und verstanden ist, darf der erste Eingriff größer sein; die Zurückhaltung gilt dem Normalfall, in dem man das Beherrschen erst beweisen muss.

7. Was man in den ersten neunzig Tagen nicht tut

So wichtig wie das, was man tut, ist das, was man in dieser Phase bewusst unterlässt. Man beginnt keinen großen Umbau und keinen Neubau, solange man das System nicht versteht — die Versuchung ist groß, gerade weil das Alte unangenehm ist, aber ein Neubau auf Basis von Unverständnis wiederholt nur die Fehler, deren Grund man nicht kennt. Man strukturiert nicht vorschnell um, was man für unordentlich hält, weil die Ordnung, die man vermisst, oft einem Zweck dient, den man noch nicht sieht. Und man verspricht nach außen keine schnellen, großen Ergebnisse, die nur durch riskante Eingriffe zu haben wären.

Diese Zurückhaltung ist keine Passivität, sondern eine Entscheidung. Die erste Phase hat ein klares Ziel — das System zu verstehen, sicher zu machen und beherrschbar —, und alles, was diesem Ziel nicht dient oder es gefährdet, gehört nicht hinein. Der große Umbau kommt, aber später, aus Verständnis heraus und in umkehrbaren Schritten, wie es die Modernisierung ohne Big Bang beschreibt. Wer in den ersten neunzig Tagen der Versuchung zum großen Wurf widersteht, legt das Fundament, auf dem der große Wurf überhaupt gelingen kann.

Trade-off. Auf den großen Wurf zu verzichten bedeutet, kurzfristig weniger zu beeindrucken — gegen den Gewinn, das Risiko zu vermeiden, das die meisten Übernahmen scheitern lässt.

Kosten. Man muss die Erwartung großer, schneller Ergebnisse aktiv dämpfen und die Geduld derer aushalten, die das übernommene System sofort verwandelt sehen wollen.

Wann wir anders entscheiden. Wo das System akut versagt und ein Weiterbetrieb unverantwortlich wäre, verschiebt sich die Abwägung; dann handelt man früher, aber so umkehrbar wie eben möglich.

8. Typische Fehler

Die wiederkehrenden Muster, an denen Übernahmen scheitern — fast alle sind Varianten davon, zu ändern, bevor man versteht:

• Sofort verbessern, was auffällt, und dabei eine Vorkehrung entfernen, deren Zweck man nicht kannte.
• Verantwortung übernehmen und handeln, als hätte man das System gebaut, statt die Lücke im Verständnis zu schließen.
• Ändern, bevor geprüfte Sicherungen und ausreichende Beobachtbarkeit stehen — blind an etwas Unumkehrbarem arbeiten.
• Die vergessenen Ränder übersehen — den seltenen Dienst, die stille Außenverbindung —, die beim Eingriff den größten Schaden anrichten.
• Auf Annahmen über das Verhalten handeln, statt das heutige Verhalten belegt festzuhalten.
• Mit einem großen, sichtbaren Eingriff beginnen, statt das Beherrschen erst an kleinen, umkehrbaren zu beweisen.
• Vorschnell umstrukturieren, was unordentlich aussieht, aber einem noch unbekannten Zweck dient.
• Nach außen schnelle, große Ergebnisse versprechen, die nur durch riskante Eingriffe zu haben wären.

9. Entscheidungs-Checkliste

Für die erste Phase der Übernahme der Reihe nach zu klären:

• Verständnis vor Änderung? Ist das Verstehen die erklärte Hauptarbeit der ersten Phase — nicht das Verbessern?
• Zurückkönnen? Gibt es geprüfte Sicherungen, von denen man weiß, dass man sie wirklich zurückspielen kann?
• Sehen können? Reicht die Beobachtbarkeit, um zu erkennen, wie sich das System verhält und ob ein Eingriff es gestört hat?
• Karte? Sind die tragenden Teile, die Abhängigkeiten und besonders die vergessenen Ränder sichtbar gemacht?
• Verhalten festgehalten? Ist das heutige Verhalten belegt, als Bezugspunkt für jede Änderung?
• Klein und umkehrbar begonnen? Beweisen die ersten Eingriffe das Beherrschen, statt die größte Wirkung zu suchen?
• Bewusst unterlassen? Ist der große Umbau, das vorschnelle Umstrukturieren und das Versprechen schneller Ergebnisse aufgeschoben?
• Vertrauen aufgebaut? Zeigen die ersten sicheren Änderungen nach außen, dass das System in guten Händen ist?

Wer diese Fragen beantworten kann, hat ein fremdes System übernommen, ohne es zu gefährden — und das Fundament gelegt, auf dem die Modernisierung gelingen kann.

FAQ

Warum nicht sofort die offensichtlichen Mängel beheben? Weil in einem gewachsenen System vieles, was wie ein Fehler aussieht, eine Lösung für ein Problem ist, das man noch nicht kennt. Wer ändert, bevor er versteht, entfernt womöglich genau die Vorkehrung, die einen stillen Ausfall verhindert hat. Man notiert die Auffälligkeiten und behebt sie, sobald man ihren Zusammenhang versteht — nicht vorher.

Was ist das Erste, das man an einem übernommenen System tut? Die Sicherheitsnetze herstellen: geprüfte Sicherungen, von denen man weiß, dass man sie zurückspielen kann, und genug Beobachtbarkeit, um zu sehen, wie sich das System verhält. Ein System, das man nicht zurücksetzen und nicht beobachten kann, darf man nicht verändern. Diese Netze machen das System beherrschbar, noch bevor man etwas ändert.

Was bedeutet Charakterisierung? Das heutige Verhalten des Systems belegt festzuhalten, bevor man es ändert — als Bezugspunkt. In einem fremden System ist das momentane Verhalten die einzige verlässliche Wahrheit, mitsamt seinen Eigenheiten. Ist es festgehalten, sieht man sofort, ob ein Eingriff etwas verschoben hat, das niemand verschieben wollte — statt es erst vom Nutzer zu erfahren.

Warum kein großer Umbau in den ersten neunzig Tagen? Weil ein Neubau oder Umbau auf Basis von Unverständnis nur die Fehler wiederholt, deren Grund man nicht kennt. Die erste Phase dient dem Verstehen und der Sicherheit; der große Wurf kommt später, aus Verständnis heraus und in umkehrbaren Schritten. Wer der Versuchung zum großen Wurf widersteht, legt das Fundament, auf dem er überhaupt gelingen kann.

Woran erkennt man, dass die Übernahme abgeschlossen ist? Daran, dass kleine, umkehrbare Änderungen verlässlich gelingen — dass man ändern kann, ohne etwas zu brechen. Das ist der Beweis, dass die Netze halten, die Karte stimmt und das festgehaltene Verhalten den Bezugspunkt liefert. Erst dann geht die Übernahme in die eigentliche Modernisierung über.

Wie lange dauert diese Phase wirklich? Die neunzig Tage sind ein Bild, kein festes Maß. Die Phase dauert so lange, bis die Lücke zwischen Verantwortung und Verständnis geschlossen ist — bei einem kleinen, dokumentierten System kürzer, bei einem großen, undurchsichtigen länger. Sie endet nicht nach einer Frist, sondern wenn man das System beherrscht.

Weiterführend

• Legacy-Modernisierung ohne Big Bang — was nach der Übernahme kommt: modernisieren in kleinen, umkehrbaren Schritten.
• Einen Legacy-Monolithen modernisieren — das Playbook für die Modernisierung selbst.
• Observability ist Architektur — warum man ohne Sehen nicht sicher eingreifen kann.
• Reversibilität vor Vorhersage — warum die ersten Eingriffe klein und umkehrbar sein müssen.

Grundlage ist die Batunet Engineering Method: erst verstehen, dann ändern; für den Fehlerfall entwerfen; in kleinen, umkehrbaren Schritten vorgehen.

Abschließendes Engineering-Prinzip

Man übernimmt ein fremdes System nicht, indem man es sofort zu seinem eigenen macht, sondern indem man sich das Recht verdient, es zu ändern — durch Verstehen, durch Sicherheit, durch bewiesenes Beherrschen. Die erste Phase liefert kein Feature und keinen großen Wurf; sie liefert etwas Wertvolleres: ein System, das man ändern kann, ohne es zu gefährden. Der häufigste Grund, warum Modernisierungen scheitern, ist nicht die Modernisierung selbst, sondern eine Übernahme, die zu schnell zu viel wollte. Wer die ersten Wochen der Geduld widmet, verliert keine Zeit — er kauft die Sicherheit, die alles Weitere erst möglich macht.

Ein übernommenes System gehört einem erst wirklich, wenn man es versteht. Bis dahin verwaltet man das Werk eines anderen — und die einzige Kunst ist, es nicht zu beschädigen, während man lernt.