Wann sollten Sie bestehende Software ersetzen — und wann nicht?

Irgendwo in der Organisation läuft ein System, das schon seit Jahren da ist. Es ist langsam, es ist hässlich, und niemand weiß mehr genau, wie es funktioniert — außer vielleicht einem Mitarbeiter, der schon dreimal versucht hat, in Rente zu gehen. Aber das System läuft. Die Bestellungen kommen rein. Die Rechnungen gehen raus.

Die Frage, ob man dieses System ersetzen soll, ist eine der schwierigsten Entscheidungen in der IT, weil sowohl zu frühes als auch zu spätes Handeln Geld kostet. Unternehmen, die zu früh ersetzen, verschwenden Kapital für eine Migration, die nicht nötig war. Unternehmen, die zu spät ersetzen, zahlen jahrelang einen versteckten Tribut in Produktivitätsverlust, technischen Schulden und verpassten Chancen.

Hier ist ein ehrlicher Rahmen, um die Entscheidung zu treffen.

Die Zeichen, die sagen: Ersetzen Sie es

Das System schafft seine eigene Arbeitslast

Wenn Mitarbeiter strukturell mehr als zwei Stunden pro Tag mit Workarounds für das System beschäftigt sind — manuelle Dateneingabe zwischen Systemen, Excel-Dateien als Zwischenschicht, Kopieren-und-Einfügen, das eigentlich automatisch laufen sollte — dann ist das System kein unterstützendes Werkzeug mehr. Es ist Teil der Arbeitslast geworden.

Berechnen Sie das konkret. Vier Mitarbeiter, die je zwei Stunden pro Tag mit Workarounds verbringen: das sind acht Mannstunden pro Tag, vierzig pro Woche, über zweitausend pro Jahr. Bei einem durchschnittlichen Kostenniveau von €40 pro Stunde sind das €80.000 pro Jahr an versteckten Systemkosten — noch vor den Kosten der Fehler, die durch manuelle Arbeit entstehen.

Integration mit modernen Tools ist nicht mehr möglich

Nahezu jeder Geschäftsprozess berührt heutzutage mehrere Systeme: CRM, Buchhaltungspaket, E-Commerce-Plattform, Logistik, Kommunikationstools. Wenn Ihr Legacy-System keine API hat oder nur ein veraltetes Protokoll spricht, das moderne Tools nicht unterstützen, zahlen Sie unverhältnismäßig hohe Integrationskosten — oder Sie akzeptieren Informationssilos, die bessere Entscheidungsfindung behindern.

Dieser Punkt ist besonders kritisch, wenn Sie wachsen. Ein Unternehmen mit zwanzig Mitarbeitern kann vielleicht mit manueller Synchronisation leben. Ein Unternehmen mit hundert Mitarbeitern kann das nicht.

Der Lieferant hat das System verlassen

End-of-Life-Software ist ein unterschätztes Risiko. Wenn der Lieferant keine Sicherheitsupdates mehr veröffentlicht, betreiben Sie ein System mit bekannten Schwachstellen, die nicht behoben werden. Für Systeme, die Kundendaten verarbeiten, ist das auch ein DSGVO-Risiko. Versicherer beginnen, Fragen zu End-of-Life-Software in ihrer Cyber-Police zu stellen.

Ein System ohne aktive Lieferantenunterstützung ist technisch gesehen dem Untergang geweiht. Die Frage ist nur, wie lange es noch funktionsfähig bleibt, bevor etwas Unerwartetes es zu Fall bringt.

Eine Person ist die Einzige, die es versteht

Das wird im Volksmund „Bus-Faktor eins" genannt: Wenn diese eine Person unter einen Bus kommt, ist das System unverständlich. Das ist kein hypothetisches Risiko — es ist ein Kontinuitätsrisiko, das bei Due-Diligence-Prüfungen von Käufern und Investoren aufgedeckt wird.

Systeme ohne Dokumentation, mit Code, der nur noch vom ursprünglichen Erbauer zu lesen ist, werden mit jedem Jahr schwieriger und teurer zu warten. Jede Anpassung kostet mehr als die vorherige.

Sicherheitsprobleme sind strukturell nicht lösbar

Manchmal sind Schwachstellen keine Software-Bugs, sondern architektonische Probleme. Ein System, das ohne Authentifizierungsschicht entworfen wurde, das Passwörter im Klartext speichert oder das auf einer veralteten Serverumgebung läuft, die moderne Sicherheitsstandards nicht unterstützt: Das sind keine Probleme, die Sie mit einem Patch lösen. Das sind Probleme, die ein neues Design erfordern.

Die Zeichen, die sagen: Warten Sie

Das System funktioniert — nur nicht schön

