Der Business Case für Legacy-Modernisierung: Wie Sie Budget bekommen und den ROI beziffern

Die meisten Budgetanträge für Modernisierung scheitern nicht an der Sache, sondern an der Sprache. Der CTO kommt mit einer Liste architektonischer Probleme, einer Kennzahl zur Testabdeckung und einer Abhängigkeitskarte in die Geschäftsleitung, und ihm gegenüber sitzen Menschen, die am selben Tag über den Eintritt in einen neuen Markt und über den Ausbau des Vertriebsteams entscheiden. Diese beiden Anträge haben eine berechnete Rendite. Die Modernisierung hat keine, also verliert sie, selbst wenn sie die rentabelste der drei Investitionen wäre.

Das Problem liegt nicht darin, dass Führungsgremien Technologie nicht verstünden. Es liegt darin, dass sich zwei Investitionen nicht vergleichen lassen, wenn nur eine in Zahlen ausgedrückt ist. Der folgende Beitrag zeigt praxisnah, wie sich ein Business Case für Modernisierung aufbauen lässt: wie laufende Kosten, Opportunitätskosten und Aufschubkosten beziffert werden, wie Optionen dargestellt werden, welche Kennzahlen in einem Führungsgremium tatsächlich wirken und welche Fehler die Zustimmung am häufigsten kosten.

Warum ein technischer Antrag gegen einen kommerziellen verliert

Ein Führungsgremium bewertet Investitionen an einem gemeinsamen Maßstab: Was hat das Unternehmen davon und wann? Ein Antrag zum Ausbau des Vertriebs benennt klar, wie viele zusätzliche Abschlüsse er bringen soll und in welchem Zeitraum. Ein Modernisierungsantrag sagt meist, die Architektur sei eng gekoppelt, die technischen Schulden wüchsen und das System stelle ein Risiko dar. All das kann zutreffen und ist dennoch keine Entscheidungsgrundlage, weil weder ein Betrag noch ein Zeithorizont darin vorkommt.

Die zweite Ursache ist die Rahmung. Modernisierung als Aufräumen nach Jahren von Kompromissen dargestellt, klingt nach den Kosten für die Korrektur eigener Fehler. Dieselbe Modernisierung als Beseitigung einer Barriere dargestellt, die den Wachstumsplan blockiert, klingt nach Investition. Der Unterschied ist nicht kosmetisch: Die erste Fassung konkurriert mit anderen Kosten, die zweite mit anderen Investitionen, und das sind in einer Budgetdiskussion völlig verschiedene Kategorien.

Die dritte Ursache ist das Fehlen von Alternativen. Ein Antrag mit einer Lösung und einem Betrag stellt das Gremium vor eine Ja-Nein-Entscheidung. Ein Antrag mit drei Szenarien samt ihren Konsequenzen, einschließlich des Nichtstuns, gibt dem Gremium, was es erwartet: die Möglichkeit zu entscheiden statt lediglich abzunicken.

Erste Säule: laufende Kosten

Die laufenden Kosten sind der am leichtesten zu berechnende Teil des Business Case und meist der am stärksten unterschätzte. Sie zerfallen in mehrere Posten, die man trennen sollte, weil jeder ein anderes Mitglied der Geschäftsleitung anspricht.

Die Grundlage bilden die Lieferkosten. Wenn eine Funktion, die früher zwei Wochen brauchte, heute sechs braucht, lässt sich das unmittelbar als Engineering-Kosten je gelieferter Werteinheit ausdrücken. In einem von Altimi modernisierten System, einer Plattform für Qualitätsmanagement auf einem Stack aus dem Jahr 2016, waren die Kosten für die Auslieferung einer Funktion auf das Fünffache des Ausgangswerts gestiegen. Bei einem Team von einem Dutzend Ingenieuren oder mehr ergibt diese Differenz einen Betrag, den jeder CFO ohne Übersetzung erkennt.

Der zweite Posten sind Wartungs- und Infrastrukturkosten, am besten als Anteil am Umsatz ausgedrückt und im Zeitverlauf verfolgt. Ein steigender Anteil bei stabiler Produktmarge ist ein konkreter Beleg dafür, dass das Modell nicht wie geplant skaliert.

