Es gibt in fast jedem mittelständischen Unternehmen dieses eine System. Es läuft seit zwölf Jahren. Niemand will es anfassen. Der Entwickler, der es gebaut hat, ist längst weg. Und trotzdem hängt ein Großteil des Tagesgeschäfts daran. Du weißt, dass du irgendwann etwas tun musst. Du weißt nur nicht was — und vor allem, ohne dass der Laden für eine Woche stillsteht.
Dieser Beitrag ist die ehrliche Anleitung dazu. Inklusive der unbequemen Wahrheit, warum der naheliegende Reflex — „alles wegwerfen und neu bauen" — fast immer scheitert, und was stattdessen funktioniert.
Der Begriff Legacy klingt nach Müll. Das ist er nicht. Ein Altsystem ist Software, die seit Jahren funktioniert und reale Arbeit erledigt. Das ist eine Leistung, kein Versagen. Das eigentliche Problem ist selten der Code an sich — es ist, dass das Wissen darüber verloren gegangen ist und dass Änderungen riskant geworden sind.
Ein Altsystem wird genau dann zum echten Problem, wenn eine von vier Bedingungen eintritt: Es lässt sich nicht mehr sicher ändern. Es lässt sich nicht mehr mit anderen Systemen verbinden. Es kann nicht mehr betrieben werden, weil die Technik ausläuft. Oder das Wissen ist auf eine einzige Person geschrumpft.
Wenn keine dieser vier Bedingungen erfüllt ist, ist die ehrlichste Empfehlung oft: in Ruhe lassen. „Es ist alt" ist kein Geschäftsproblem. „Wir können nicht mehr reagieren" ist eines. Modernisiere wegen eines konkreten Schmerzes, nicht wegen eines Bauchgefühls.
Der naheliegende Reflex: „Lasst uns das alte Ding wegwerfen und sauber neu bauen." Er fühlt sich richtig an. Er ist fast immer falsch. Das ist keine bloße Meinung: Der gescheiterte „große Rewrite" gehört zu den am ausführlichsten dokumentierten Erfahrungen der Softwarebranche — von Joel Spolskys Klassiker „Things You Should Never Do" bis zu Martin Fowlers Arbeiten zur schrittweisen Ablösung (Quellen am Ende).
Drei Gründe, warum der Big-Bang-Rewrite scheitert:
Die ehrliche Konsequenz: Der Big Bang ist die teuerste und riskanteste Option. Es gibt fast immer einen besseren Weg.
Die bewährte Strategie heißt, das Altsystem schrittweise abzulösen, statt es in einem Knall zu ersetzen. Das Bild dahinter: Du baust das Neue außen herum und schneidest dem Alten Stück für Stück die Aufgaben ab, bis nichts mehr übrig ist, das es noch tun muss.
Konkret bedeutet das: Du legst eine saubere Schnittstelle vor das Altsystem. Neue Funktionalität entsteht im Neuen. Bestehende Funktionen werden einzeln, in Reihenfolge ihres Schmerzes, herausgelöst und ersetzt. Das Altsystem schrumpft, statt zu explodieren.
Der entscheidende Vorteil: Jeder Schritt liefert Wert und ist für sich genommen klein und umkehrbar. Geht ein Schritt schief, hast du ein kleines Problem, keine Unternehmenskrise. Diese Schnittstellenschicht ist meist der allererste, risikoärmste Modernisierungsschritt — wir haben das Thema vertieft in API-Entwicklung in München.
Auch hier die ehrliche Gegenrichtung. Nicht jedes Altsystem gehört modernisiert.
Wenn es stabil läuft und sich nichts ändern muss. Ein in sich geschlossenes System, das eine abgeschlossene Aufgabe zuverlässig erledigt und keine neuen Anforderungen bekommt, ist kein Modernisierungsfall. Es ist ein funktionierendes Werkzeug. Lass es laufen.
Wenn der zugrunde liegende Prozess ohnehin abgeschafft wird. Modernisiere niemals einen Prozess, der in einem Jahr nicht mehr existiert. Erst die Geschäftsentscheidung, dann die Technik.
Wenn die ehrliche Antwort „ablösen durch Standardsoftware" ist. Manchmal ist die Modernisierung gar kein Entwicklungsprojekt, sondern eine Einkaufsentscheidung: Das Altsystem macht heute nichts mehr Unternehmensspezifisches, ein Standardprodukt kann es übernehmen. Diese Abwägung führen wir grundsätzlich im Leitfaden zur individuellen Softwareentwicklung.
Ein guter Partner prüft diese drei Fälle zuerst — bevor er dir ein Modernisierungsprojekt verkauft.
Ein Wort zur Vertragsgestaltung, weil sie bei Legacy-Projekten besonders heikel ist: Ein reiner Festpreis ist hier fast immer die falsche Wahl. Niemand kann seriös vorab festpreisen, was in einem undokumentierten Altsystem an Überraschungen schlummert. Wer es trotzdem tut, hat entweder einen riesigen Risikoaufschlag eingerechnet oder wird das Projekt mitten im Schritt nachverhandeln.
Warum das so ist und welches Modell stattdessen passt, haben wir ausführlich in Festpreis vs. agil beschrieben. Kurzfassung für Legacy: Discovery klar abgegrenzt, Umsetzung iterativ mit Budget-Deckel. Und weil der Mittelstand hier eigene Spielregeln hat, lohnt ergänzend Software für den Mittelstand.
Mehr zu unserem Vorgehen findest du auf der Seite zur individuellen Software- und App-Entwicklung.
Legacy-Modernisierung ist kein Aufräumprojekt, sondern Risikomanagement. Der naheliegende große Rewrite ist fast immer die teuerste und riskanteste Option. Der bessere Weg ist, das Altsystem schrittweise abzulösen — kleine, wertvolle, umkehrbare Schritte. Und manchmal ist die ehrlichste Modernisierung, das System einfach in Ruhe zu lassen.
Du hast ein System, das niemand mehr anfassen will und an dem trotzdem alles hängt? Wir analysieren ehrlich, ob und wie es schrittweise abgelöst werden sollte — und sagen dir auch, wenn du es besser in Ruhe lässt.
Dieser Beitrag beruht auf eigener Projekterfahrung aus Legacy-Modernisierungen im Raum München. Die zentralen Aussagen — warum der große Rewrite scheitert und warum die schrittweise Ablösung der bessere Weg ist — sind etabliertes, gut dokumentiertes Branchenwissen; die ursprünglichen Primärquellen sind unten verlinkt.
