Viele Unternehmen stehen heute vor derselben Herausforderung: Zentrale Anwendungen funktionieren zwar noch, basieren aber auf Technologien, Architekturen und Konzepten, die teilweise Jahrzehnte alt sind. Selbst frühe Webanwendungen aus den 2000er-Jahren haben inzwischen ein Alter erreicht, in dem Wartbarkeit, Sicherheit und Erweiterbarkeit zunehmend zum Problem werden. Genau mit dieser Situation beschäftigt sich Robert Schmelzer in seinem Beitrag „Softwaremodernisierung: Sechs Empfehlungen für erfolgreiche Transformationen“ auf heise developer.
Seine zentrale Aussage ist dabei ebenso einfach wie wichtig: Softwaremodernisierung darf kein Selbstzweck sein. Bevor über Frameworks, Cloud-Plattformen oder eine neue Programmiersprache gesprochen wird, muss geklärt sein, welches konkrete Problem die Modernisierung eigentlich lösen soll.
Der Artikel formuliert daraus sechs Empfehlungen für größere Modernisierungsvorhaben. Viele davon erscheinen zunächst selbstverständlich – in der Praxis werden sie jedoch erstaunlich häufig missachtet.
Warum wird Software überhaupt modernisiert?
Bevor der Autor zu seinen eigentlichen Empfehlungen kommt, unterscheidet er vier wesentliche Treiber einer Modernisierung.
1. Erhaltung der Betriebsfähigkeit
Manchmal funktioniert eine Anwendung fachlich weiterhin einwandfrei, aber ihre technische Basis wird zum Problem.
Typische Gründe sind:
- nicht mehr unterstützte Frameworks,
- veraltete Bibliotheken,
- ausgelaufene Betriebssysteme,
- fehlende Sicherheitsupdates oder
- obsolete Laufzeitumgebungen.
In solchen Fällen soll die Funktionalität weitgehend erhalten bleiben, während die technische Basis erneuert wird. Gerade hier sieht der Autor auch Potenzial für KI-gestützte Werkzeuge.
2. Neue nichtfunktionale Anforderungen
Eine Anwendung kann fachlich funktionieren und trotzdem technisch nicht mehr tragfähig sein.
Neue Anforderungen an beispielsweise:
- Sicherheit,
- Datenschutz,
- Skalierbarkeit,
- Architektur oder
- Betriebsmodelle
können eine grundlegende Überarbeitung notwendig machen.
Als Beispiel nennt der Artikel klassische Desktop- oder 2-Tier-Anwendungen mit direktem Datenbankzugriff. In solchen Fällen kann eine neue Architektur erforderlich werden, die bis hin zu einer vollständigen Neuimplementierung reicht.
3. Neue funktionale Anforderungen
Ein weiterer Treiber sind neue Geschäftsanforderungen, die sich nur noch schwer in bestehende Systeme integrieren lassen.
Ursachen können technische Grenzen, schlechte Wartbarkeit oder fehlendes Wissen über die Altanwendung sein. Hier bietet sich häufig eine schrittweise Modernisierung an, bei der neue Komponenten nach und nach in das bestehende System integriert werden.
4. Strategische Modernisierung
Nicht immer gibt es bereits ein konkretes technisches Problem.
Unternehmen modernisieren Systeme auch strategisch, um auf zukünftige Entwicklungen vorbereitet zu sein. Aktuell nennt der Autor insbesondere die Vorbereitung auf KI-Anwendungen. In früheren Jahren waren beispielsweise Mobile-Anwendungen und API-Ökosysteme vergleichbare Treiber.
In der Praxis treten diese Motivationen natürlich häufig gemeinsam auf.
Software als Anlagegut betrachten
Eine interessante Analogie des Artikels ist die Betrachtung von Software als Anlagegut.
Maschinen, Gebäude oder Produktionsanlagen benötigen regelmäßige Wartung und müssen irgendwann ersetzt oder grundlegend erneuert werden. Bei Software wird dagegen häufig erwartet, dass eine einmal entwickelte Anwendung praktisch unbegrenzt weiterbetrieben werden kann.
Der Autor argumentiert, dass auch Software über ihre Lebensdauer kontinuierliche Investitionen benötigt. Wartung allein bedeutet dabei noch keine Modernisierung. Wird über viele Jahre ausschließlich der aktuelle Betrieb gesichert, entsteht langfristig ein immer größerer Modernisierungsbedarf.
Dieser Gedanke ist für mich einer der stärksten Punkte des Artikels.
Technische Schulden verschwinden nicht dadurch, dass eine Anwendung weiterhin funktioniert. Sie werden lediglich weniger sichtbar – bis eine notwendige Änderung plötzlich sehr teuer wird.
Empfehlung 1: Modernisierung iterativ durchführen
Die erste Empfehlung lautet:
Modernisierung sollte in kleinen, nutzbaren Schritten erfolgen.
Große Transformationsprojekte besitzen ein erhebliches Risiko. Statt über mehrere Jahre eine komplette neue Lösung zu entwickeln und sie anschließend auf einen Schlag einzuführen, empfiehlt der Autor eine Abfolge kleiner Iterationen, die jeweils einen nachvollziehbaren Mehrwert schaffen.
Das hat mehrere Vorteile:
- Ergebnisse werden schneller sichtbar,
- Fehler in der Strategie werden früher erkannt,
- Anforderungen können angepasst werden,
- Nutzer erhalten früher neue Funktionen,
- das Projektrisiko sinkt.
Für viele Legacy-Systeme bedeutet das beispielsweise, einzelne Funktionen oder Dienste schrittweise aus einer bestehenden Anwendung herauszulösen.
Empfehlung 2: Eine klare Vision und Mission definieren
Modernisierungsprojekte erzeugen täglich viele kleine technische und fachliche Entscheidungen.
Soll eine Funktion übernommen werden?
Soll ein Prozess verändert werden?
Soll das neue System genauso funktionieren wie das alte?
Soll eine technische Abkürzung akzeptiert werden?
Ohne ein gemeinsames Ziel werden solche Entscheidungen schnell inkonsistent.
Deshalb empfiehlt der Autor eine klar formulierte Projektvision und Mission, an der Entscheidungen ausgerichtet werden können.
Das klingt zunächst nach klassischem Projektmanagement, hat aber gerade bei lang laufenden Modernisierungsvorhaben eine enorme Bedeutung.
Die Frage sollte nicht lauten:
„Wie bauen wir die alte Anwendung mit neuer Technologie nach?“
Sondern eher:
„Welches Problem soll das zukünftige System besser lösen?“
Empfehlung 3: Anforderungen konsequent priorisieren
Einer der häufigsten Fehler bei Modernisierungsprojekten besteht darin, jede Funktion der Altsoftware übernehmen zu wollen.
Das Ergebnis ist dann möglicherweise technisch modern – aber genauso kompliziert wie zuvor.
Der Artikel argumentiert deshalb für eine Triage der Anforderungen. Bestehende Funktionen sollten nicht automatisch Bestandteil des neuen Systems werden. Stattdessen müssen sie bewertet und priorisiert werden.
Besonders interessant ist dabei der Vorschlag, Entscheidungen mit realen Daten aus der bestehenden Anwendung zu unterstützen.
Beispielsweise können:
- Log-Dateien,
- Transaktionsdaten,
- Nutzungsstatistiken oder
- Datenbankauswertungen
zeigen, welche Funktionen tatsächlich genutzt werden.
Der Autor berichtet aus seiner Projekterfahrung sogar von Funktionen, die von Fachabteilungen als geschäftskritisch bezeichnet wurden, in Produktionssystemen tatsächlich aber kaum genutzt wurden.
Das ist ein wichtiger Punkt: Modernisierung ist auch eine Gelegenheit zum Aufräumen.
Empfehlung 4: Klare Domänengrenzen schaffen
Über viele Jahre wachsen Anwendungen häufig weit über ihre ursprüngliche Aufgabe hinaus.
Eine zusätzliche Funktion wird schnell eingebaut, weil es gerade einfacher ist.
Später kommt noch eine weitere hinzu.
Irgendwann übernimmt ein einzelnes System Aufgaben, die eigentlich mehreren unterschiedlichen fachlichen Bereichen zuzuordnen wären.
Der Artikel warnt genau vor dieser schleichenden Verwässerung von Domänengrenzen.
Bei einer Modernisierung sollte deshalb klar definiert werden:
- Wer sind die Benutzer?
- Welche Geschäftsprozesse unterstützt das System?
- Welche Geschäftsobjekte gehören dazu?
- Wo beginnt und endet die Verantwortung der Anwendung?
- Welche Funktionen gehören eigentlich in andere Systeme?
Der Autor empfiehlt unter anderem Personas und Prozessdarstellungen, um diese Abgrenzung verständlich zu dokumentieren.
Gerade bei größeren Unternehmensanwendungen erinnert dieser Ansatz stark an Konzepte aus Domain-Driven Design.
Empfehlung 5: Das Altsystem selbst als Dokumentation verwenden
Bei sehr alten Anwendungen gibt es häufig ein grundlegendes Problem:
Niemand weiß mehr genau, wie das System vollständig funktioniert.
Die ursprünglichen Entwickler sind möglicherweise längst nicht mehr im Unternehmen und vorhandene Dokumentationen sind unvollständig oder veraltet.
Der Artikel spricht hier treffend von „Ahnenforschung“.
Statt sich ausschließlich auf vorhandene Dokumentation zu verlassen, sollte das bestehende System selbst untersucht werden.
Informationsquellen sind beispielsweise:
- Quellcode,
- Benutzeroberflächen,
- Screenshots,
- APIs,
- Datenbankstrukturen,
- erzeugte Dokumente,
- Berichte und
- Schnittstellen.
Letztlich ist insbesondere der Quellcode eine wichtige Quelle dafür, was die Anwendung tatsächlich tut. Der Autor sieht auch hier einen sinnvollen Einsatzbereich für moderne LLMs, die dabei helfen können, größere Codebasen zu analysieren und Zusammenhänge zu erklären.
Ebenso wichtig: Entscheidungen darüber, welche Funktionen bewusst nicht übernommen werden, sollten dokumentiert werden.
Empfehlung 6: „Show early, show often“
Die letzte Empfehlung richtet den Blick auf die zukünftigen Nutzer.
Menschen können sich eine neue Anwendung anhand von Anforderungslisten und abstrakten Dokumenten häufig nur schwer vorstellen.
Deshalb sollten Prototypen und funktionsfähige Teile möglichst früh gezeigt werden.
Der Artikel fasst dieses Prinzip als:
„Show early, show often.“
zusammen.
Kurze Feedback-Zyklen haben gleich mehrere Vorteile:
- Anwender können frühzeitig Einfluss nehmen,
- falsche Annahmen werden schnell sichtbar,
- Akzeptanzprobleme werden früher erkannt,
- Entwickler erhalten konkreteres Feedback,
- Nutzer werden schrittweise auf Veränderungen vorbereitet.
Gerade bei Software, die zentrale Arbeitsprozesse verändert, ist das mindestens genauso wichtig wie die technische Architektur.
Die sechs Empfehlungen zusammengefasst
Der Artikel lässt sich auf sechs zentrale Grundsätze reduzieren:
- Iterativ modernisieren statt jahrelang im Verborgenen neu zu entwickeln.
- Eine klare Vision und Mission definieren.
- Anforderungen priorisieren und Entscheidungen mit Daten untermauern.
- Klare fachliche Domänengrenzen schaffen.
- Quellcode, Benutzeroberflächen und andere Bestandssysteme als Informationsquellen nutzen.
- Neue Lösungen früh und regelmäßig den Anwendern zeigen.
Die Infografik auf Seite 8 des Artikels fasst genau diese sechs Punkte noch einmal kompakt zusammen.
Meine kritische Einordnung
Die Empfehlungen sind aus meiner Sicht insgesamt sehr praxisnah. Besonders positiv ist, dass der Artikel Modernisierung nicht primär als Technologieproblem betrachtet.
Es geht nicht darum, eine alte Java-Anwendung unbedingt durch das neueste Framework zu ersetzen oder eine Desktop-Anwendung allein deshalb in die Cloud zu verlagern, weil Cloud-Technologien aktuell populär sind.
Die entscheidende Frage lautet vielmehr:
Warum modernisieren wir überhaupt?
Genau diese Perspektive verhindert viele klassische Fehlentscheidungen.
Stärke 1: Der Artikel stellt die Fachlichkeit vor die Technologie
Besonders überzeugend ist die konsequente Orientierung an Geschäftsprozessen, Anforderungen und tatsächlicher Nutzung.
Ein neues Framework löst keine unklaren Prozesse.
Microservices lösen keine falsch geschnittenen Domänen.
Die Cloud beseitigt keine unnötigen Funktionen.
Wer eine technisch neue Anwendung mit denselben strukturellen Problemen des Altsystems baut, hat zwar neue Technologien eingeführt, aber keine erfolgreiche Modernisierung durchgeführt.
Diese Trennung macht der Artikel sehr deutlich.
Stärke 2: Daten statt Bauchgefühl
Auch die Empfehlung, Nutzung und Relevanz bestehender Funktionen anhand realer Daten zu überprüfen, halte ich für sehr wertvoll.
Gerade bei langjährigen Unternehmensanwendungen entstehen zahlreiche Sonderfälle und Funktionen, deren ursprünglicher Zweck möglicherweise längst verschwunden ist.
Wer jede historische Funktion ungeprüft übernimmt, übernimmt damit auch Jahrzehnte gewachsener Komplexität.
Modernisierung sollte daher immer auch Vereinfachung bedeuten.
Stärke 3: Iteratives Vorgehen reduziert Risiken
Die Warnung vor jahrelangen Big-Bang-Neuentwicklungen ist ebenfalls berechtigt.
Ein Projekt, das erst nach zwei oder drei Jahren erstmals mit realen Benutzern konfrontiert wird, hat über diesen gesamten Zeitraum möglicherweise falsche Annahmen verfolgt.
Kleine, produktiv nutzbare Schritte liefern dagegen kontinuierlich Feedback.
Was mir im Artikel fehlt
Die sechs Empfehlungen bilden eine sehr gute organisatorische und fachliche Grundlage. Einige technische Aspekte einer Softwaremodernisierung werden jedoch nur am Rand behandelt.
Aus meiner Sicht sollten insbesondere vier weitere Themen explizit berücksichtigt werden.
1. Eine Migrationsstrategie für den Parallelbetrieb
Bei großen Legacy-Systemen ist die technische Frage entscheidend, wie Alt- und Neusystem während der Übergangsphase zusammenarbeiten.
Eine komplette Umschaltung an einem bestimmten Stichtag ist häufig riskant.
Interessant wären deshalb beispielsweise Konzepte wie:
- Strangler-Fig-Pattern,
- schrittweise Extraktion einzelner Funktionen,
- Adapter zwischen Alt- und Neusystem,
- API-Fassaden,
- paralleler Betrieb und
- kontrollierte Datenmigration.
Gerade wenn eine Modernisierung – wie im Artikel empfohlen – iterativ durchgeführt wird, braucht man eine technische Architektur, die genau diesen Parallelbetrieb ermöglicht.
2. Automatisierte Tests
Je weniger man über ein Legacy-System weiß, desto wichtiger wird eine automatisierte Absicherung seines tatsächlichen Verhaltens.
Vor einer Migration können beispielsweise Characterization Tests erstellt werden.
Sie dokumentieren nicht unbedingt, wie die Anwendung theoretisch funktionieren sollte, sondern zunächst, wie sie tatsächlich funktioniert.
Gerade bei jahrzehntealten Geschäftsregeln kann das entscheidend sein.
3. Observability und messbare Erfolgskriterien
Wenn eine Modernisierung eine klar definierte Motivation besitzen soll, sollten daraus auch messbare Ziele entstehen.
Beispiele könnten sein:
Deploymentdauer:
2 Stunden → 10 Minuten
Releasehäufigkeit:
monatlich → wöchentlich
Antwortzeit:
1,5 Sekunden → < 500 ms
Sicherheitsupdates:
mehrere Wochen → wenige Tage
Builddauer:
25 Minuten → 8 Minuten
Damit lässt sich später objektiv beurteilen, ob die Modernisierung tatsächlich einen Vorteil gebracht hat.
4. Rollback und Fehlerszenarien
Jede Migration kann scheitern.
Eine Modernisierungsstrategie sollte deshalb nicht nur beantworten:
„Wie bringen wir das neue System produktiv?“
sondern auch:
„Was passiert, wenn es nicht funktioniert?“
Rollback-Mechanismen, Datenkompatibilität, Backups und Wiederherstellungsstrategien gehören aus meiner Sicht deshalb ebenfalls zu einer vollständigen Modernisierungsstrategie.
Und welche Rolle spielt KI?
Der Artikel erwähnt mehrfach den Einsatz moderner KI-Werkzeuge bei der Analyse und Modernisierung bestehender Systeme. Besonders beim Verständnis großer Codebasen können aktuelle LLMs hilfreich sein.
Das halte ich für einen zunehmend wichtigen Aspekt.
Werkzeuge wie GitHub Copilot, Codex oder andere Coding Agents können beispielsweise:
- unbekannten Legacy-Code erklären,
- Abhängigkeiten suchen,
- Geschäftslogik identifizieren,
- Tests erzeugen,
- wiederkehrenden Code migrieren,
- Dokumentation erstellen,
- mögliche Refactorings vorschlagen.
Allerdings verändert KI das grundlegende Problem nicht.
Ein KI-Agent kann sehr schnell schlechten Code in eine neue Technologie übertragen. Wenn vorher nicht geklärt wurde, welche Funktionen überhaupt benötigt werden und wie die zukünftige Architektur aussehen soll, automatisiert man möglicherweise lediglich die Übernahme technischer Schulden.
Auch mit KI gilt deshalb:
Erst verstehen, dann entscheiden, dann migrieren.
Fazit
Der Artikel von Robert Schmelzer liefert keine technische Schritt-für-Schritt-Anleitung für eine Legacy-Migration – und genau darin liegt seine Stärke.
Er konzentriert sich auf die Fragen, die häufig vor der eigentlichen technischen Umsetzung geklärt werden müssen.
Besonders wichtig erscheinen mir dabei drei Gedanken:
Modernisierung braucht ein konkretes Ziel.
Nicht jede Funktion eines Altsystems muss übernommen werden.
Eine große Transformation sollte aus vielen kleinen, überprüfbaren Schritten bestehen.
Ich würde die sechs Empfehlungen deshalb um eine technische Ebene ergänzen:
Warum modernisieren?
↓
Vision und Ziele
↓
Anforderungen analysieren
↓
Domänen definieren
↓
Legacy-System verstehen
↓
Migrationsstrategie entwickeln
↓
Automatisierte Tests
↓
Iterativ migrieren
↓
Nutzerfeedback
↓
Messen und verbessern
Wer eine Softwaremodernisierung ausschließlich als Austausch alter Technologien betrachtet, wird wahrscheinlich nur ein neues Legacy-System bauen.
Eine erfolgreiche Modernisierung bedeutet dagegen, fachliche Anforderungen, Architektur, Entwicklungsprozesse und Nutzer gemeinsam weiterzuentwickeln.
Und vielleicht ist genau das die wichtigste Erkenntnis des Artikels: Softwaremodernisierung ist weniger ein einzelnes IT-Projekt als ein kontrollierter Veränderungsprozess.
Grundlage dieses Beitrags ist der Artikel „Softwaremodernisierung: Sechs Empfehlungen für erfolgreiche Transformationen“ von Robert Schmelzer, erschienen am 12. August 2026 bei heise developer.