Legacy-Software modernisieren

Code ist billig geworden. Das Wissen, das in deinem Altsystem steckt, ist es nicht.

Am 23.02.2026 veröffentlichte Anthropic einen Beitrag mit einer steilen These: Die Modernisierung von Legacy-Code sei jahrelang ins Stocken geraten, weil es mehr kostete, ihn zu verstehen, als ihn neu zu schreiben. KI-Agenten könnten genau diese Analyse übernehmen, und Teams könnten ihre COBOL-Systeme dadurch „in Quartalen statt Jahren“ modernisieren. Am selben Tag verlor die IBM-Aktie 13 Prozent, laut CIO.com der größte Tagesverlust seit Oktober 2000.

IBM antwortete mit einem eigenen Blogbeitrag. Rob Thomas, dort als Senior Vice President für Software zuständig, hielt fest: Die reine Übersetzung erfasse fast nichts von der eigentlichen Komplexität. Die stecke in allem, worauf die Anwendung läuft und womit sie verbunden ist. An beidem ist etwas dran.

Im Alltag sieht diese Komplexität unspektakulär aus. Eine Rundungsregel, auf die sich die Schnittstelle zur Buchhaltung stillschweigend verlässt. Ein Statusfeld, dessen Wert 9 seit Jahren etwas anderes bedeutet als im Handbuch. Solche Regeln stehen in keiner Dokumentation. Wer sie übersieht, merkt es erst, wenn nach der Umstellung die Zahlen nicht mehr stimmen.

Deshalb beginnt jede Modernisierung mit zwei Fragen. Welchen Weg lässt die Technik noch zu? Und wie viel Wissen musst du sichern, bevor du etwas umbaust? Geht es um eine mobile App, klärt der Beitrag App-Update oder Neubau? Store-Fristen und Stack-Fragen.

Was ist ein Legacy-System?

Ein Legacy-System ist Software, die im Unternehmen eine tragende Rolle spielt, sich aber nicht mehr sicher oder wirtschaftlich ändern lässt. Das Alter allein entscheidet nicht. Eine zehn Jahre alte Java-Anwendung mit Tests, aktueller Laufzeitumgebung und zwei Entwicklern, die sie kennen, ist gepflegte Bestandssoftware. Ein drei Jahre altes Projekt, dessen einziger Entwickler gegangen ist, kann bereits Legacy sein.

Legacy-Software hat damit drei Dimensionen: die Plattform, auf der sie läuft, die Menschen, die sie verstehen, und das Wissen, das in ihr steckt. Typische Kandidaten im Mittelstand sind PHP-Anwendungen aus den 2010er-Jahren, Access-Datenbanken mit eigener Oberfläche, Werkzeuge in Visual Basic 6 oder Delphi, Anwendungen auf älteren .NET-Framework-Versionen, AngularJS-Frontends und über Jahre gewachsene ERP-Erweiterungen.

Davon zu trennen ist technische Schuld: die Summe der Abkürzungen im Code, die jede weitere Änderung verteuert. Technische Schuld steckt in fast jeder Software und lässt sich abbauen, ohne das System zu tauschen. Legacy beschreibt den Zustand des ganzen Systems, einschließlich Betrieb und Menschen. Anwendungsmodernisierung ist deshalb mehr als Aufräumen im Code.

Woran erkennst du, dass deine Software modernisiert werden muss?

Das stärkste Argument gegen jede Modernisierung lautet: Das System läuft doch. Das stimmt fast immer und beantwortet die falsche Frage. Entscheidend ist, ob du es noch ändern kannst, wenn du musst, etwa für eine Sicherheitslücke, eine neue Kundenschnittstelle oder den Austausch von E-Rechnungen. Diese sieben Warnsignale zeigen, dass die Antwort Nein lautet oder bald lauten wird:

• Framework, Laufzeit oder Betriebssystem bekommen keine Sicherheitsupdates mehr.
• Nur eine Person kann das System sicher ändern, intern oder bei einem Dienstleister.
• Kleine Änderungen dauern Wochen, weil niemand abschätzen kann, was sie an anderer Stelle auslösen.
• Es gibt keinen reproduzierbaren Build. Der letzte lauffähige Stand existiert nur auf einem bestimmten Server oder Rechner.
• Bibliotheken lassen sich nicht aktualisieren, weil sie eine neuere Plattform voraussetzen.
• Neue Anforderungen wie eine Schnittstelle oder ein mobiler Zugang scheitern an der Architektur.
• Für die Technologie findest du kaum noch Fachleute, die sich einarbeiten wollen.

