Lohnt sich das noch? Wie viel du in ein System steckst, das bald abgelöst wird

„Da machen wir nichts mehr dran, das wird eh abgelöst.“ Kennst du den Satz? Ich höre ihn in fast jedem größeren Vorhaben. Meistens fällt er in einem Meeting, alle nicken erleichtert, und das Thema ist vom Tisch.

Eine Situation, die ich in Projekten immer wieder erlebe: Ein altes System soll in absehbarer Zeit durch ein neues ersetzt werden. Offiziell ist es nur noch „Rückfallebene“, der Nachfolger ist für „Mitte nächsten Jahres“ angekündigt. Gleichzeitig kommt eine neue Anforderung rein, die das alte System eigentlich noch braucht. Und dann sitzen alle da und fragen sich: Lohnt sich das noch?

Gute Frage. Nur leider beantwortet sie meistens niemand. Man lässt sie einfach liegen. Und genau das ist das Problem.

Probleme

„Wird eh abgelöst“ ist keine Entscheidung

„Wird eh abgelöst“ klingt nach Plan. Ist es aber nicht. Es ist eine Hoffnung mit Datum. Was wirklich passiert: Niemand investiert mehr, aber niemand schaltet ab. Das System läuft einfach weiter. Ohne Budget, ohne Verantwortlichen, ohne Ziel.

Ich nenne das gerne den Zombie-Modus. Das System ist offiziell tot, läuft aber munter weiter und frisst nebenbei Zeit. Jeder Fehler wird mit spitzen Fingern angefasst, jede Anpassung ist ein Kampf um Budget („Dafür geben wir doch kein Geld mehr aus!“), und die Leute, die es betreiben, fühlen sich wie die Nachtwache auf einem sinkenden Schiff.

Ablösetermine sind optimistisch. Immer.

Jetzt denkst du vielleicht: „Na und? Ist doch nur für ein paar Monate.“ Nun, lass uns ehrlich sein. Wie oft hast du erlebt, dass ein Nachfolgesystem pünktlich zum geplanten Termin produktiv war? Und zwar so, dass das alte am nächsten Tag abgeschaltet werden konnte?

Eben.

Aus „Mitte nächsten Jahres“ wird gerne „Ende nächsten Jahres“. Und dann „nach dem nächsten großen Release“. Das ist keine böse Absicht, sondern der Normalfall bei großen Vorhaben. Wer seine Entscheidung über das Altsystem auf den geplanten Ablösetermin baut, baut auf Sand.

Am Altsystem hängt mehr, als du denkst

Das zweite Problem: Ein System, das lange läuft, hat Abnehmer. Viele. Manche kennst du, manche nicht. Da ist die offizielle Schnittstelle zum Nachbarsystem. Da ist der Export, den irgendeine Fachabteilung jeden Montag zieht. Und da ist das kleine Skript, das jemand vor sieben Jahren gebaut hat und das seitdem still vor sich hin läuft.

„Abschalten“ klingt deshalb einfacher, als es ist. Ich habe es schon erlebt, dass an einem angeblich „abgelösten“ System noch mehrere Webseiten und Apps mit enormen Abrufzahlen hingen. Das schaltest du nicht einfach ab. Das schaltest du nur ab, wenn jeder einzelne Abnehmer vorher umgezogen ist.

Das Wissen geht vor dem System

Und jetzt kommt das eigentlich gefährliche Problem. Die Leute, die das Altsystem wirklich verstehen, sind meistens wenige. Oft ein kleines Team, manchmal nur zwei, drei Personen. Und die merken sehr genau, wenn ihr System auf dem Abstellgleis steht.

Was machen gute Leute auf einem Abstellgleis? Richtig. Sie gehen. Entweder ins Projekt für das neue System (wo sie auch dringend gebraucht werden) oder gleich ganz woanders hin. Und dann hast du ein System, das noch zwei Jahre laufen muss, aber niemanden mehr, der es reparieren kann, wenn es am Sonntagmorgen um drei Uhr hakt.

Das muss man sich erstmal leisten können.

Die Organisation wechselt schneller als das System

