Software modernisierung: schrittweise umbauen oder neu entwickeln?

Für wen das Thema relevant ist

Eine Modernisierung wird fällig, wenn eine Software zwar noch läuft, aber zum Risiko oder zur Bremse geworden ist: Änderungen dauern unverhältnismäßig lang, die Technik wird nicht mehr unterstützt, es gibt kaum noch Entwickler, die sie kennen, oder Schnittstellen zu neuen Systemen sind kaum machbar.

Typische Auslöser (Beispiele, keine Statistik):

• Eine Excel- oder Access-Lösung ist zur unverzichtbaren Fachanwendung geworden.
• Die Anwendung läuft auf einer Version einer Programmiersprache oder Datenbank, die keine Sicherheitsupdates mehr erhält.
• Der Mitarbeiter, der alles weiß, geht in den Ruhestand.
• Ein ERP-Wechsel steht an, und die Eigenentwicklung hängt daran (siehe Schnittstellen und ERP-Anbindung).

Die Kernfrage: schrittweise modernisieren oder neu entwickeln?

Es gibt keine allgemeingültige Antwort. Die folgende Tabelle hilft, Ihre Lage einzuordnen.

Wenn die meisten Zeilen links zutreffen, spricht vieles für schrittweises Vorgehen. Bei vielen Kreuzen rechts kann ein Neubau die bessere Wahl sein. Für den Vergleich mit fertiger Software hilft der Ratgeber Individualsoftware oder Standardsoftware, denn manchmal ist die dritte Antwort, das Altsystem durch ein Standardprodukt zu ersetzen.

Die gängigen Strategien: Rehost bis Replace

Für die Einordnung gibt es in der IT eine verbreitete „R“-Systematik. Bekannt ist sie aus der Cloud-Migration; sie lässt sich auf die Modernisierung allgemein übertragen. Amazon Web Services nennt in einer Übersicht sechs Strategien. Die Bezeichnungen variieren je nach Quelle; die folgende Zuordnung orientiert sich daran.

Hinweis: AWS fasst Refactor und Re-architect zu einer Strategie zusammen. Die Trennung hier dient der Verständlichkeit.

Refactoring in einem Satz

Refactoring bezeichnet nach Martin Fowler das Umstrukturieren von Code in kleinen, abgesicherten Schritten, bei dem das äußere Verhalten gleich bleibt. Ziel ist, Software leichter verständlich und billiger änderbar zu machen. Ohne automatisierte Tests ist das riskant, weil niemand sicher sagen kann, dass das Verhalten unverändert blieb.

Das Strangler-Muster in einfachen Worten

Martin Fowler beschreibt mit dem Strangler-Fig-Muster ein schrittweises Vorgehen: Statt das Altsystem auf einen Schlag zu ersetzen, wächst das neue System um das alte herum. Neue Funktionen entstehen im neuen Teil, bestehende Funktionen werden nach und nach an dafür geeigneten Stellen herausgelöst und verlagert. Alt und Neu laufen währenddessen zusammen, über eine Übergangsarchitektur. Das Altsystem wird erst abgeschaltet, wenn nichts Wichtiges mehr darin steckt.

Der Vorteil: Jeder Schritt ist klein, das Risiko bleibt überschaubar, und der Nutzen zeigt sich früh. Der Preis: Sie betreiben zeitweise zwei Systeme und müssen Übergangslösungen bauen, die später wieder verschwinden.

Erste Schritte: Das sollten Sie vor dem Angebot klären

• Bestandsaufnahme: Welche Funktionen hat die Software wirklich, welche werden genutzt, welche nicht?
• Wissensträger: Wer kennt Fachlogik und Technik? Was ist nirgends aufgeschrieben?
• Quellcode und Zugänge: Liegen Code, Server-Zugänge, Lizenzen und Schlüssel bei Ihnen?
• Abhängigkeiten: Welche Programmiersprache, Bibliotheken, Datenbank und Betriebssystemversion laufen? Gibt es dafür noch Herstellersupport?
• Schnittstellen: Mit welchen Systemen tauscht die Software Daten aus?
• Testabdeckung: Gibt es automatisierte Tests? Falls nicht: Welche Abläufe müssen vor jeder Änderung von Hand geprüft werden?
• Daten: Wie viele Daten gibt es, wie sauber sind sie, was darf nach der Migration entfallen?
• Betriebsfenster: Wie lange darf das System im Zweifel stehen?

Die Ergebnisse gehören in ein strukturiertes Dokument. Wie man Anforderungen aufschreibt, zeigt der Ratgeber Lastenheft für Software und das Werkzeug Projekt vorbereiten.

Risiken im Bestand

Wissen in einem einzigen Kopf

Wenn nur eine Person das System versteht, ist das ein Betriebsrisiko, bevor es ein Technikproblem ist. Maßnahmen: Abläufe dokumentieren, Wissen in Gesprächen festhalten, Verhalten mit Tests beschreiben.

Laufzeitumgebungen ohne Support

Programmiersprachen und Frameworks haben Supportzeiträume. Ein Beispiel: PHP unterstützt jede Version laut php.net vier Jahre, zwei Jahre mit Fehlerkorrekturen, zwei weitere nur mit Sicherheitskorrekturen. Laut der Übersicht, abgerufen am 9. November 2026, endet der Sicherheitssupport für PHP 8.2 am 31. Dezember 2026. Prüfen Sie für Ihre eigene Technik die offizielle Supportseite des Herstellers und tragen Sie das Datum in Ihre Planung ein.

Sicherheitsupdates