Die Fristen setzen dabei die Hersteller. Ein paar Beispiele, Stand Oktober 2026: Für AngularJS ist der Support seit Januar 2022 offiziell beendet. PHP 8.0 und 8.1 erhalten keine Sicherheitsupdates mehr, 8.2 bekommt sie laut php.net noch bis zum 31.12.2026, 8.3 bis zum 31.12.2027. Microsoft beendet den erweiterten Support für Windows Server 2016 im Januar 2027, im selben Monat läuft auch .NET Framework 4.6.2 aus.

Allgemein gilt: Nach einem Support-Ende läuft Software weiter, neu gefundene Lücken schließt aber niemand mehr.

Visual Basic 6 ist die Ausnahme, die zeigt, wie eng der verbleibende Support gefasst ist. Die Entwicklungsumgebung wird seit dem 08.04.2008 nicht mehr unterstützt, die Laufzeit läuft auf aktuellen Windows-Versionen weiter. Microsoft beschränkt den Support aber auf schwere Regressionen und kritische Sicherheitsprobleme und empfiehlt ausdrücklich, solche Anwendungen durch moderne Technik zu ersetzen.

Dazu kommt das Personalrisiko. Versteht nur eine einzige Person das System, ist ihr Urlaub ein Betriebsrisiko und ihre Kündigung ein Notfall.

Was du vor jeder Modernisierung absichern musst

Bevor du dich für einen Weg entscheidest, sorgst du dafür, dass das Altsystem die Modernisierung überlebt: Code in einem Repository, geprobte Backups, aktuelle Basis-Software, dokumentierte Zugänge und Tests, die das heutige Verhalten festhalten. Das klingt banal und wird trotzdem oft übersprungen, weil es keinen sichtbaren Fortschritt erzeugt.

Konkret bedeutet das:

• Der Quellcode liegt vollständig in einem Repository, und jemand außer dem bisherigen Entwickler kann daraus einen lauffähigen Stand bauen.
• Backups existieren, und eine Wiederherstellung wurde tatsächlich geprobt.
• Betriebssystem, Datenbank und Laufzeit sind so aktuell, wie es die Anwendung zulässt. Wo das nicht geht, ist das System so weit wie möglich von außen abgeschottet.
• Zugänge, Zertifikate und Lizenzen sind dokumentiert und hängen nicht an privaten Konten.
• Für die wichtigsten Abläufe gibt es Charakterisierungstests. Sie halten fest, was das System heute tut, auch dort, wo es fachlich falsch rechnet.

Der letzte Punkt trägt jeden der folgenden Wege. Charakterisierungstests zeigen beim Refactoring, dass sich nichts verändert hat, beim Strangler-Ansatz, dass der neue Baustein dasselbe liefert wie der alte, und beim Rebuild, welche Sonderfälle die neue Software abdecken muss. Kurz gesagt: Erst wenn du das heutige Verhalten messen kannst, kannst du es gefahrlos ändern.

So sieht ein Charakterisierungstest aus

Ein Charakterisierungstest hält fest, was das Altsystem tatsächlich tut, und prüft jede neue Umsetzung dagegen. Dafür zeichnest du für typische und auffällige Eingaben die echten Antworten des Altsystems auf, etwa aus Logs oder über die bestehende Schnittstelle. Im Beispiel liegen diese Paare aus Eingabe und Antwort in der Datei golden/fracht.json. Der Test prüft, ob die neue Frachtkostenberechnung für jede Eingabe exakt dasselbe liefert.

// Charakterisierungstest: hält fest, was das Altsystem heute liefert,
// und prüft, ob die neue Umsetzung für dieselben Eingaben dasselbe liefert.
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { readFileSync } from 'node:fs';
import { berechneFracht } from './fracht.ts';

// Vorher aus dem Altsystem aufgezeichnet: echte Eingaben, echte Antworten
const faelle = JSON.parse(
  readFileSync(new URL('./golden/fracht.json', import.meta.url), 'utf8'),
);

