Die Entscheidung steht oft schon im Raum
Die meisten Investitionsvorlagen, die wir zu dieser Lage sehen, enthalten bereits eine Richtung. Ein Dienstleister hat einen Neubau angeboten. Ein Team will den Altcode hinter sich lassen. Der Betrieb sagt, das System laufe doch. Das sind Positionen. Eine Entscheidung ist das noch nicht.
Neu bauen, ablösen und weiterbetreiben sind keine Stufen einer Reifeleiter. Es sind drei Wetten: auf eine neue Spezifikation, auf ein fremdes Produkt oder auf die Tragfähigkeit dessen, was schon da ist. Wer sie vermischt, ohne die Mischung zu benennen — parallel neu bauen, nebenbei Standardsoftware einführen, den Altbestand „noch eine Weile“ mitziehen —, trägt das Risiko aller drei Wege und den Nutzen keines.
Das schrittweise Ablösen eines Kerns, oft als Strangler-Fig-Muster beschrieben, ist ein Umsetzungsweg nach der Entscheidung, nicht die Entscheidung selbst. Dafür braucht es einen eigenen Text.
Drei Optionen, drei Wetten
Neu bauen
Neu bauen heißt: dasselbe fachliche Problem noch einmal spezifizieren und in einer neuen Codebasis lösen. Der Altbestand wird zur Übergangsquelle, nicht zum Fundament.
Das trägt, wenn sich die Fachlichkeit selbst verschoben hat — nicht nur die Oberfläche. Ein Vorgang, der früher ein Dokument erzeugte und heute Kontingente, Verfügbarkeiten und Freigaben in einem Schritt hält, lässt sich in einem System, das Dokumente denkt, oft nicht mehr ausdrücken. Dann ist der Neubau keine Geschmacksfrage, sondern die einzige Stelle, an der das neue Modell Platz hat.
Er trägt nur, wenn drei weitere Bedingungen zusammenkommen. Die Leute, die das Altsystem wirklich verstehen, müssen für die Spezifikation noch erreichbar sein. Die Organisation muss zwei Systeme gleichzeitig betreiben können: das alte, das das Geschäft trägt, und das neue, das es noch nicht tut. Und es muss klar sein, welcher Teil des Alten nicht mitkommt. Ein Neubau, der „alles, nur schöner“ verspricht, ist ein Altprojekt mit neuem Namen.
Joel Spolsky hat das Risiko 2000 am Beispiel von Netscape beschrieben: Ein vollständiger Neuschrieb wirft nicht nur schlechten Code weg, sondern Jahre kodierten Wissens über Randfälle. Genau diese Schicht sieht im Quelltext unordentlich aus und ist im Betrieb der wertvollste Teil. Wer sie wegwirft, entdeckt sie im neuen System ein zweites Mal — unter Zeitdruck und ohne die alten Tester.
Ablösen
Ablöse heißt: das eigene System durch ein anderes ersetzen — Standardsoftware, eine Plattform, ein Produkt, das ein Anbieter schon betreibt. Der eigene Code wird nicht neu geschrieben, er wird abgeschaltet.
Das trägt, wenn der eigene Prozess näher am Branchenstandard liegt, als intern behauptet wird. Viele „einzigartige“ Abläufe sind historisch gewachsene Sonderwege um eine Lücke herum, die das damalige Werkzeug hatte. Liegt die Lücke heute in jedem gängigen Produkt nicht mehr, ist die Ablöse die billigere Form der Standardisierung.
Sie trägt auch, wenn die eigentliche Last nicht die Fachlichkeit ist, sondern der Betrieb des Eigenen: niemand mehr, der den Stack wartet; Lizenzen, die auslaufen; eine Schlüsselperson, die das Haus verlässt; Sicherheitsupdates, die sich nicht mehr einspielen lassen, ohne drei Integrationen zu zerlegen. Dann kauft man nicht Features, sondern eine Betriebsform.
Sie trägt nicht, wenn das Datenmodell nicht abbildbar ist, die Integrationen dichter sind als der Kern, oder der Ausstieg aus dem neuen Vertrag in drei Jahren teurer wäre als der Verbleib im Alten. Eine Ablöse verschiebt Abhängigkeit — von internem Wissen auf einen Anbieter. Das kann richtig sein. Unbenannt ist es nur ein Tausch.
Liegt bereits ein Angebot, ein Konzept oder eine Produktauswahl auf dem Tisch, ist die Frage eine andere: nicht „was tragen die Systeme?“, sondern „trägt diese Vorlage?“. Dafür ist die Architektur-Zweitmeinung das passende Format, nicht dieser Beitrag.
Weiterbetreiben
Weiterbetreiben heißt nicht: nichts tun. Es heißt, bewusst in den Bestand zu investieren — Betrieb, Wissen, gezielte Instandsetzung — und die große Weichenstellung zu verschieben oder zu verwerfen.
ISO/IEC/IEEE 14764 fasst Softwarewartung nicht als Restgröße, sondern als eigenen Lebenszyklusprozess. Die Norm unterscheidet korrigierende, adaptive, perfektionierende und vorbeugende Wartung. Wer „weiterbetreiben“ sagt und nur Störungstickets meint, hat drei der vier Arten gar nicht beauftragt. Dann verfällt das System nicht, weil es alt ist, sondern weil niemand die Wartung als Programm geführt hat.
Weiterbetreiben trägt, wenn das System das Geschäft noch trägt, die Ausfälle verstanden und begrenzt sind, und eine Änderung am Bestand billiger und sicherer ist als der Übergang. Es trägt auch, wenn das sichtbare Problem gar nicht im System liegt.
Ein traditionsreicher Hersteller stand vor einer größeren Investition in den Onlinehandel. Die naheliegende Antwort war ein neuer Shop. Die Prüfung fiel gegen den Neubau aus: Die Infrastruktur war tragfähig und in wesentlichen Teilen unterausgelastet. Was zwischen Marke und Kunde stand, waren Auffindbarkeit und uneinheitliche Artikeldaten. Ein neues System hätte beides mitgenommen. Der Aufwand ging in die Positionen, die wirkten; die verworfene Alternative stand im Bericht, weil genau diese Frage intern beantwortet werden musste.
Weiterbetreiben trägt nicht, wenn das Betriebswissen in einem Kopf liegt und dieser Kopf nicht mehr lange da ist; wenn sich Sicherheitslücken nicht mehr schließen lassen, ohne das System anzuhalten; wenn sich für den Stack niemand mehr finden lässt; oder wenn eine regulatorische Änderung einen Vorgang verlangt, den das Datenmodell nicht ausdrücken kann. Dann ist „es läuft doch“ keine Strategie, sondern ein Aufschub mit Datum.
Die Kriterien, die die Entscheidung tragen
Die drei Optionen lassen sich nicht an einer Kennzahl entscheiden. Sie lassen sich an sieben Fragen so weit einengen, dass eine Empfehlung begründbar wird — und die verworfene Alternative mit ihr.
Fachliche Passung. Bildet das System den Vorgang noch ab, oder zwingt es die Organisation in den Vorgang von vor fünf Jahren? Passt der Schnitt nicht mehr zur Arbeitsteilung, helfen weder ein neues Frontend noch eine neue Lizenz.
Änderbarkeit. Lässt sich eine Anforderung an einer Stelle umsetzen, ohne dass drei andere brechen? Eng gekoppelte Systeme können fachlich noch richtig sein und trotzdem nicht mehr tragfähig, weil jede Änderung ein Projekt wird.
Wissen. Wer kann den Bestand erklären — nicht die Folie, sondern den Ablauf im Fehlerfall? Fehlt diese Person, ist der Neubau teurer als er aussieht, weil die Spezifikation geraten werden muss. Dieselbe Lücke macht die Ablöse riskanter, weil niemand den Fit-Gap ehrlich schneiden kann.
Betrieb. Wird überwacht, was ausfallen darf? Wurde die Wiederherstellung jemals ausgeführt? Ein System ohne getestetes Backup ist unabhängig vom Alter ein Betriebsrisiko; die Frage ist nur, ob man es im Bestand behebt oder im Übergang verdoppelt.
Abhängigkeit. Lizenzen, Anbieter, Personen, nicht dokumentierte Schnittstellen. Jede Option verschiebt diese Abhängigkeit, sie löscht sie nicht. Entscheidend ist, welche Verschiebung die Organisation tragen kann.
Daten. Wem gehören sie, in welcher Qualität, und was kostet es, sie zu bewegen? Viele Ablösen scheitern nicht am Produkt, sondern an Artikeln, Beständen und Vorgangsnummern, die im Alten nie eindeutig waren.
Absorptionsfähigkeit. Kann die Organisation einen Übergang neben dem Tagesgeschäft tragen — fachlich, personell, zeitlich? Ein richtiger Neubau zum falschen Zeitpunkt ist die teuerste Form der richtigen Idee.
Martin Fowlers Technical Debt Quadrant unterscheidet, was in dieser Liste oft untergeht: Nicht jede Unordnung ist dieselbe Sorte Schuld. Leichtsinnig angehäufter Ballast ist ein anderer Befund als eine bewusst genommene Abkürzung mit Datum. Im ersten Fall ist Weiterbetreiben ohne Programm Hoffnung. Im zweiten kann die Schuld bedient werden, statt das Haus zu verkaufen. Wer beides „Legacy“ nennt, hat die Entscheidung schon verwischt.
Eine grobe Risikomatrix
Das ist keine Bewertungsmethode und kein Score. Es ist die grobe Lage, in der die drei Wetten typischerweise scheitern — und die Fehleinschätzung, die jeweils dazu führt.
| Option | Was typischerweise schiefgeht | Umkehrbarkeit | Häufige Fehleinschätzung |
|---|---|---|---|
| Neu bauen | Doppelbetrieb, Scope, verlorenes Betriebswissen | nach Go-live gering | „Ohne den Altcode sind wir schneller.“ |
| Ablösen | Fit-Gap, Datenübernahme, Anbieterbindung | mittel, oft vertraglich begrenzt | „Standardsoftware ist immer billiger.“ |
| Weiterbetreiben | schleichender Verfall, Schlüsselperson, ungepatchte Fläche | der Start ist leicht; langes Warten wird teuer | „Solange es läuft, lassen wir es.“ |
Zwei Achsen reichen, um die grobe Lage zu sehen. Erstens: Was passiert mit dem Geschäft, wenn das System drei Tage steht oder einen falschen Bestand ausgibt? Zweitens: Wie teuer ist es, die Entscheidung in zwölf Monaten zurückzunehmen?
Steht das Geschäft still und die Entscheidung ist kaum umkehrbar, darf niemand aus einer Folie heraus neu bauen oder ablösen. Ist sie umkehrbar — ein abgegrenzter Teil, ein rückholbarer Schnitt —, kann eine gezielte Ablöse oder ein begrenzter Neubau das kleinere Risiko sein. Trägt das System und die Umkehrbarkeit ist hoch, ist Weiterbetreiben mit Programm die rationale Voreinstellung. Trägt es nicht mehr und die Umkehrbarkeit ist gering, wird oft weiterbetrieben, weil die anderen Wege zu groß wirken. Genau hier entsteht der Schaden, den man später dem „Altsystem“ zuschreibt.
Die Matrix ersetzt keine Prüfung. Sie zeigt, welche Behauptung die größte Beweislast hat.
Wann wir abraten
Wir raten vom Neubau ab, wenn das Motiv Langeweile, Personalwechsel oder „endlich moderne Technik“ ist und die Fachlichkeit sich nicht verschoben hat. Ein Team, das den Bestand nicht mehr anfassen will, hat ein Wissens- und Betriebsproblem. Das löst man nicht in einem leeren Repository.
Wir raten von der Ablöse ab, wenn niemand den eigenen Vorgang unabhängig vom aktuellen Werkzeug beschreiben kann. Dann kauft man nicht ein Produkt, sondern die Hoffnung, das Produkt werde den Vorgang erklären. Ebenso, wenn der Wechsel die Integrationen verdoppelt, bevor er den Kern ersetzt, oder der Vertrag den Ausstieg teurer macht als den Verbleib.
Wir raten vom Weiterbetreiben ab, wenn es nur der Aufschub einer Entscheidung ist, die die Organisation schon getroffen, aber nicht aufgeschrieben hat. Und wenn der Bestand nachweislich nicht mehr wartbar ist — nicht weil er alt ist, sondern weil niemand ihn mehr ändern, wiederherstellen oder erklären kann.
Von allen drei Wegen raten wir ab, solange die Investition die Antwort auf eine ungeprüfte Lage ist. Wer die Umsetzung schon gestartet hat und die Analyse nur noch formal abhaken möchte, bekommt von uns keine Bestätigung. Dasselbe gilt, wenn ein Befund eine vorher festgelegte Richtung stützen soll. Was vorher feststand, schreiben wir nicht auf.
Eine Investition, deren Begründung „sonst passiert nichts“ lautet, ist noch keine Entscheidung. Sie ist der Wunsch, die Unruhe zu beenden.
Erst der Befund, dann die Summe
Die Reihenfolge ist der eigentliche Inhalt. Zuerst der Zustand: Architektur, Datenflüsse, Integrationen, Sicherheit, Betrieb, technische Schulden. Dann die Optionen nebeneinander, einschließlich der verworfenen. Dann die Investition — oder das bewusste Unterlassen.
Das System-Audit ist dafür der abgegrenzte Auftrag: 6.500 € netto, vier Wochen, fünf Dokumente. Darunter eine Entscheidungsvorlage, in der Empfehlung und Sachverhalt getrennt stehen. Der Auftrag endet mit der Übergabe. Ob Sie danach selbst umsetzen, Ihren Dienstleister beauftragen oder 01PC, ist eine getrennte Frage.
Liegt die Unsicherheit nicht im Bestand, sondern in einer einzelnen Vorlage, ist das Audit die teure Antwort auf eine kleine Frage. Dann genügt die Zweitmeinung: 1.400 €, eine Woche, ein Dokument.
In beiden Fällen gilt dasselbe: Die Investition kommt nach dem Befund. Nicht davor.
Quellen