Es gibt einen Unterschied zwischen einem System, das Probleme verursacht, und einem System, das alt ist, aber funktioniert. Ein hässliches Dashboard ist kein Grund, ein System zu ersetzen. Ein langsamer, aber zuverlässiger Workflow ist kein Grund, ein System zu ersetzen. Die Frage lautet immer: Was kostet das System in seinem aktuellen Zustand, und was kostet es, es zu ersetzen? Wenn die Kosten des Systems niedriger sind als die Kosten der Migration plus die Risiken eines Übergangs, ist Warten die klügere Wahl.

Die Amortisationszeit überschreitet drei Jahre

Eine Software-Migration kostet Zeit, Geld und operative Unterbrechungen. Wenn die jährliche Einsparung durch ein neues System kleiner ist als ein Drittel der Migrationskosten, ist der Business Case schwach. Drei Jahre ist eine Faustregel — für schnell wachsende Unternehmen kann zwei Jahre akzeptabel sein, für stabile Organisationen kann vier Jahre noch vertretbar sein. Aber wenn die Amortisationszeit fünf Jahre oder länger beträgt, ist die Wahrscheinlichkeit groß, dass die Organisation bis dahin bereits wieder verändert ist.

Es gibt keine interne Kapazität für den Übergang

Eine Migration ist nicht nur ein IT-Projekt. Sie erfordert die Beteiligung der Menschen, die das System täglich nutzen, für die Definition von Anforderungen, das Testen der neuen Lösung und das Durchstehen der anfänglichen Unannehmlichkeiten. Wenn die Organisation gerade durch eine andere große Transition geht, wenn Schlüsselmitarbeiter überlastet sind oder wenn kein internes Eigenverantwortlichkeit zu organisieren ist, ist die Wahrscheinlichkeit einer erfolgreichen Migration gering — unabhängig davon, wie gut das neue System ist.

Der Mittelweg: Das Legacy-System einwickeln

Es gibt eine dritte Option, die oft übersehen wird: das bestehende System nicht ersetzen, sondern eine moderne Schicht darum herum bauen.

Das heißt in der Software-Architektur „Strangler Fig"-Ansatz — benannt nach dem Feigenbaum, der einen anderen Baum langsam umwächst und übernimmt. Sie bauen neue Funktionalität in einem modernen System und sorgen dafür, dass dieses System über eine API mit dem Legacy-System kommuniziert. Mit der Zeit verschieben sich immer mehr Funktionen in die neue Schicht, bis das alte System so wenig tut, dass es sicher abgeschaltet werden kann.

Das ist besonders nützlich, wenn:

• Das Legacy-System stabile Kerndatenmodelle hat, die es wert sind, erhalten zu werden
• Eine vollständige Ablösung operativ zu riskant ist
• Man schrittweise modernisieren möchte, ohne eine „Big Bang"-Migration

Die Kehrseite: Eine API-Schicht über einem schlecht entworfenen Legacy-System ist vorübergehend Blei um altes Eisen. Sie verschafft Luft, löst aber die zugrundeliegenden Architekturprobleme nicht.

Zwei Migrationsstrategien verglichen

Big Bang: Alles auf einmal

Sie bauen ein vollständig neues System, migrieren alle Daten zu einem festgelegten Datum und schalten das alte System ab. Vorteil: Sie zahlen nicht jahrelang für zwei Systeme nebeneinander. Nachteil: Das Risiko ist hoch. Wenn das neue System am Launch-Tag nicht gut funktioniert, haben Sie keine Rückfalloption.

Big-Bang-Migrationen funktionieren am besten bei kleineren Systemen, gut dokumentierten Prozessen und Organisationen, die die operative Unterbrechung auffangen können.

Strangler Fig: Schrittweise Ablösung

Sie ersetzen das System Modul für Modul, wobei das neue System schrittweise die Funktionen des alten übernimmt. Vorteil: geringeres Risiko pro Phase, kontinuierliche Lernkurve, frühere Rendite bei Teilsystemen. Nachteil: höhere Gesamtkosten, längere Durchlaufzeit, Komplexität des Betriebs zweier Systeme nebeneinander.

Für große, geschäftskritische Systeme ist der Strangler-Fig-Ansatz fast immer die klügere Wahl — auch wenn die Gesamtkosten höher ausfallen.

Die Entscheidung

Ersatz ist die richtige Wahl, wenn zwei oder mehr der „Ersetzen Sie es"-Zeichen vorhanden sind und der Business Case über drei Jahre positiv ist. Warten ist die richtige Wahl, wenn der operative Schmerz beherrschbar ist und die Organisation die Migrationskapazität jetzt nicht hat.

Was niemals die richtige Wahl ist: nichts zu entscheiden, weil die Entscheidung schwierig ist. Jedes Jahr, das ein problematisches Legacy-System weiterläuft, akkumulieren sich die Kosten der technischen Schulden. Diese Schuld wird irgendwann bezahlt — die Frage ist nur wann und unter welchen Umständen.