Das BSI behandelt Patch- und Änderungsmanagement im IT-Grundschutz-Kompendium als eigenen Baustein (OPS.1.1.3). Wer Software ohne Sicherheitsupdates betreibt, trägt das Risiko selbst, besonders bei Systemen, die aus dem Internet erreichbar sind. Fragen Sie Ihre IT-Sicherheitsverantwortlichen, wie das in Ihrem Unternehmen geregelt ist.

Migration, Parallelbetrieb und Umschalten

• Datenmigration: Welche Daten wandern, welche werden bereinigt oder archiviert? Wer prüft die Vollständigkeit? Legen Sie Abgleichskriterien fest (Anzahl, Summen, Stichproben).
• Parallelbetrieb: Läuft das neue System zunächst neben dem alten, und wie werden Doppelerfassungen vermieden?
• Umschaltung (Cutover): Stichtag oder Etappen? Wer entscheidet, und anhand welcher Kriterien?
• Rückfallweg (Rollback): Wie kehren Sie zurück, wenn nach dem Start Fehler auftreten? Bis wann ist das möglich?

Beispielszenario: Auftragsverwaltung eines Maschinenbauers

Beispielszenario, frei erfunden und kein realer Fall. Angenommen, ein mittelständischer Betrieb in der Region Rhein-Neckar verwaltet Aufträge mit einer vor vielen Jahren selbst gebauten Anwendung. Sie läuft auf einer nicht mehr unterstützten Laufzeitumgebung, ein einzelner Mitarbeiter kennt die Preislogik, und Tests gibt es nicht.

Ein mögliches schrittweises Vorgehen:

1. Bestandsaufnahme: Funktionen und Datenflüsse erfassen, Preislogik gemeinsam mit dem Wissensträger beschreiben.
2. Absichern: Für die wichtigsten Abläufe Tests schreiben, Quellcode und Zugänge in Ihre Verwaltung überführen.
3. Plattform: Laufzeitumgebung auf eine unterstützte Version bringen (Replatform), soweit der Code es zulässt.
4. Herauslösen: Die Angebotserstellung als erstes Modul neu bauen, das Altsystem ruft sie über eine Schnittstelle auf (Strangler-Muster).
5. Parallelbetrieb: Neue Angebote entstehen im neuen Modul, Altaufträge bleiben im alten System, ein Abgleich vergleicht Summen.
6. Weitere Module: Auftragsverwaltung und Lager folgen in späteren Etappen, danach wird das Altsystem abgeschaltet.

Welche Reihenfolge in einem realen Fall sinnvoll ist, hängt von Risiko und Nutzen ab, nicht von diesem Beispiel.

Phasen und Ergebnisse, die Sie verlangen sollten

Typische Phasen: Assessment, Zielbild und Migrationsplan, Absicherung durch Tests, Umsetzung in Etappen, Parallelbetrieb, Umschaltung, Abschaltung des Altsystems, Übergabe.

Verlangen Sie von einem Dienstleister:

• einen Assessment-Bericht mit Funktionsumfang, Abhängigkeiten, Risiken und Empfehlung samt Begründung der Alternativen,
• einen Migrationsplan mit Etappen, Abhängigkeiten, Datenmigration und Abschaltkriterien,
• einen Rückfallplan für jede Umschaltung,
• Testkonzept und Testfälle für das bestehende Verhalten,
• Dokumentation, Quellcode, Zugänge und Schlüssel auf Ihren Namen,
• eine Aufstellung dessen, was das Altsystem kann und was bewusst entfällt.

Wie Sie Anbieter vergleichen, steht im Ratgeber Softwaredienstleister auswählen.

Kosten- und Zeittreiber

Seriöse Preise lassen sich ohne Prüfung des Bestands nicht nennen. Aufwand und Dauer hängen vor allem ab von:

• Umfang und Qualität des vorhandenen Codes und seiner Dokumentation,
• Testabdeckung und Aufwand, sie nachzurüsten,
• Datenmenge, Datenqualität und Migrationsregeln,
• Zahl und Art der Schnittstellen zu anderen Systemen,
• Länge des Parallelbetriebs,
• Verfügbarkeit der Wissensträger,
• Anforderungen an Ausfallsicherheit.

Mehr zur Preisstruktur steht im Ratgeber Was kostet Individualsoftware?. Wenn am Ende ein Neubau steht, hilft der Überblick zu Individualsoftware.

Betrieb nach der Modernisierung

Modernisierung ist kein Endzustand. Vereinbaren Sie, wer nach dem Start Updates einspielt, Abhängigkeiten pflegt und Supportzeiträume beobachtet. Legen Sie fest, wie oft die Dokumentation aktualisiert wird und wie Wissen im Unternehmen bleibt, damit Sie nicht erneut von einer Person abhängen.

Warnzeichen im Angebot

• Ein Festpreis für den Komplettneubau, ohne dass der Bestand angesehen wurde.
• Kein Assessment, keine Aussage zu Alternativen wie Refactoring oder Standardsoftware.
• Die Datenmigration wird nicht beschrieben oder als „Nebensache“ behandelt.
• Kein Parallelbetrieb und kein Rückfallweg.
• Der bestehende Funktionsumfang ist nicht dokumentiert, es heißt nur „wie bisher, aber neu“.
• Quellcode und Zugänge bleiben beim Dienstleister.
• Es wird versprochen, alles in einem Schritt zu ersetzen, ohne Risiken zu nennen.

Nächster Schritt

Halten Sie fest, was Ihre Software heute tut, wer sie kennt und wo die Risiken liegen. Mit dem Werkzeug Projekt vorbereiten erstellen Sie daraus eine kopierbare Beschreibung für Angebotsanfragen. Zur Struktur Ihrer Anforderungen passt der Ratgeber Lastenheft für Software.