Software-Modernisierung: Strategien und Vorgehen

Was ist Software-Modernisierung?

Software-Modernisierung umfasst alle Maßnahmen, die eine bestehende Anwendung technisch und funktional auf einen aktuellen Stand bringen, ohne ihre bewährte Geschäftslogik aufzugeben. Das kann ein vergleichsweise einfaches Framework-Update sein, aber auch eine grundlegende Umstrukturierung der Architektur oder die Migration in eine neue Laufzeitumgebung.

Der Auslöser ist in der Regel kein einzelnes Ereignis, sondern eine Ansammlung von Symptomen: wachsende technische Schulden, steigende Wartungskosten, Schwierigkeiten bei der Rekrutierung von Entwicklern für veraltete Technologien oder das nahende End of Life eines Frameworks.

Wichtig ist die Abgrenzung: Modernisierung ist nicht dasselbe wie Neuentwicklung. Bei einer Neuentwicklung wird die bestehende Anwendung verworfen und von Grund auf neu gebaut, etwa wenn eine gewachsene Access-Datenbank abgelöst wird. Bei der Modernisierung wird das Bestehende als Ausgangspunkt genommen und gezielt verbessert. Das spart Zeit, Kosten und bewahrt die Geschäftslogik, die sich über Jahre bewährt hat. Wird die Anwendung dagegen ersetzt, folgt danach ein eigener Schritt, nämlich das Stilllegen des Altsystems.

Die Modernisierung von Software ist damit ein Baustein des Application Management, das eine Anwendung vom Betrieb bis zur Ablösung begleitet.

Wann ist Modernisierung notwendig?

Nicht jede ältere Software muss modernisiert werden. Solange sie stabil läuft, sicher ist und die Geschäftsanforderungen erfüllt, besteht kein Handlungsdruck. In der Lünendonk-Studie zur IT-Modernisierung vom Juli 2025 gaben allerdings 62 Prozent der befragten Unternehmen an, dass Teile ihrer geschäftskritischen Anwendungen den heutigen Anforderungen nicht mehr gerecht werden. Modernisierung wird dann relevant, wenn eines oder mehrere dieser Signale auftreten:

Sicherheitsrisiken. Die eingesetzten Frameworks oder Libraries haben ihr End of Life erreicht und erhalten keine Sicherheitsupdates mehr. Jeder Tag ohne Migration vergrößert das Angriffsfenster.

Steigende Wartungskosten. Wenn einfache Änderungen unverhältnismäßig viel Zeit kosten, weil der Code unübersichtlich geworden ist oder Abhängigkeiten veraltet sind, deutet das auf technische Schulden hin, die sich nur durch Modernisierung abbauen lassen.

Fachkräftemangel. Entwickler für COBOL, ältere PHP-Versionen oder proprietäre Frameworks sind schwer zu finden und teuer. Wenn die Wartung der Software an der Verfügbarkeit von Spezialisten hängt, ist das ein strukturelles Risiko.

Skalierungsprobleme. Die Anwendung ist für 50 Nutzer gebaut worden, bedient aber inzwischen 5.000. Wenn die Architektur an ihre Grenzen stößt, hilft kein Hardware-Upgrade, der Code selbst muss angepasst werden.

Compliance-Anforderungen. Neue Regularien wie NIS-2, BITV oder branchenspezifische Vorgaben erfordern Funktionen, die die bestehende Architektur nicht hergibt.

Strategien der Software-Modernisierung

Für die Software-Modernisierung haben sich in der Praxis zwei Modelle mit je sieben Strategien etabliert: Gartner nennt sieben Optionen von Encapsulate bis Replace, AWS die „7 Rs” von Retire bis Refactor. Welche Strategie die richtige ist, hängt vom Zustand der Software, dem verfügbaren Budget und den geschäftlichen Anforderungen ab. Die folgende Auswahl verbindet beide Modelle:

• Retain (Beibehalten): Die Software wird vorerst nicht verändert. Diese Strategie ist sinnvoll, wenn die Anwendung stabil läuft, keine Sicherheitsrisiken bestehen und die Modernisierung auf einen späteren Zeitpunkt verschoben werden kann. Ein professioneller Wartungsvertrag sichert in dieser Phase den laufenden Betrieb.

• Rehost (Umziehen): Die Anwendung wird unverändert in eine neue Infrastruktur verschoben, typischerweise von einem lokalen Server in die Cloud. Am Code ändert sich nichts. Der Vorteil: schnell und kostengünstig. Der Nachteil: Die grundlegenden Probleme der Software bleiben bestehen.