for (const fall of faelle) {
  const { plz, gewichtKg } = fall.eingabe;
  test(`Fracht für ${gewichtKg} kg nach PLZ ${plz}`, () => {
    assert.deepEqual(berechneFracht(fall.eingabe), fall.altsystem);
  });
}

Das Beispiel nutzt nur den Test-Runner, der in Node.js eingebaut ist. Aktuelle Node.js-Versionen führen TypeScript-Dateien wie diese ohne Build-Schritt aus. Entscheidend ist die Auswahl der Fälle: Grenzwerte, Sonderkunden und Werte mit Nachkommastellen. Rundet die neue Umsetzung anders als die alte, fällt das bei 12 Kilogramm womöglich gar nicht auf, bei 12,2 Kilogramm schon.

Schlägt ein Test fehl, klärst du mit dem Fachbereich, ob das alte Verhalten gewollt war. Erst danach änderst du die Referenz und hältst fest, wer die Abweichung freigegeben hat.

Refactor, Strangler oder Rebuild: Welcher Weg passt?

Drei Wege erneuern den Code selbst. Refactor passt, wenn die Technik aktuell oder höchstens leicht veraltet ist. Strangler passt, wenn Framework und Version deutlich veraltet sind, das System aber läuft. Rebuild passt, wenn das Framework abgekündigt ist und dazu Sicherheitsupdates für die Version, Wartung oder Dokumentation fehlen. Daneben stehen drei Optionen, die den Code kaum oder gar nicht anfassen: behalten, umziehen und durch Standardsoftware ersetzen.

Nach denselben Regeln schlägt der Legacy-Check seinen Pfad vor, allerdings für ein ganzes System. In der Praxis kombinierst du die Wege meist: Der stabile Kern wird refaktoriert, ein Modul mit dem Strangler-Ansatz abgelöst, ein drittes durch Standardsoftware ersetzt. Triff die Entscheidung deshalb Modul für Modul.

Refactor: modernisieren im Bestand

Refactoring heißt im engen Sinn, die innere Struktur von Code zu verbessern, ohne sein Verhalten zu ändern. Bei Legacy-Code gehört mehr dazu: Abhängigkeiten aktualisieren, die Plattform auf eine unterstützte Version heben, Tests und eine Build-Pipeline ergänzen und das Wissen aufschreiben, das bisher nur in Köpfen liegt.

Refactor ist der unterschätzteste der drei Wege. Ein System, das ein, zwei Major-Versionen hinter dem aktuellen Stand liegt, wirkt schnell wie ein Fall für den Neubau, auch wenn die Fachlogik noch trägt. Für PHP gibt es mit Rector ein Werkzeug, das Versions-Upgrades und Refactorings regelbasiert automatisiert. Aus einem gefürchteten Upgrade-Projekt wird so eine Folge überprüfbarer Änderungen.

Laut Hersteller deckt Rector sogar den Sprung von PHP 5.3 auf 8.5 ab. Ein System, das so weit zurückliegt, ist nach der Regel oben kein Refactor-Fall mehr. Lässt sich das Upgrade weitgehend automatisieren, kann ein Refactoring trotzdem der günstigere Weg sein. Ob das trägt, zeigt erst ein Blick in den Code.

Das Risiko liegt nach dem Projekt. Refactoring macht ein System wieder wartbar, solange jemand die Wartung auch übernimmt. Ohne festes Wartungsmodell mit regelmäßigen Updates stehst du in ein paar Jahren wieder an derselben Stelle.

Strangler: ablösen, während das System weiterläuft

Der Name geht auf Martin Fowler zurück. Er sah 2001 im Regenwald von Queensland Würgefeigen, die in einem Wirtsbaum keimen, ihn umwachsen und schließlich ersetzen, und übertrug das Bild auf die schrittweise Ablösung von Software. Das Vorgehen ist heute als Strangler-Fig-Pattern bekannt.

Technisch setzt du eine Fassade vor das Altsystem, etwa einen Reverse Proxy oder ein API-Gateway. Sie entscheidet pro Anfrage, wer antwortet: das Altsystem oder der neue Baustein. Mit jedem abgelösten Bereich sinkt der Anteil der Anfragen, die noch beim Altsystem landen. Kommt dort nichts mehr an, schaltest du es ab. Die Nutzer erleben dabei keinen Umstellungstag.