Zu guter Letzt: In vielen Unternehmen ändern sich Zuständigkeiten heute schneller als Systemlandschaften. Bereiche werden zusammengelegt, Verantwortungen wandern, neue Leitungen kommen. Die Halbwertszeit eines Organigramms liegt gefühlt bei ein paar Monaten.

Für Altsysteme ist das Gift. Bei jeder Umorganisation stellt sich die Frage neu: Wem gehört das eigentlich noch? Und wenn die Antwort „Na ja, eigentlich niemandem“ lautet, sind wir wieder im Zombie-Modus.

Ich weiß, das waren jetzt viele Probleme für ein System, das „eh bald weg ist“. Aber genau darum geht es: Weil alle denken, es sei bald weg, kümmert sich keiner. Was also tun?

Lösungen

Wähle bewusst einen von drei Modi

Für ein System mit Ablaufdatum gibt es aus meiner Sicht genau drei sinnvolle Modi:

1. Weiter investieren: Das System bekommt noch neue Funktionen, weil es länger lebt, als allen lieb ist, oder weil die Funktion sich später ins neue System übertragen lässt.
2. Einfrieren: Keine neuen Funktionen mehr, aber Betrieb, Fehlerbehebung und Sicherheitsupdates sind sauber budgetiert und besetzt.
3. Gesteuert auslaufen: Es gibt einen Abschaltplan mit Terminen, und jeder Abnehmer weiß, bis wann er umgezogen sein muss.

Der vierte Modus, „Wir lassen es einfach mal laufen“, ist keiner. Schreib die Entscheidung auf, mit Namen der Person, die sie getroffen hat, und mit einem Datum, an dem ihr sie überprüft. Das klingt banal. Ist es auch. Aber ich habe es selten gesehen.

Rechne mit dem realistischen Ablösetermin

Statt mit dem geplanten Termin rechne mit einem realistischen. Meine Faustregel: geplante Restlaufzeit plus 50 % Puffer. Wenn der Nachfolger in 12 Monaten kommen soll, plane mit 18 Monaten.

Dann wird die Investitionsfrage plötzlich greifbar. Nehmen wir an, eine Anpassung am Altsystem kostet 40 Personentage.

• Lebt das System noch 6 Monate, kostet dich jeder Nutzungsmonat knapp 7 Personentage.
• Lebt es realistischerweise 18 Monate, sind es nur noch gut 2 Personentage pro Monat.

Das ist ein ganz anderes Gespräch. Und vergiss die andere Seite der Rechnung nicht: Jeder Monat, den das Altsystem länger läuft, kostet Betrieb, Lizenzen, Hosting und Leute, und im Parallelbetrieb zahlst du vieles doppelt. Auch das gehört auf den Tisch, wenn jemand sagt „Ist doch nur ein bisschen länger“.

Und wenn die Anpassung verhindert, dass in diesen 18 Monaten jeden Monat Handarbeit, Fehler oder genervte Kunden anfallen, rechnet sie sich vielleicht sogar ziemlich schnell.

Achtung: Das ist keine Einladung, ins Altsystem zu investieren, wie es dir gefällt. Es ist eine Einladung, ehrlich zu rechnen. Mehr dazu, wie du Problem und Lösung gegeneinander abwägst, findest du in Wie wertvoll ist das Problem vs. wie teuer ist die Lösung.

Investiere in die Brücke, nicht ins Altsystem

Oft gibt es einen klugen Mittelweg: Bau die neue Funktion nicht im Altsystem, sondern daneben. Eine Schnittstelle, ein kleiner Dienst, eine Übersetzungsschicht, die heute am alten System hängt und morgen am neuen. Dann zahlst du nur einmal und nimmst die Arbeit mit, wenn der Nachfolger kommt.

In der Softwarearchitektur heißt das übrigens „Strangler Fig Pattern“, nach der Würgefeige, die um einen alten Baum herumwächst, bis sie ihn nicht mehr braucht. Das ist nicht immer möglich, aber öfter, als man denkt. Die Frage „Können wir das so bauen, dass es den Umzug überlebt?“ sollte bei jeder Anforderung an ein Altsystem gestellt werden.

Mach eine Abnehmerliste