• Replatform (Plattformwechsel): Die Anwendung wird auf eine neue Plattform migriert, ohne die Architektur grundlegend zu verändern. Beispiel: Migration einer Datenbank von MySQL auf PostgreSQL oder der Wechsel von einem selbst betriebenen Server zu einem Managed Hosting. Moderate Kosten, moderate Wirkung.

• Refactor (Umstrukturieren): Der bestehende Code wird überarbeitet, um die Qualität zu verbessern, ohne die Funktionalität zu verändern. Ziel: bessere Lesbarkeit, geringere Komplexität, höhere Testabdeckung. Software Refactoring ist oft der erste Schritt, um eine Codebasis überhaupt modernisierungsfähig zu machen.

• Rearchitect (Neu strukturieren): Die Architektur wird grundlegend überarbeitet, etwa von einem Monolithen zu Microservices, von synchroner zu asynchroner Kommunikation oder von einer monolithischen Datenbank zu Event Sourcing. Der Aufwand ist höher als beim Refactoring, die Wirkung aber tiefgreifender.

• Rebuild (Neu bauen): Die Anwendung wird von Grund auf neu entwickelt, wobei die bestehenden Anforderungen und die Geschäftslogik als Spezifikation dienen. Das ist die teuerste und riskanteste Option, aber manchmal die einzig sinnvolle, etwa wenn der bestehende Code so veraltet ist, dass eine schrittweise Modernisierung mehr kosten würde als ein Neuanfang.

• Retire (Abschalten): Die Anwendung wird abgeschaltet, weil sie nicht mehr benötigt wird oder ihre Funktion von einer anderen Software übernommen wurde. AWS nennt als Anhaltspunkt Anwendungen, auf die 90 Tage lang keine Verbindung eingegangen ist.

Softwaremodernisierung: Dienstleistungen im Überblick

Ein Modernisierungsprojekt reicht von der Analyse des Bestands über die eigentliche Umsetzung bis zur Übergabe in einen geregelten Betrieb. Ein Anbieter kann alle Dienstleistungen der Softwaremodernisierung übernehmen oder nur einzelne, etwa ein Gutachten zum Code, bevor eine Ausschreibung entsteht. Vor der Vergabe sind deshalb zwei Fragen zu klären: was die Analyse liefern muss und wie der Auftrag vertraglich zugeschnitten wird.

Bestandsanalyse und Modernisierungsfahrplan

Zu Beginn einer Software-Modernisierung wird geprüft, welche Frameworks und Bibliotheken im Einsatz sind, welche davon keine Sicherheitsupdates mehr erhalten, wie hoch die Testabdeckung ist und welche Schnittstellen an der Anwendung hängen. Daraus entsteht eine Software-Modernisierungsstrategie, die je Komponente einen der sieben Wege festlegt und die Reihenfolge begründet. Dieser Fahrplan ist auch dann nützlich, wenn die Umsetzung später an einen anderen Dienstleister geht, weil er Angebote vergleichbar macht.

Beauftragung und Vertragsform

Wer Dienstleistungen zur Softwaremodernisierung zum Festpreis beauftragt, braucht eine belastbare Leistungsbeschreibung, und die entsteht erst mit der Bestandsanalyse. Deshalb lässt sich die Analyse gut als eigener, kleiner Auftrag vergeben, bevor über die eigentliche Modernisierung der Software entschieden wird.

In Unternehmen

Für eine Software-Modernisierung im Mittelstand bietet sich ein zweistufiges Vorgehen an: erst die Analyse zu einem festen Betrag, dann die Umsetzung als Werkvertrag auf Basis des Fahrplans. Vertraglich zu regeln sind vor allem die Nutzungsrechte am geänderten Code, die Herausgabe von Quellcode und Dokumentation und die Abnahmekriterien je Iteration.

In der öffentlichen Verwaltung

Die öffentliche Hand beschafft Dienstleistungen zur Softwaremodernisierung über die EVB-IT Erstellung. Dieser Vertragstyp regelt die werkvertragliche Erstellung und Anpassung von Software und kann die Pflege nach der Abnahme sowie die Weiterentwicklung gleich mit einschließen.

© TenMedia GmbH

Seit der Überarbeitung der EVB-IT von 2025 ist bei neuen Softwareprojekten die Entwicklung und Bereitstellung als Open Source der Standard. Bei der Anpassung vorhandener Software ermöglichen die Vertragsbedingungen die Einbeziehung von Open Source (BMDS, Einkauf von Open-Source-Software mit EVB-IT, 2025). Nach der Vergabe folgt die Umsetzung der Software-Modernisierung, schrittweise im laufenden Betrieb und mit Tests und Dokumentation als Teil des Projekts. Am Ende steht der geplante Übergang in einen laufenden Wartungsvertrag.