Fowler begründet den Weg mit einer Beobachtung, die jeder kennt, der schon einmal einen Neubau spezifiziert hat: Das bestehende Verhalten im Detail zu ermitteln ist schwer, und vieles davon braucht eigentlich niemand mehr. Der schrittweise Weg senkt das Risiko und bringt früher Nutzen. Bezahlt wird mit Übergangsarchitektur, also Code, der nach der Migration wieder verschwindet. Fowler hält diesen Preis für gerechtfertigt.

Wie wenig Technik der Einstieg braucht, zeigt eine Konfiguration für den Webserver nginx. Der Bereich Angebote ist bereits abgelöst. Die Frachtkosten laufen im Schattenbetrieb: Das Altsystem antwortet weiter, der neue Dienst bekommt eine Kopie jeder lesenden Anfrage.

# Fassade vor dem Altsystem: Abgelöste Bereiche gehen an den neuen
# Dienst, alles andere läuft unverändert ins Altsystem.
upstream altsystem    { server legacy-app:8080; }
upstream neuer_dienst { server neuer-dienst:3000; }

server {
  listen 80;

  # Bereich 1 ist abgelöst: Angebote kommen aus dem neuen Dienst
  location /api/angebote/ {
    proxy_pass http://neuer_dienst;
  }

  # Bereich 2 im Schattenbetrieb: Das Altsystem antwortet weiter,
  # der neue Dienst bekommt eine Kopie, seine Antwort wird verworfen
  location /api/frachtkosten/ {
    mirror /schatten;
    proxy_pass http://altsystem;
  }

  location = /schatten {
    internal;
    if ($request_method != GET) { return 204; }  # nur Lesezugriffe spiegeln
    # Kurze Timeouts: Ein hängender neuer Dienst darf das Altsystem nicht bremsen
    proxy_connect_timeout 1s;
    proxy_read_timeout    1s;
    proxy_pass http://neuer_dienst$request_uri;
  }

  # Alles, was noch nicht umgezogen ist
  location / {
    proxy_pass http://altsystem;
  }
}

Die Kopie erzeugt das mirror-Modul von nginx, das die Antworten auf gespiegelte Anfragen verwirft. Die Nutzer sehen also weiter nur das Altsystem. Den Abgleich baust du selbst, etwa indem der neue Dienst sein Ergebnis protokolliert und ein Job es mit den Antworten des Altsystems vergleicht.

Gespiegelt werden nur Lesezugriffe. Eine gespiegelte Schreibanfrage würde Daten ein zweites Mal anlegen, diesmal im neuen System. Ebenso wichtig sind die beiden Timeouts im Schatten-Block: nginx gibt die Verbindung für die nächste Anfrage erst frei, wenn auch die Kopie beantwortet ist. Ohne sie bremst ein hängender neuer Dienst die echten Nutzer aus, im Extremfall bis zum Standardwert von 60 Sekunden. Mit ihnen bleibt es bei rund einer Sekunde.

Für den ersten Bereich eignet sich, was klar abgrenzbar ist und sich häufig ändert, denn dort zahlt sich neue Technik am schnellsten aus. Wie oft sich ein Bereich ändert, verrät die Versionshistorie, wie stark er genutzt wird, das Access-Log der Fassade. Ein verbreitetes Missverständnis noch: Der Strangler-Ansatz verlangt keine Microservices. Ein modularer Monolith mit Modulen entlang fachlicher Grenzen ist oft das bessere Ziel. Wie du diese Grenzen findest, zeigt der Beitrag zu Domain-Driven Design.

Rebuild: neu bauen, wenn nichts mehr trägt

Ein Rebuild ist richtig, wenn das Framework abgekündigt ist und dazu Sicherheitsupdates für die Version, Wartung oder Dokumentation fehlen. Dann fehlt ein sicherer Weg, das System weiterzubetreiben, und auch der Legacy-Check schlägt den Neubau vor.