Der dritte sind die Kosten von Störungen und Ausfällen, gerechnet nicht nur in Arbeitsstunden, sondern auch als Kundenwirkung und als Exponierung aus Service-Level-Zusagen. Der vierte, oft vergessene, sind Rekrutierungs- und Einarbeitungskosten: Braucht eine neue Fachkraft ein Quartal bis zur eigenständigen Arbeit, liefert jede Stelle deutlich später Wert als im Personalplan unterstellt.

Zweite Säule: Opportunitätskosten

Das ist der am schwersten zu beziffernde und meist größte Teil. Laufende Kosten stehen in den Berichten, Opportunitätskosten stehen nirgends, weil sie Dinge betreffen, die nicht geschehen sind.

Drei Posten lohnen die Quantifizierung. Der erste sind verlorene Abschlüsse. Verliert der Vertrieb Verfahren in der Phase des Sicherheitsfragebogens oder wegen fehlender, von Konzernkunden erwarteter Zertifizierungen, ist der Wert dieser Abschlüsse ein unmittelbarer Preis des technischen Zustands. Es genügt, verlorene Chancen ihrer Ablehnungsursache gegenüberzustellen, um eine Zahl zu erhalten, die niemand bestreitet.

Der zweite ist die verzögerte Markteinführung. Sah der Plan den Start einer neuen Produktlinie in einem bestimmten Quartal vor und verschob der Systemzustand ihn um zwei, sind die Kosten der in diesem Fenster nicht erzielte Umsatz und der an Wettbewerber abgegebene Vorsprung.

Der dritte sind Funktionen, die nie vorgeschlagen wurden. Dieser Posten muss bewusst gesucht werden, denn er steht naturgemäß in keinem Backlog. In der Praxis genügt die Frage an die Produktverantwortlichen, was sie aufgehört haben vorzuschlagen, weil klar war, dass das System es nicht trägt. Die Antworten überraschen häufig und zeigen einem Gremium meist am besten, dass das Problem strategischer und nicht technischer Natur ist.

Dritte Säule: Kosten des Aufschubs

Das ist die am seltensten gestellte Frage und meist die überzeugendste für ein Gremium, das zwischen Handeln jetzt und einer Entscheidung in einem Jahr schwankt.

Aufgeschobene Modernisierung kostet ein Jahr später aus mehreren Gründen nicht dasselbe. In der Zwischenzeit entsteht weiterer Code auf den alten Annahmen, der Umfang wächst also. Das Fenster vor dem Supportende der Komponenten verengt sich, was bei großem Kundenstamm darüber entscheiden kann, ob eine Migration in vernünftigem Zeitrahmen überhaupt machbar ist. Bei der erwähnten Qualitätsmanagement-Plattform war einer der auslösenden Faktoren das für 2027 geplante Supportende der eingesetzten Datenbankversion, was angesichts der Migration des gesamten Kundenstamms einen frühen Beginn erforderte.

Auch das Risiko wächst. Jedes weitere Quartal auf nicht unterstützten Komponenten erhöht die Wahrscheinlichkeit eines Sicherheitsvorfalls und erschwert Gespräche mit Konzernkunden zusehends. Das als Kurve statt als einmaligen Betrag darzustellen, verändert die Diskussion: Das Gremium wählt nicht mehr zwischen Geld ausgeben und nicht ausgeben, sondern zwischen weniger jetzt und mehr später.

Wie die Optionen darzustellen sind

Ein guter Antrag enthält mindestens drei Optionen, jede mit Betrag, Zeitplan und Konsequenzen.

Die Nichtstun-Option ist der Bezugspunkt. Sie zeigt, wie laufende Kosten, Risiko und Liefertempo in zwei Jahren aussehen, wenn sich nichts ändert. Ohne sie hat das Gremium nichts, woran es die übrigen misst.

Die Option der schrittweisen Modernisierung ist meist die Empfehlung: Beginn bei den Modulen mit dem höchsten Risiko und der größten Wirkung auf den Plan, Lieferung in Phasen, durchgehendes Ausliefern durch das Team. Entscheidend ist der Hinweis, dass die ersten Wirkungen binnen Monaten eintreten und nicht erst am Ende des gesamten Programms.

