Was kostet eine Legacy-Modernisierung? Kostentreiber, Spannen und der Business Case für Geschäftsführung und Vorstand

Die Frage kommt in jedem Erstgespräch, meist von der Geschäftsführung: Was wird das kosten? Eine einzelne Zahl ist darauf die schlechteste Antwort. Sie ist entweder so hoch, dass das Vorhaben stirbt, oder so niedrig, dass es nach einem Jahr Nachforderungen gibt. Eine gute Antwort besteht aus den Treibern, die die Zahl bestimmen, aus einer Spanne mit Begründung und aus einem Budget je Phase.

Dieser Artikel zeigt, woran die Kosten einer Modernisierung hängen und welche Spannen ich in Projekten sehe. Daraus entsteht ein Business Case, den Finance prüfen kann. Der Artikel ergänzt die Business-Case-Tabelle und die Budgetvorlage, die Sie dort ohne Registrierung herunterladen können.

Sieben Treiber, die den Umfang bestimmen

Der Umfang des Quellcodes ist ein schwacher Indikator für die Kosten. Zwei Systeme mit gleich vielen Zeilen können sich im Aufwand um den Faktor fünf unterscheiden. Den Unterschied machen sieben Treiber.

1. Datenmigration. Datenvolumen, Datenqualität, Historie und Nachweispflichten bestimmen, ob die Übernahme ein Skript oder ein eigenes Teilprojekt ist. Der Artikel zur Datenmigration bei der Ablösung eines Kernsystems beschreibt die Muster.
2. Schnittstellen. Jede Verbindung zu einem anderen System muss verstanden, nachgebaut und mit dem Partner getestet werden. Schnittstellen zu externen Partnern kosten am meisten, weil deren Zeitpläne nicht Ihre sind.
3. Testabdeckung. Ohne automatisierte Tests wird jede Änderung am Altsystem von Hand geprüft. Vor der Migration müssen deshalb Tests entstehen, die das heutige Verhalten festhalten. Dieser Posten fehlt in fast jeder ersten Schätzung.
4. Parallelbetrieb. Solange Alt und Neu laufen, zahlen Sie doppelt und setzen fachliche Änderungen doppelt um. Die Laufzeit des Parallelbetriebs ist der Posten mit der größten Streuung.
5. Fachliche Klärung. In einem alten System stecken Regeln, die niemand mehr begründen kann. Jede davon braucht eine Entscheidung des Fachbereichs. Diese Zeit gehört in das Budget des Fachbereichs. Wie viele solcher Regeln es gibt, zeigt die Architektur-Rekonstruktion mit KI-Agenten vorab.
6. Teamkapazität und Wissen. Das interne Team hat ein Tagesgeschäft. Was es für die Modernisierung nicht leisten kann, wird extern eingekauft oder verschiebt den Zeitplan. Dazu kommt die Lernkurve auf der neuen Plattform.
7. Betriebswechsel. Eine neue Plattform braucht Monitoring, Bereitschaft, Sicherheitsprüfungen und in regulierten Häusern neue Nachweise. Diese Kosten laufen nach dem Projekt weiter.

Welche Spannen realistisch sind

Für die technische Migration einer .NET-Anwendung auf modernes .NET nenne ich auf der Seite zur .NET-Migration Spannen, die sich in Projekten bestätigt haben. Dort ist der Codeumfang ein brauchbarer Anhaltspunkt, weil Fachlogik und Datenmodell bleiben, wie sie sind.

Diese Zahlen gelten für den technischen Wechsel der Plattform. Ein Neubau der Oberfläche, etwa von WebForms nach React, ist damit nicht abgedeckt. Welche Größenordnung dann gilt, zeigt der Praxisbericht zur WebForms-Modernisierung. Ein Modernisierungsprogramm für ein Kernsystem ist größer. Assessment, Strategie und Projektstart liegen in meinen Angeboten zwischen 25.000 und 75.000 Euro. Die Umsetzung ist davon getrennt. Datenmigration, Parallelbetrieb, Fachbereichszeit und Betriebswechsel kommen dazu. Davon zu unterscheiden ist das Initial-Assessment für eine reine .NET-Migration auf der Migrationsseite, das deutlich kleiner ausfällt.

Für die Datenmigration eines Kernsystems nennt der Modernisierungsleitfaden als Orientierung 200.000 bis 800.000 Euro, abhängig von Datenvolumen und Historie. Spannen je Treiber lassen sich erst nach dem Assessment seriös angeben, weil erst dann Schnittstellen gezählt und Testlücken gemessen sind. Bei Kernsystemen mit langer Historie und vielen Schnittstellen bewegen sich solche Programme über mehrere Jahre im siebenstelligen Bereich. Zum Vergleich: Dieselben Häuser zahlen häufig jedes Jahr sechs- bis siebenstellige Beträge an einen Dienstleister für den Weiterbetrieb, ohne dass neue Funktionen entstehen.

Die Posten, die in der ersten Schätzung fehlen

Wenn eine Modernisierung teurer wird als geplant, fehlen in der ersten Schätzung meist dieselben Posten.