Auch ein Rebuild beginnt nicht auf dem weißen Blatt. Die Anforderungen stecken im laufenden System: in Masken, Reports, Datenbankfeldern und im Wissen der Menschen, die täglich damit arbeiten. Daraus entsteht ein Lastenheft, das beschreibt, was die neue Software leisten muss. Wie du es aufbaust, zeigt der Leitfaden zu Lastenheft und Pflichtenheft.

Für den Datenumzug gilt, was weiter unten im Abschnitt über Daten steht: früh proben, mit dem vollständigen Bestand. Bis zur Abschaltung laufen die aufgezeichneten Referenzfälle aus den Charakterisierungstests gegen den Neubau, und jede Abweichung klärt der Fachbereich. Nutze den Neubau außerdem, um Ballast abzuwerfen: Was laut Nutzungsdaten niemand mehr aufruft, wird nicht nachgebaut.

Bleibt es beim Neubau, entsteht Individualsoftware, die zu deinen heutigen Abläufen passt. Für eine erste Einordnung von Kosten und Dauer eines solchen Projekts gibt es den Projekt-Rechner.

Behalten, umziehen, ersetzen: die übrigen Optionen

Nicht jedes Altsystem braucht neuen Code. Ein stabiles, selten geändertes Programm mit klar begrenzter Aufgabe darf bleiben, wenn du es abschottest und die Entscheidung regelmäßig überprüfst. Ist vor allem Hardware oder Betriebssystem das Problem, verschafft ein Umzug auf neue Server oder in Container Zeit. Anthropic beschreibt diesen Weg als schnell, das Wartungsproblem bleibe aber bestehen.

Was beim Wechsel der Infrastruktur zu beachten ist, beschreibt der Entscheidungs-Guide zur Cloud-Migration. Bildet das Altsystem dagegen einen Standardprozess ab, ist eine Standardsoftware oft die günstigere Antwort. Wann sich Eigenentwicklung lohnt und wann nicht, wägt der Beitrag Build vs. Buy aus Engineering-Sicht ab.

Was ändern KI-Coding-Agenten an der Modernisierung?

KI-Coding-Agenten können die Analyse eines Altsystems deutlich günstiger machen: Abhängigkeiten kartieren, vergessene Abläufe dokumentieren, Risiken aufspüren, Tests entwerfen. Die Entscheidungen bleiben beim Team. Welche Geschäftsregel noch gilt, ob die Tests ausreichen und wann umgestellt wird, beantwortet kein Agent.

So beschreibt es auch Anthropic: Claude Code soll die Erkundungs- und Analysephasen übernehmen, die bei COBOL-Projekten den größten Teil des Aufwands ausmachen, und vorab Funktionstests entwerfen, die prüfen, ob der migrierte Code dieselben Ausgaben liefert wie das Original. Das ist das Prinzip des Charakterisierungstests von oben. Den größten Effekt sieht Anthropic trotzdem beim Neuschreiben in einer modernen Sprache.

Für Altsysteme im Mittelstand halte ich einen anderen Effekt für wichtiger. Refactor und Strangler leben davon, Bestehendes zu verstehen und in Tests festzuhalten, und genau diese Vorarbeit wird billiger. Ein Agent, der eine Abhängigkeitskarte erstellt und Referenzfälle für Charakterisierungstests vorschlägt, senkt die Einstiegshürde für den schrittweisen Weg stärker als die für den Neubau.

Was KI nicht ändert: Welche der gefundenen Regeln noch gilt, weiß nur der Fachbereich. Ein Agent, der Code ohne Tests in eine neue Sprache übersetzt, überträgt auch die Fehler, nur schneller. Und die Umstellung mit Schnittstellen, Datenumzug und Abschalttermin bleibt ein Organisationsprojekt. Das ist der Kern des Einwands von Rob Thomas.

Praktisch setzt du KI-Agenten für vier Aufgaben ein: die Bestandsaufnahme, Testentwürfe, mechanische Upgrades und eine erste Dokumentation, die Fachleute gegenlesen. Jede Änderung eines Agenten läuft durch Review und Tests wie die eines menschlichen Teammitglieds.

Warum Daten und Schnittstellen den Zeitplan bestimmen

Daten und Schnittstellen bestimmen den Zeitplan, weil sich ihre Probleme erst spät zeigen: Eine vergessene Verbindung fällt auf, wenn ein Partner keine Daten mehr bekommt, Altlasten im Bestand beim ersten vollständigen Umzug. Plane deshalb drei Dinge früh: eine Bestandsaufnahme aller Verbindungen, genau ein schreibendes System pro Tabelle und einen wiederholbaren Datenumzug.