Die Option der vollständigen Neuentwicklung gehört auch dann in den Antrag, wenn sie nicht empfohlen wird, gerade um Kosten und Risiko sichtbar zu machen. Eine Neuentwicklung unterstellt, dass das Team das bestehende System gut genug versteht, um es nachzubilden, dass die Anforderungen über viele Quartale stillhalten und dass im verworfenen Code nichts Wesentliches steckt. Diese Annahmen neben die schrittweise Option gestellt, entscheiden die Diskussion meist von selbst.

Zu jeder Option gehören nicht nur die Kosten, sondern auch der Zeitpunkt der ersten Wirkungen und die Angabe, was während der Arbeiten mit der Produktauslieferung geschieht. Für ein Gremium wiegt die zweite Information oft schwerer als die erste.

Kennzahlen, die in der Geschäftsleitung wirken

Nicht jede Engineering-Kennzahl gehört in eine Vorlage für die Geschäftsleitung. Es wirken jene, die den technischen Zustand mit einem finanziellen Ergebnis oder mit dem Plan verbinden.

Die erste Gruppe betrifft das Tempo: Zeit von der Entscheidung für eine Funktion bis zur Produktivsetzung und Anzahl der Releases pro Monat. Das ist der einfachste Weg zu zeigen, ob Investitionen in die Fundamente sich in Lieferfähigkeit übersetzen.

Die zweite sind Stückkosten: Engineering-Kosten je gelieferter Funktion und Infrastrukturkosten je Kunde. Die dritte ist Risiko in geschäftlichen Begriffen: offene kritische Schwachstellen, Komponenten ohne Herstellersupport und der Stand jener Anforderungen, die den Vertrieb in das Konzernsegment bestimmen.

Die vierte und wichtigste ist die Wirkung auf den Plan: wie viele geplante Produktinitiativen durch den Systemzustand blockiert sind und wie sich diese Zahl entwickelt. Diese Kennzahl erklärt einem Gremium am besten, warum Modernisierung mit Wachstumsinitiativen um Budget konkurriert und nicht mit Verwaltungskosten.

Es lohnt sich, vorab zu vereinbaren, wie diese Kennzahlen nach Programmstart berichtet werden. Ein Antrag, der sich auf eine konkrete Messweise festlegt, ist deutlich leichter zu genehmigen als einer, der mit dem Versprechen von Verbesserung endet.

Vier Fehler, die die Zustimmung kosten

Der erste ist ein großer Betrag ohne Phasen. Ein Antrag über ein mehrjähriges Programm weckt naturgemäß Vorsicht. Dasselbe Programm in Phasen gegliedert, deren erste klein ist und mit einem konkreten Ergebnis endet, geht deutlich leichter durch.

Der zweite ist das Versprechen nicht messbarer Wirkungen. Formulierungen wie bessere Codequalität oder größere architektonische Flexibilität lassen sich nicht abrechnen und untergraben die Glaubwürdigkeit des gesamten Antrags. Besser weniger versprechen, dafür in überprüfbaren Größen.

Der dritte ist das Weglassen der Nichtstun-Option. Ohne Bezugspunkt vergleicht das Gremium die Modernisierungskosten mit null, was immer ungünstig ausfällt. Mit Nichtstun-Option vergleicht es zwei Beträge, von denen einer über die Zeit wächst.

Der vierte ist ein Antrag auf Basis ungedeckter Schätzungen. Stammen Kosten und Zeitplan aus dem Bauchgefühl des Teams, beendet die erste Frage nach ihrer Grundlage die Diskussion. Deshalb sollte ein Business Case aus einer strukturierten Bewertung am echten Code hervorgehen und nicht aus einem Whiteboard-Workshop.

Woher die Zahlen kommen

Das ist die häufigste Hürde: Das Team weiß, dass das System ein Problem darstellt, hat aber keine Daten, um es in finanzieller Sprache zu belegen. Eine technische Bewertung, die auf eine Investitionsentscheidung hin konzipiert ist, löst das, weil sie Diagnose und Bezifferung zugleich liefert.

Das AI Refactoring Assessment von Altimi dauert vier Wochen und ist so gebaut, dass sein Ergebnis in einer Sitzung der Geschäftsleitung bestehen kann. Es besteht aus zwei verbundenen Arbeitssträngen. Der erste ist die Bewertung von Architektur und technischen Schulden: die Feststellung, welche Teile des Systems Wachstum und Skalierbarkeit blockieren, mit quantifizierten Schulden, einer Bewertung der KI-Reife und einer Prüfung der Infrastrukturrisiken. Der zweite ist ein Technical Spike, eine praktische Validierung des risikoreichsten Teils der Codebasis am echten Produktionscode, die belastbare Daten zum Migrationsrisiko und zur tatsächlichen Wirkung von KI-Werkzeugen liefert, bevor Budget gebunden wird.

