Die Situation kennen viele: Ein System läuft seit Jahren, trägt einen relevanten Teil des Umsatzes und ist gleichzeitig der Grund, warum jedes neue Feature Wochen statt Tage braucht. In der Technik ist längst klar, dass etwas passieren muss. Nur wird in der Geschäftsführung nicht in "technischer Schuld" gerechnet, sondern in Euro, Risiko und Zeit. Genau hier scheitern die meisten Modernisierungen: nicht am Code, sondern an einem fehlenden Business Case.
Ein Business Case Modernisierung ist kein technisches Dokument. Er ist die Übersetzung eines Engineering-Problems in eine Investitionsentscheidung. Wer diese Übersetzung nicht liefert, bekommt entweder ein Nein oder das gefährlichste aller Ja: "Dann machen wir eben komplett neu."
Warum ein laufendes System kein Sanierungsfall ist
Bevor Sie rechnen, klären Sie die Grundannahme. Ein System, das seit Jahren im Produktivbetrieb funktioniert, ist kein Müll. Es ist der Beweis, dass die Fachlogik trägt. Die eigentlichen Geschäftsregeln, die Sonderfälle, die über Jahre gewachsenen Ausnahmen im Bestellprozess oder in der Abrechnung, das ist Ihr wertvollstes Asset. Dieses Wissen steckt oft nirgends sauber dokumentiert, sondern nur im Code selbst.
Das Problem ist fast nie die Fachlogik. Das Problem ist der Code drumherum: eine veraltete PHP-Version ohne Sicherheitsupdates, direkte SQL-Strings statt Prepared Statements, keine Tests, ein Framework in einer Version, die niemand mehr pflegt, Abhängigkeiten, die sich nicht mehr per Composer aktualisieren lassen. Diese Unterscheidung ist die Basis Ihres gesamten Business Case. Denn sie führt direkt zu der Frage, die über die Kosten entscheidet.
Warum Neuentwicklung fast immer die teuerste Option ist
Ist eine komplette Neuentwicklung nicht sauberer als eine Modernisierung? In der Regel nein. Eine Neuentwicklung bedeutet, dass Sie das über Jahre gewachsene Fachwissen aus dem alten System vollständig neu erheben, neu implementieren und neu testen müssen, während der Altbetrieb parallel weiterlaufen und weiter gewartet werden muss.
Der teure Teil einer Neuentwicklung ist nicht das Schreiben von Code. Es ist die Rekonstruktion der Anforderungen. Jede undokumentierte Ausnahme, die im alten System seit acht Jahren stillschweigend funktioniert, wird im Neubau zum Bug, den irgendwann ein Kunde meldet. Sie zahlen also doppelt: einmal für das neue System und einmal dafür, alle alten Sonderfälle mühsam wiederzuentdecken.
Für den Business Case heißt das: Stellen Sie der Neuentwicklung ehrlich die Alternative der schrittweisen Modernisierung gegenüber. Ein sinnvoller Weg ist oft die inkrementelle Ablösung, bei der Sie das Altsystem hinter einem Fassaden-Layer schrittweise durch neue Teile ersetzen (das Strangler-Fig-Muster). Das System bleibt die ganze Zeit lauffähig, und Sie liefern kontinuierlich Wert, statt monatelang auf einen riskanten Stichtag hinzuarbeiten.
Welche Kosten der Status quo wirklich verursacht
Die stärkste Zahl im Business Case ist selten die Investitionssumme. Es sind die Kosten des Nichtstuns. Diese bleiben ohne Ihr Zutun unsichtbar, weil sie im Tagesgeschäft versickern. Machen Sie sie greifbar:
- Wartungslast: Wie viele Entwicklertage pro Monat fließen in Workarounds, manuelle Deployments und das Nachstellen von Fehlern, die es mit Tests nicht gäbe? Diese Stunden haben einen konkreten Tagessatz.
- Feature-Geschwindigkeit: Wie lange dauert heute eine Änderung, die fachlich eine Kleinigkeit ist? Der Unterschied zwischen "zwei Tage" und "drei Wochen" ist entgangener Umsatz oder ein verlorener Kunde.
- Sicherheitsrisiko: Eine PHP-Version ohne Security-Support oder ein Framework ohne Updates bedeutet, dass bekannte Lücken offenbleiben. Das ist kein technisches Detail, sondern ein Haftungs- und DSGVO-Thema mit realem finanziellem Schaden im Ernstfall.
- Personalrisiko: Wenn nur noch eine Person das System versteht, ist das ein Ausfallrisiko, das sich beziffern lässt. Neue Entwickler für eine tote Technologie zu finden, ist teuer und langsam.
Sie brauchen hier keine erfundenen Prozentzahlen. Nehmen Sie echte Zahlen aus Ihrem eigenen Ticket-System und Ihrer Zeiterfassung. Zwei, drei ehrliche Datenpunkte aus dem Haus überzeugen mehr als jede Branchenstudie.
Wie Sie den Business Case Modernisierung konkret aufbauen
Wie baue ich einen Business Case Modernisierung auf, der die Geschäftsführung überzeugt? Sie stellen die Kosten des Status quo den Kosten der Modernisierung gegenüber und zeigen, wie sich die Investition durch geringere Wartung, schnellere Features und weniger Risiko rechnet. Konkret in vier Schritten:
- Ausgangslage in Euro fassen. Wartungsstunden, Ausfälle, verzögerte Features und das Sicherheitsrisiko als jährliche Größenordnung. Lieber grob und belegbar als präzise und erfunden.
- Optionen ehrlich gegenüberstellen. Nichts tun, Neuentwicklung, schrittweise Modernisierung. Nennen Sie bei jeder Option auch die Nachteile. Ein Business Case, der nur Vorteile kennt, wirkt unglaubwürdig.
- In Etappen mit Zwischenergebnissen planen. Erst die PHP-Version und die Sicherheitslücken, dann eine Testabdeckung um die kritische Fachlogik, dann die schrittweise Erneuerung. Jede Etappe liefert für sich einen Nutzen und lässt sich stoppen, ohne alles zu verlieren.
- Erfolg messbar machen. Definieren Sie vorab, woran Sie den Erfolg festmachen: kürzere Durchlaufzeit für Änderungen, weniger produktive Fehler, aktueller Sicherheitsstand. So wird aus einem Vertrauensvorschuss ein überprüfbares Versprechen.
Der entscheidende Punkt in der Reihenfolge: Die erste Etappe sollte Risiko abbauen, nicht neue Features bringen. Eine Testabdeckung um die Kernlogik und eine aktuelle, sicherheitsgepatchte Basis sind unspektakulär, aber sie machen alles Folgende überhaupt erst sicher planbar. Wer zuerst Tests schreibt, verwandelt "wir hoffen, dass nichts kaputtgeht" in "wir wissen es".
Der häufigste Fehler: das große Versprechen
Viele Modernisierungen werden verkauft mit dem Versprechen, danach sei alles besser, schneller und moderner. Das ist der falsche Rahmen. Er erzeugt eine Erwartung, die kein Projekt einlösen kann, und beim ersten Rückschlag ist das Vertrauen weg.
Rahmen Sie es anders: Modernisierung ist Risikomanagement für ein funktionierendes Asset. Sie werfen nichts weg, das funktioniert. Sie sichern den funktionierenden Kern ab und machen ihn wieder wartbar und weiterentwickelbar. Diese Ehrlichkeit ist kein Nachteil im Verkauf, sie ist der Grund, warum ein Vorstand am Ende zustimmt.
Praxis-Tipp zum Schluss: Bevor Sie eine große Summe beantragen, holen Sie sich mit einer kleinen, klar begrenzten ersten Etappe einen sichtbaren Erfolg. Eine aktuelle PHP-Version plus Tests um den kritischsten Prozess kostet überschaubar, senkt sofort das größte Risiko und liefert Ihnen den Beweis, dass der Weg trägt. Mit diesem Beweis in der Hand ist der Business Case für den Rest fast schon geschrieben. Genau bei dieser Einschätzung und dem Aufbau des Business Case unterstützt LegacyWerk, wenn Sie einen ehrlichen Blick von außen brauchen.