Bevor du irgendwas einfrierst oder abschaltest: Finde heraus, wer an dem System hängt. Eine einfache Liste reicht. Wer bezieht welche Daten, wie oft, über welchen Weg, und wer ist der Ansprechpartner?

Und verlass dich dabei nicht nur auf die Doku. Schau in die Zugriffsprotokolle: Wer ruft tatsächlich Daten ab? Da tauchen gerne Abnehmer auf, von denen niemand wusste. Manche Teams gehen noch einen Schritt weiter und schalten das System angekündigt für eine Stunde ab, um zu sehen, wo das Telefon klingelt. Das ist der sogenannte „Scream Test“. Wirksam, aber nur etwas für Systeme, bei denen eine Stunde Ausfall keinen echten Schaden anrichtet.

Klingt nach Fleißarbeit? Ist es auch. Aber eine Liste, die du jetzt machst, kostet dich ein paar Tage. Ein Abnehmer, den du erst nach dem Abschalten entdeckst, kostet dich Wochen und eine sehr unangenehme Eskalation.

Halte die Leute, die das Wissen haben

Das ist für mich der wichtigste Punkt. Wenn du das Altsystem noch 18 Monate brauchst, brauchst du auch die Menschen, die es verstehen, noch 18 Monate. Sag es ihnen. Ganz ausdrücklich. „Ihr seid nicht das Abstellgleis, ihr seid die Brücke. Ohne euch funktioniert der Umzug nicht.“

Und dann lass Taten folgen. Worte allein halten niemanden. Gib ihnen eine verbindliche Perspektive: Welche Rolle haben sie, wenn das Altsystem abgeschaltet ist? Wenn du kannst, verhandle auch handfeste Anreize fürs Bleiben bis zum Schluss. Bezieh sie ins Projekt für das Nachfolgesystem ein. Niemand kennt die Fallstricke des alten Systems besser, und genau die stecken in den Anforderungen an das neue. Wer das alte System kennt, ist für den Nachfolger keine Altlast, sondern ein Glücksfall.

Und Finger weg von „Wir sparen da jetzt eine Stelle ein, ist ja bald weg“. Ein kleines Team, das ein kritisches System betreibt, wird durch eine Person weniger nicht billiger, sondern langsamer und unruhiger. Spoiler: Meistens geht dann nicht nur eine Person.

Leg Abschaltkriterien fest, nicht nur ein Datum

Ein Abschaltdatum allein ist eine Absichtserklärung. Was du brauchst, sind Kriterien: Alle Abnehmer sind umgezogen. Das neue System läuft seit 4 Wochen stabil im Parallelbetrieb. Der Rückweg ist dokumentiert und geübt. Und bewährt hat sich eine Zwischenstufe: Das Altsystem läuft eine Weile nur noch lesend, bevor es endgültig abgeschaltet wird. Wer dann noch schreiben will, fällt auf, solange es noch nicht zu spät ist. Erst wenn diese Punkte erfüllt sind, wird abgeschaltet.

Das schützt dich in beide Richtungen. Vor einem zu frühen Abschalten, weil „der Termin halt steht“. Und vor dem ewigen Weiterlaufen, weil niemand weiß, wann man „eigentlich“ abschalten könnte. Wie sich der Lebenszyklus eines Produkts insgesamt anfühlt, habe ich übrigens in Produktlebenszyklus beschrieben. Das Ende gehört genauso dazu wie der Anfang.

Fazit

Ein System mit Ablaufdatum braucht keine Hoffnung, sondern eine Entscheidung: investieren, einfrieren oder gesteuert auslaufen lassen. Wer keine trifft, bekommt den Zombie-Modus gratis dazu.

Dein nächster Schritt: Nimm das Altsystem, über das bei dir am häufigsten „wird eh abgelöst“ gesagt wird. Stell in der nächsten Runde eine einzige Frage: „In welchem der drei Modi sind wir eigentlich, und wer hat das entschieden?“ Wenn danach Stille herrscht, weißt du, was zu tun ist.

Ich wünsche dir viel Erfolg bei der Umsetzung dieser Ideen! Wenn du Fragen hast oder wenn ich dich bei der Umsetzung unterstützen kann, sprich mich gerne an!