Das Ergebnis ist ein Entscheidungspaket auf Geschäftsleitungs- und Investorenniveau: Executive Summary, Risikokarte, KI-gestützte Modernisierungs-Roadmap, priorisiertes Backlog der technischen Schulden, Erkenntnisse aus dem Spike und ein Business Case mit finanziellen Kennzahlen. Übergeben wird es in einem Readout-Workshop, was praktisch ins Gewicht fällt: Die Führung kann jene befragen, die die Analyse durchgeführt haben, statt ein Dokument ohne Kontext zu lesen.

Für die Renditerechnung ist die Bewertung der KI-Wirkung besonders bedeutsam. Die Analyse zeigt, welche Modernisierungsaufgaben KI-Werkzeuge um 50 bis 80 Prozent beschleunigen können und welche weiterhin das Urteil erfahrener Ingenieure verlangen. Diese Unterscheidung verändert die Kalkulation des Programms und damit das Ergebnis des gesamten Business Case, weshalb eine Stützung auf allgemeine Annahmen statt auf Validierung am eigenen Code zu Zahlen führt, die sich nicht verteidigen lassen.

Die Belastung des Teams bleibt gering, da die Arbeit im Lesezugriff erfolgt, mit zwei bis drei Sessions pro Woche mit Architekten oder Tech Leads und ohne Einfrieren der Roadmap. Die Bilanz von Altimi umfasst über 150 bewertete Legacy-Systeme in den Segmenten SaaS, FinTech, EdTech und Cybersecurity, von gründergebauten Monolithen bis zu skalierenden Mid-Market-Plattformen unter Lieferdruck.

Der europäische Kontext

Für Unternehmen in Deutschland, Österreich und der Schweiz sowie in Mittel- und Osteuropa ist die regulatorische Dimension oft das stärkste Argument im Business Case, weil sie sich am unmittelbarsten in Umsatz übersetzt. Die Einhaltung der DSGVO, Anforderungen aus Rahmenwerken wie ISO 27001 und die Erwartungen von Konzernkunden an Sicherheit und Nachvollziehbarkeit bestimmen faktisch den Zugang zu den wertvollsten Marktsegmenten. Macht die Architektur ihre Erfüllung unmöglich, lassen sich die Kosten dieses Zustands direkt als jener Marktanteil ausdrücken, den das Unternehmen nicht erreichen kann.

Ebenso zählt, wo der Quellcode während einer KI-gestützten Bewertung verarbeitet wird. Die Zusammenarbeit mit einem in der EU ansässigen, nach ISO 27001 zertifizierten Partner hält sensiblen Code innerhalb des europäischen Datenschutzraums und dokumentiert den Einsatz von KI, was bei Audits und in Gesprächen mit Konzernkunden bedeutsam sein kann.

Der Business Case für Legacy-Modernisierung

Modernisierung verliert den Kampf ums Budget nicht, weil sie unrentabel wäre, sondern weil sie selten als Investition mit berechneter Rendite präsentiert wird. Ein Business Case mit Aussicht auf Erfolg ruht auf drei Säulen: den laufenden Kosten, die in den Zahlen sichtbar sind, den Opportunitätskosten, die bewusst gesucht werden müssen, und den Aufschubkosten, die zeigen, dass der Betrag mit jedem Quartal Verzögerung wächst.

Hinzu kommen drei Elemente: Optionen statt eines einzigen Vorschlags, Kennzahlen, die den technischen Zustand mit finanziellen Ergebnissen verbinden, und Zahlen aus einer Bewertung am echten Code statt aus Schätzungen. Ein so aufgebauter Antrag konkurriert nicht länger mit Verwaltungskosten, sondern mit Wachstumsinitiativen, und damit in der richtigen Kategorie.

Wenn Sie einen solchen Antrag vorbereiten und Zahlen brauchen, die vor der Geschäftsleitung bestehen, ist ein kurzes Gespräch über das System und die aktuellen Blocker der schnellste Einstieg.