1. Zeit des Fachbereichs für Klärung, Abnahme und Schulung. In Personentagen schätzen und mit der Bereichsleitung vereinbaren.
2. Funktionen, die während der Modernisierung nicht gebaut werden. Diese Opportunitätskosten stehen als Text in der Vorstandsvorlage. In der Tabelle haben sie keinen Platz, weil sie keine Auszahlung sind.
3. Ein Parallelbetrieb, der länger läuft als geplant. Rechnen Sie das vorsichtige Szenario mit der doppelten Laufzeit.
4. Sicherheitsprüfungen, Freigaben und regulatorische Nachweise für die neue Plattform. In Finanzunternehmen kommt auf der Seite des Weiterbetriebs die jährliche Risikobewertung für Altsysteme nach der DORA-Verordnung hinzu.
5. Eine Reserve für Abhängigkeiten, die erst im Code sichtbar werden. Ohne Reserve ist jede Abweichung ein Nachtrag.

Vier Schätzfehler, die ich immer wieder sehe

1. Interne Kapazität als Einsparung zählen. Wenn das Team nach der Modernisierung schneller liefert, ist das wertvoll. Eine Auszahlung spart es erst, wenn Ausgaben tatsächlich entfallen. Weisen Sie frei werdende Kapazität getrennt aus.
2. Den Parallelbetrieb mit null Monaten ansetzen. Jede schrittweise Ablösung hat einen Parallelbetrieb. Wer ihn nicht plant, finanziert ihn aus der Reserve.
3. Zusatzerlöse als sichere Zahlung einrechnen. Neue Funktionen können Umsatz bringen. Bis dahin sind sie ein Szenario mit Eintrittswahrscheinlichkeit und werden getrennt ausgewiesen.
4. Einen Punktwert statt einer Spanne nennen. Ein Punktwert suggeriert eine Genauigkeit, die niemand hat. Drei Szenarien mit benannten Annahmen sind für Finance besser prüfbar und für Sie leichter zu verteidigen.

So füllen Sie die Business-Case-Tabelle

Die Tabelle vergleicht drei Optionen über denselben Zeitraum: Weiterbetrieb mit Absicherung, schrittweise Modernisierung und Ersatz. Jede Option wird in einem vorsichtigen, einem erwarteten und einem günstigen Szenario gerechnet. Die Datei enthält die Zeilen für das vorsichtige Szenario. Für die beiden anderen kopieren Sie die Zeilen und ändern das Szenario. Je Kostenposition ist die Kostenart vorgegeben: einmalig, laufend oder Übergang. Einmalige Kosten tragen Sie als Einmalbetrag ein, laufende und Übergangskosten als Betrag pro Monat mit der Anzahl der Monate. Dazu kommt, ob der Betrag eine Auszahlung oder gebundene interne Kapazität ist, woher die Zahl stammt, welche Annahme dahinter steht und wer sie verantwortet.

Gesamtkosten einer Option sind Einmalaufwand plus laufende Kosten im Betrachtungszeitraum plus Übergangsaufwand. Als Kostendifferenz gilt der Unterschied zwischen Weiterbetrieb und der jeweiligen Alternative. Zusatzerlöse bleiben außerhalb dieser Rechnung und stehen als eigenes Szenario daneben.

Drei Hinweise aus der Anwendung der Tabelle.

1. Wählen Sie einen Zeitraum, den Finance akzeptiert. Meist sind das fünf Jahre.
2. Tragen Sie für den Weiterbetrieb auch Updates, Tests, Dokumentation und den Abbau von Wissensabhängigkeiten ein. Auch Weiterbetrieb kostet.
3. Notieren Sie zu jeder Annahme Quelle, Verantwortlichen und Datum. So lässt sich die Tabelle in der nächsten Budgetrunde fortschreiben.

Was in die Vorstandsvorlage gehört

Die Budgetvorlage ist bewusst zweiseitig. Sie beantragt die Freigabe einer einzelnen Phase und zeigt das Gesamtprogramm als Rahmen daneben. Die Vorlage hat sechs Abschnitte.

1. Die beantragte Entscheidung: Betrag, interne Personentage und das Ergebnis, das diese Phase liefert. Die nächste Phase bekommt eine eigene Freigabe.
2. Der geschäftliche Anlass mit Beleg und den Folgen eines Aufschubs.
3. Die drei Optionen im gleichen Betrachtungszeitraum.
4. Die Empfehlung mit den Annahmen, unter denen sie sich ändern würde.
5. Der Pilot mit Abnahmekriterium, Messzeitraum und Rückfallplan.
6. Die Verantwortlichen für Entscheidung, Umsetzung, Betrieb und Finance.

Ein Vorstand entscheidet schneller, wenn er sieht, welche Annahme die Investition trägt und woran ein Abbruch erkannt würde. Eine Gesamtsumme mit Renditeversprechen leistet das nicht.

Die erste Phase ist fast immer ein Assessment mit Pilotplan. Es kostet einen Bruchteil des Programms und liefert die Zahlen, die den Rest der Tabelle belastbar machen. Wie ein solches Assessment abläuft, steht in der Leistungsbeschreibung zur Legacy-Modernisierung.

Nächster Schritt

Die Vorlagen enthalten Entscheidungsmatrix, Business-Case-Tabelle, Budgetvorlage und Review-Checkliste. Für technische Schulden im laufenden Betrieb ohne Ablösung passt das Business-Case-Framework für Technical Debt besser. Für die Abstimmung einer Vorlage mit Vorstand und Finance bietet sich das CTO-Sparring an.