An einem Altsystem hängen über die Jahre Shop, ERP, Buchhaltung, Auswertungen und Dateiexporte. Jede dieser Schnittstellen muss nach der Modernisierung weiter funktionieren oder bewusst abgelöst werden.

Einen Teil der Bestandsaufnahme liefert die Fassade gleich mit. Ihr Access-Log zeigt nach ein paar Wochen, welche Endpunkte tatsächlich aufgerufen werden, von welchen Systemen und wie oft. Was dort nie auftaucht, ist ein Kandidat zum Streichen. Verbindungen an der Fassade vorbei findest du so allerdings nicht, etwa direkte Datenbankzugriffe oder Dateiablagen. Die suchst du in den Benutzerkonten der Datenbank, in geplanten Jobs und in Netzwerkfreigaben.

Solange alt und neu parallel laufen, braucht jede Tabelle genau ein System, das schreibt. Das andere liest oder bekommt die Änderungen synchronisiert. Schreiben beide in dieselben Daten, überschreiben sie sich gegenseitig, und das fällt selten sofort auf. Mit jedem abgelösten Bereich wechselt die Schreibhoheit für dessen Daten genau einmal, geplant und mit Datum.

Den Datenumzug schreibst du als wiederholbares Skript und lässt ihn von Anfang an regelmäßig gegen eine Kopie des vollständigen, bei Bedarf pseudonymisierten Bestands laufen. Nach jedem Lauf vergleichst du Zeilenzahlen und Summen zwischen alt und neu, etwa offene Posten oder Lagerwerte. Jede Differenz wird ein Ticket, das vor dem echten Umzug geschlossen sein muss.

Achte beim Zielsystem darauf, nicht die nächste Abhängigkeit einzukaufen. Offene Datenformate, dokumentierte Schnittstellen und Code, dessen Rechte bei dir liegen, verhindern einen neuen Vendor Lock-in.

Was kostet es, Legacy-Software zu modernisieren?

Was es kostet, Legacy-Software zu modernisieren, hängt an sechs Treibern: Fachlogik, Schnittstellen, Datenqualität, Testabdeckung, Dokumentation und die geforderte Verfügbarkeit. Dazu kommt der gewählte Weg, denn ein Refactoring aus Updates und Tests ist ein anderes Projekt als ein Rebuild mit Datenumzug und Parallelbetrieb. Eine seriöse Zahl gibt es deshalb erst nach der Bestandsaufnahme, die Treiber kannst du vorher abschätzen.

Auf der anderen Seite der Rechnung stehen die Kosten des Nichtstuns: Wartung, die jedes Jahr mehr Zeit bindet, offene Sicherheitsrisiken und die Abhängigkeit von wenigen Personen. Sie tauchen in keinem Angebot auf. Erst ein Blick auf die Total Cost of Ownership über mehrere Jahre macht beide Seiten vergleichbar.

Fahrplan: In fünf Schritten zur Entscheidung

Der Weg vom Bauchgefühl zu einer belastbaren Entscheidung hat fünf Schritte. Die ersten beiden kosten wenig und senken das Risiko sofort, die übrigen bereiten die eigentliche Modernisierung vor.

1. Risiko einschätzen. Der Legacy-Check fragt in sechs Fragen Sprache und Framework, Version, letztes Update, Wartung, Hosting und Dokumentation ab. Er liefert in zwei Minuten einen Risiko-Score von 0 bis 100 und einen ersten Pfad, ohne Anmeldung.
2. Betrieb absichern: Repository, geprobte Backups, dokumentierte Zugänge und Charakterisierungstests für die kritischen Abläufe.
3. Bestand aufnehmen: Module, Schnittstellen, Datenflüsse und tatsächliche Nutzung. Hier helfen KI-Agenten am meisten.
4. Pfad pro Modul festlegen: behalten, refaktorieren, schrittweise ablösen, neu bauen oder ersetzen. Die Reihenfolge richtet sich danach, wo der erste Schritt am schnellsten sichtbaren Nutzen bringt.
5. Klein starten und Wartung vereinbaren. Der erste Baustein geht in Produktion, bevor der zweite geplant wird, und ein Wartungsmodell sorgt dafür, dass das neue System nicht wieder altert.

