Warum Risikoreduktion und Wirtschaftlichkeit wichtiger sind als neue Technologien
Die meisten Modernisierungsprojekte machen Software schlechter, nicht besser.
Das ist keine provokante These zur Einleitung. Es ist eine nüchterne Beobachtung: Systeme werden abgelöst, weil sie alt aussehen – nicht weil sie nicht funktionieren. Das Neue kostet mehr, bringt neue Abhängigkeiten, dauert länger als geplant. Und am Ende läuft dasselbe Geschäft auf anderem Stack.
Modernisierung ist kein Ziel. Risikoreduktion und Wirtschaftlichkeit sind es.
Das klingt nach einem Satz, dem alle zustimmen würden. Aber in der Praxis handeln die wenigsten danach.
Wer Modernisierung treibt – und warum
Drei Gruppen bringen Modernisierungsentscheidungen voran, selten aus denselben Gründen.
Entwickler – und ich schließe mich hier ein – wollen sauberen Code, aktuelle Frameworks, bessere Developer Experience. Das sind legitime Anliegen. Aber sie rechtfertigen keinen vollständigen Systemaustausch. Ich kenne das Muster aus eigener Erfahrung. Joel Spolsky hat es 2000 am Beispiel von Netscape beschrieben – damals war es der größte strategische Fehler des Unternehmens. Fred Brooks nannte es den „Second System Effect”. Viele Modernisierungen passieren, weil Entwickler wechseln und das Neue lieber aufsetzen als das Alte verstehen.
Berater verkaufen Transformation. Migrations-Roadmaps, Plattformwechsel, Cloud-Strategien – das ist ihr Geschäft. Der Anreiz liegt im Projektumfang, nicht im Ergebnis. „Migration als Default” ist kein technisches Urteil, es ist ein Geschäftsmodell.
Management will keine veraltete Infrastruktur auf dem Risikoradar. „Technische Schulden” klingen bedrohlich. Modernisierung fühlt sich nach Kontrolle an. Und sie liest sich gut im Statusbericht.
Alle drei haben gute Absichten. Das Muster trotzdem: Die Kosten des Bestehenden werden überschätzt, die Kosten des Neuen unterschätzt.
Was wirklich in Unternehmen läuft
Die Excel-Datei, die seit 2014 jeden Monat die Abrechnung fährt. Das 2.000-Zeilen-Skript, das nur einer versteht – und das trotzdem nie ausfällt. Das Tool ohne Namen, das trotzdem das wichtigste System ist.
Wer in Unternehmen arbeitet, kennt das. Diese Lösungen wurden gebaut, um ein konkretes Problem zu lösen. Sie sind bezahlt, akzeptiert, in Prozesse eingebettet. Sie sind nicht schön. Sie sind zuverlässig.
Das Problem mit ihnen ist meistens nicht ihr Verhalten. Das Problem ist, wie sie aussehen.
Das eigentliche Problem: falsche Bewertungsmaßstäbe
Modernisierung wird fast immer gegen das Bild einer idealen Neuimplementierung gemessen – sauber, dokumentiert, testabgedeckt, mit aktuellen Technologien. Das ist kein realistischer Vergleich.
Der realistische Vergleich ist: bestehende Lösung mit bekannten Problemen gegen neue Lösung mit unbekannten.
Bekannte Probleme kann man managen. Unbekannte überraschen. Modernisierung ersetzt oft bekannte Probleme durch neue, die noch keiner versteht – und das mit dem vollen Migrationsrisiko obendrauf.
4 Fragen, die wirklich entscheiden
Nicht „Ist die Technologie aktuell?” Sondern:
Funktioniert das Ding? Läuft es stabil, liefert es den richtigen Output, fällt es im Alltag auf – oder läuft es einfach? Wenn es läuft: kein unmittelbarer Handlungsdruck.
Entstehen messbare Kosten? Zeitverluste, Fehler mit finanziellen Folgen, manuelle Workarounds, Abhängigkeit von einer einzigen Person? Wenn nicht: Das ist ein technisches Projekt, kein wirtschaftliches.
Welche neuen Risiken entstehen? Jeder Systemwechsel schafft neue Abhängigkeiten – Hersteller, Lizenzmodelle, Cloud-Plattformen, Schulungsaufwand. Die entscheidende Frage: Sind die neuen Risiken geringer als die alten? Wenn nein, verschlechtert Modernisierung die Gesamtsituation.
Lässt es sich stabilisieren statt ersetzen? Dokumentation, Tests an kritischen Stellen, Refactoring, Wissensverteilung – das reduziert Ausfallrisiken und Personenabhängigkeit, ohne einen vollständigen Systemwechsel.
Ein konkretes Negativbeispiel
Ein mittelständisches Unternehmen ersetzt eine intern gewachsene Lösung durch eine SaaS-Plattform. Begründung: zu viel Legacy, zu viel Wissen liegt bei einer Person, der Code ist unleserlich.
Ergebnis nach zwei Jahren: monatliche Lizenzkosten im vierstelligen Bereich, Prozesse mussten an die neue Plattform angepasst werden statt umgekehrt, neue Abhängigkeit von einem Anbieter, dessen Roadmap sich von den eigenen Anforderungen entfernt hat. Das Know-how über die Geschäftslogik steckt jetzt im Konfigurationsmodell eines Dritten.
Die alte Lösung hatte echte Probleme. Die neue hat andere – und ist teurer.
Stabilisieren statt ersetzen
In vielen Fällen ist der bessere Schritt: das Bestehende tragfähig machen. Nicht schön. Nicht modern. Sondern sicher, verstanden, dokumentiert.
Gezielte Tests an den kritischen Stellen. Eine Dokumentation des Geschäftswissens, das in den Makros steckt. Ein zweiter Mensch, der das Skript versteht. Das sind keine glamourösen Projekte. Aber sie reduzieren echte Risiken – ohne neue zu schaffen.
Stabile Systeme sterben selten an Technik, sondern an Entscheidungen.
Einordnung
Modernisierung ist oft ein Karriereprojekt, kein Unternehmensprojekt. Das ist kein Vorwurf – es ist ein Muster, das man kennen sollte, bevor man eine Entscheidung trifft.
Die Frage ist nie: „Ist das modern genug?” Sie ist immer: „Rechtfertigt der Mehrwert den Aufwand und das Risiko?”
Entwickler, die das verstehen, treffen bessere Entscheidungen – nicht weil sie weniger ambitioniert sind, sondern weil sie den Kontext kennen.
Modernisierung ist kein Ziel. Risikoreduktion und Wirtschaftlichkeit sind es.