Was kostet Software-Modernisierung?

Die Kosten variieren erheblich: Zwischen einem Framework-Update und einer vollständigen Rearchitect-Strategie liegt ein Vielfaches. Den größten Einfluss auf die Kosten der Softwaremodernisierung hat die gewählte Strategie, danach der Zustand des Codes. Eine grobe Orientierung zu Zeitrahmen und relativem Aufwand:

Diese Angaben sind Richtwerte und hängen von der Größe und Komplexität der Anwendung ab. Eine belastbare Zahl entsteht erst nach der Analyse des Bestands, die Konditionen finden sich auf der Preisseite.

Was die Kosten treibt

Bei einer Software-Modernisierung bestimmen innerhalb der gewählten Strategie vor allem vier Faktoren den Aufwand: der Umfang des Codes, die vorhandene Testabdeckung, die Zahl der angebundenen Schnittstellen und eine nötige Datenmigration. Eine niedrige Testabdeckung erhöht die Kosten der Softwaremodernisierung bei jeder Strategie ab dem Refactoring, weil zuerst das bestehende Verhalten abgesichert werden muss.

Software-Modernisierung: Kosten des Weiterbetriebs

Entscheidend ist der Vergleich mit den Kosten des Status quo: Was kostet es, die nicht-modernisierte Software weiterzubetreiben? Steigende Wartungskosten, Sicherheitsrisiken, Produktivitätsverluste und der irgendwann unvermeidliche Notfall-Umbau müssen in die Rechnung einfließen. In der US-Bundesverwaltung fließen laut dem Rechnungshof GAO rund 80 Prozent der IT-Ausgaben in Betrieb und Wartung bestehender Systeme.

Modernisierung im laufenden Betrieb

Ein häufiges Bedenken lautet, die Anwendung lasse sich nicht monatelang abschalten. Das ist auch nicht nötig. Professionelle Modernisierung geschieht schrittweise und im laufenden Betrieb.

• Strangler Fig Pattern: Neue Komponenten werden parallel zur bestehenden Anwendung entwickelt und schrittweise eingeführt. Die alte Funktionalität wird nach und nach durch die neue ersetzt, wie bei einer Würgefeige, die langsam einen Baum umschließt. Der Vorteil: Zu jedem Zeitpunkt gibt es ein funktionierendes System. Das Risiko eines Big-Bang-Umstiegs entfällt.

• Feature Toggles: Neue Funktionalität wird parallel zum bestehenden Code implementiert und per Konfiguration aktiviert oder deaktiviert. So lassen sich neue Komponenten in der Produktion testen, ohne die bestehende Funktionalität zu gefährden.

• Iteratives Vorgehen: Die Modernisierung wird in Sprints aufgeteilt. Jeder Sprint liefert ein funktionierendes Inkrement, also eine modernisierte Komponente, eine migrierte Datenbank, eine refactored Schicht. Das Unternehmen sieht nach jedem Sprint einen Fortschritt und kann Prioritäten anpassen.

Nach der Modernisierung: Wartung sicherstellen

Modernisierung ist kein einmaliges Projekt, sondern der Auftakt zu einer neuen Phase der Softwarewartung. Die modernisierte Software braucht professionelle Wartung, um nicht binnen weniger Jahre erneut in den Zustand zu geraten, der die Modernisierung nötig gemacht hat. Eine CI/CD-Checkliste für Unternehmen prüft anschließend, ob Pipeline und Tests die neuen Anforderungen dauerhaft tragen.

Ein guter Modernisierungspartner denkt deshalb von Anfang an an die Zeit danach: Dokumentation wird während der Modernisierung erstellt, nicht nachträglich. Automatisierte Tests werden als Teil des Projekts aufgebaut. Und der Übergang in einen laufenden Wartungsvertrag wird nicht dem Zufall überlassen, sondern geplant.

Unser ausführlicher Leitfaden zur Legacy-Software-Modernisierung beschreibt Strategien und Vorgehen im Detail, den Zeitpunkt dafür bestimmt das Software End of Life.

TenMedia übernimmt bestehende Anwendungen auch im laufenden Betrieb und führt sie mit einer schrittweisen Software-Modernisierung auf einen wartbaren Stand, so geschehen bei der SaaS-Lösung für ambulante Betreuungsdienste, die während eines umfassenden Refactorings weiterlief. Die Modernisierung bestehender Software läuft nach Prüfung als Werkvertrag mit Festpreis auf Basis einer Leistungsbeschreibung. Den Betrieb danach deckt der Maintenance, Wartung und Support Service ab.