Wie wir diese Schritte gemeinsam mit dir gehen, beschreibt die Seite Altsystem ablösen.

Häufige Fragen zur Legacy-Modernisierung

Was ist der Unterschied zwischen Refactoring und Rebuild?

Beim Refactoring bleibt das System bestehen. Du verbesserst Code, Tests und Plattformversion, ohne das fachliche Verhalten zu ändern. Beim Rebuild ersetzt ein neu entwickeltes System das alte, meist mit Datenumzug und Parallelbetrieb. Refactoring passt, wenn die Technik aktuell oder höchstens leicht veraltet ist. Ein Rebuild wird nötig, wenn das Framework abgekündigt ist und dazu Sicherheitsupdates für die Version, Wartung oder Dokumentation fehlen.

Kann ich Legacy-Software modernisieren, ohne den Betrieb zu unterbrechen?

Ja, das ist das Ziel von Refactoring und Strangler-Ansatz. Beim Refactoring gehen Änderungen in kleinen Releases live. Beim Strangler-Ansatz bleibt das Altsystem in Betrieb, während eine Fassade einzelne Bereiche auf das neue System umleitet. Nur ein Rebuild hat einen Umstellungstermin, den du mit Parallelbetrieb und einem geprobten Datenumzug kurz hältst.

Kann KI Legacy-Code automatisch in eine moderne Sprache übersetzen?

Teilweise. KI-Coding-Agenten analysieren Abhängigkeiten, dokumentieren Abläufe, entwerfen Tests und übernehmen mechanische Upgrades. Ob eine gefundene Regel noch gilt und wann umgestellt wird, entscheiden Menschen. Eine Übersetzung ohne Tests überträgt auch die Fehler des Altsystems in die neue Technik.

Wie lange dauert eine Legacy-Modernisierung?

Das hängt vom Weg und vom Umfang ab, vor allem von der Zahl der Schnittstellen und der Datenqualität. Wichtiger als die Gesamtdauer ist, wann der erste Teil produktiv läuft. Refactoring und Strangler-Ansatz liefern Ergebnisse in Etappen, ein Rebuild erst zum Stichtag. Eine belastbare Schätzung entsteht nach der Bestandsaufnahme.

Was passiert, wenn Framework oder Version keine Updates mehr bekommen?

Die Software läuft weiter, aber neu entdeckte Sicherheitslücken schließt niemand mehr. Kurzfristig hilft Abschotten: Zugriff nur aus dem internen Netz oder über eine vorgeschaltete Fassade. Mittelfristig gilt die Regel von oben. Bekommt nur deine Version keine Updates mehr, das Framework aber schon, passt der Strangler-Ansatz, oder ein Refactoring, wenn sich das Upgrade weitgehend automatisieren lässt. Ist auch das Framework abgekündigt, ist es ein Fall für den Rebuild.

Fazit: Erst das Wissen sichern, dann den Weg wählen

Legacy-Software zu modernisieren kann 2026 günstiger werden, weil KI-Agenten die teure Analysephase verkürzen. An den Kriterien für die Entscheidung ändert das nichts. Sie hängt weiterhin daran, ob Framework und Version noch Updates bekommen, ob jemand das System wartet und versteht und wie viel Fachwissen ungeschrieben im Code steckt.

Meine Position: Ein Altsystem, das läuft, modernisierst du im Bestand oder löst es in Etappen ab, solange es die Regel zulässt. Erst sichern, dann den Bestand aufnehmen, pro Modul entscheiden und klein starten. Ein Rebuild bleibt die Ausnahme für abgekündigte Technik ohne sicheren Weg, sie weiterzubetreiben. Mein Rat für den Anfang: Schreib die ersten Charakterisierungstests, bevor jemand über Technik diskutiert. Du brauchst sie bei jedem der drei Wege.

Wie modern deine Software wirklich ist, zeigt der kostenlose Legacy-Check in zwei Minuten. Willst du das Ergebnis mit jemandem besprechen, der solche Ablösungen begleitet, findest du unser Vorgehen bei der Software-Modernisierung.