Claude Code Legacy Code: Alten Code verstehen und modernisieren

Fast jedes Entwicklerteam trägt einen Rucksack: Code, der vor Jahren geschrieben wurde, kaum noch dokumentiert ist und trotzdem das Herzstück der Anwendung bildet. Claude Code Legacy Code ist kein Marketing-Begriff — es beschreibt eine konkrete Arbeitstechnik, mit der du alten, undokumentierten oder schwer lesbaren Code systematisch verstehst, bewertest und Schritt für Schritt modernisierst.

Dieser Artikel zeigt, wie Claude Code dabei hilft: vom ersten Lesedurchgang eines fremden Codebase über die Identifikation technischer Schulden bis hin zum konkreten Migrationsplan. Nicht theoretisch, sondern so, wie es im Produktiveinsatz tatsächlich funktioniert.

1. Undokumentierten Code verstehen und erklären lassen

Der erste Kontakt mit Legacy-Code ist oft ernüchternd: Funktionen ohne Kommentare, Variablennamen wie x2 oder tempData, Abhängigkeiten die nirgends erklärt sind. Der klassische Ansatz — stundenlang lesen, debuggen, raten — kostet immens viel Zeit.

Claude Code dreht diesen Prozess um. Statt selbst zu erraten, was ein Code-Block tut, übergibst du ihn direkt:

claude "Erkläre mir was diese Funktion macht, welche Eingaben sie erwartet
und welche Seiteneffekte sie hat:" < src/legacy/process_orders.php

Claude Code liest die Datei, verfolgt alle Aufrufe innerhalb des Projekts, liest die aufgerufenen Hilfsfunktionen und gibt dir eine vollständige Erklärung: was die Funktion berechnet, welche Datenstrukturen sie erwartet, wo sie schreiben kann und wo typische Fehlerquellen liegen. Was vorher zwei Stunden Lesen bedeutete, dauert jetzt fünf Minuten.

Besonders wertvoll: Du kannst gezielt nach dem "Warum" fragen, nicht nur dem "Was":

claude "Warum prüft diese Funktion den Status zweimal? Ist das ein Bug
oder hat das einen Grund?" < src/legacy/checkout.py

2. Technische Schulden identifizieren und priorisieren

Technische Schulden sind selten gleichmäßig verteilt. Es gibt Module, die seit Jahren niemand angefasst hat und trotzdem stabil laufen. Und es gibt Module, die bei jeder Änderung zwei neue Bugs produzieren. Den Unterschied zu kennen ist entscheidend — weil Zeit zum Aufräumen immer begrenzt ist.

Claude Code kann eine systematische Bestandsaufnahme machen:

claude "Analysiere das Verzeichnis src/legacy/ und erstelle eine Liste
der technischen Schulden, sortiert nach Risiko und Aufwand zur Behebung.
Markiere was dringend ist und was warten kann."

Das Ergebnis ist eine priorisierte Liste: Sicherheitslücken, die sofort behoben werden müssen. Fehlerquellen, die aktiv Bugs produzieren. Komplexitäts-Hotspots, die jede Änderung verlangsamen. Und technische Schulden, die zwar hässlich aber stabil sind — die man in Ruhe lassen kann.

Diese Unterscheidung ist der wichtigste erste Schritt jeder Modernisierung: nicht alles refactoren, sondern zuerst das, was tatsächlich schadet. Besuche auch unseren Artikel über Claude Code Refactoring für einen tieferen Blick auf den eigentlichen Umbau-Prozess.

Konkrete Metriken einbeziehen

Noch präziser wird die Analyse, wenn du Claude Code mit konkreten Daten versorgst: welche Dateien am häufigsten geändert werden, welche Module die meisten Bugs produzieren. Diese Kombination aus Code-Analyse und Verlaufsdaten macht die Priorisierung wesentlich zuverlässiger als reine Code-Inspektion.

git log --format="%n%H" --name-only --since="6 months ago" | sort | uniq -c | sort -rn | head -20 | claude "Welche dieser häufig geänderten Dateien haben die höchste technische Schulden-Dichte?"

3. Schrittweise Modernisierung: von jQuery zu React, von Python 2 zu 3

Die größte Versuchung bei Legacy-Code ist der "Big Bang Rewrite" — alles auf einmal neu schreiben. Das scheitert fast immer, weil die Komplexität unterschätzt wird und die neue Version nie das vollständige Verhalten der alten abdeckt. Die bessere Strategie: schrittweise Migration, Datei für Datei, Modul für Modul.

Claude Code macht genau das möglich. Für eine jQuery-zu-React-Migration zum Beispiel:

claude "Konvertiere diese jQuery-Komponente zu React. Behalte das exakte
Verhalten, erkläre was du geändert hast und warum, und zeige wo ich
noch manuell prüfen muss:" < src/legacy/datepicker.js

Claude Code schreibt nicht blind um — es erklärt jeden Unterschied. Wo jQuery direkte DOM-Manipulation verwendet hat, warum das in React anders funktioniert, welche Event-Handler anders verdrahtet werden müssen. Du bekommst nicht nur den neuen Code, sondern das Verständnis, das du brauchst um ihn zu testen und zu debuggen.

Für Python-2-zu-3-Migrationen ist der Workflow ähnlich:

claude "Analysiere alle Python-2-spezifischen Muster in diesem Modul
und erstelle einen Migrationsplan: was kann automatisch umgestellt werden,
was braucht manuelle Prüfung?" < src/legacy/data_processing.py

4. Tests für bestehenden Code nachträglich schreiben

Legacy-Code ohne Tests ist das häufigste Problem bei der Modernisierung: Du kannst nicht sicher sein, ob deine Änderung das Verhalten bricht, weil es keine Tests gibt, die das ursprüngliche Verhalten dokumentieren. Und Tests schreiben für Code den man nicht vollständig versteht ist mühsam.

Claude Code löst das auf zwei Ebenen. Erstens: Es versteht den bestehenden Code und kann daraus Tests ableiten, die das tatsächliche Verhalten dokumentieren:

claude "Schreib umfassende Tests für diese Funktion. Die Tests sollen das
aktuelle Verhalten dokumentieren, einschließlich Edge Cases und Fehlerfälle.
Keine Annahmen über 'korrektes' Verhalten — nur was der Code tatsächlich tut:" < src/legacy/pricing.py

Zweitens kann Claude Code diese "Charakterisierungstests" nutzen, um Refactoring sicher zu machen. Du schreibst erst Tests die das alte Verhalten festhalten, dann änderst du den Code, dann verifizierst du dass alle Tests noch grün sind. Das ist die einzige sichere Methode um Legacy-Code zu modernisieren.

Mehr zur Methodik des testgetriebenen Arbeitens mit Claude Code findest du in unserem Artikel zu Claude Code und TDD — die dort beschriebenen Techniken lassen sich direkt auf Legacy-Szenarien anwenden.

5. Migrationsplan erstellen für große Umbauarbeiten

Bei größeren Umbauten — ein komplettes Framework-Upgrade, eine Architekturumstellung, eine Datenbank-Migration — braucht man einen strukturierten Plan, bevor man anfängt. Nicht eine To-do-Liste, sondern einen Plan der Abhängigkeiten erkennt, Risiken benennt und die richtige Reihenfolge definiert.

claude "Erstelle einen vollständigen Migrationsplan für die Umstellung
unserer Monolith-Architektur auf modulare Services. Analysiere zunächst
die bestehenden Abhängigkeiten, dann schlage eine Reihenfolge vor die
das Risiko minimiert. Jeder Schritt soll einzeln deploybar sein."

Claude Code analysiert dabei die tatsächlichen Code-Abhängigkeiten, nicht theoretische Architektur-Vorstellungen. Es sieht, welche Module direkt voneinander abhängen, welche über gemeinsame Datenbankstrukturen verbunden sind, und wo zirkuläre Abhängigkeiten existieren die zuerst aufgelöst werden müssen.

Das Ergebnis ist ein Migrationsplan der realistisch ist — weil er auf dem tatsächlichen Zustand des Code basiert, nicht auf der Architektur, die man sich einmal vorgestellt hatte.

Rollback-Strategie einplanen

Ein guter Migrationsplan enthält immer auch den Rückweg. Claude Code kann explizit nach Rollback-Optionen gefragt werden:

claude "Für jeden Schritt des Migrationsplans: was ist die Rollback-Strategie
wenn dieser Schritt fehlschlägt? Welche Datenbankänderungen sind reversibel,
welche nicht?"

6. Claude Code Legacy Code in der Praxis: ein reales Beispiel

Ein konkretes Szenario aus dem Produktiveinsatz: Eine PHP-5-Anwendung, geschrieben zwischen 2012 und 2016, ca. 40.000 Zeilen Code, kaum Dokumentation, keine Tests. Die Aufgabe: auf PHP 8 migrieren ohne die laufende Produktion zu gefährden.

Der klassische Ansatz hätte bedeutet: Wochen mit manuellem Lesen und Verstehen, dann Monate schrittweiser Migration mit ständiger Angst vor dem nächsten unbekannten Seiteneffekt.

Mit Claude Code lief es so:

• Tag 1: Claude Code analysierte alle 40.000 Zeilen und erstellte eine vollständige Liste PHP-8-inkompatibler Muster — deprecated Functions, geänderte Fehlerbehandlung, neue Type-Coercion-Regeln. Mit Priorität und geschätztem Aufwand pro Punkt.
• Woche 1: Charakterisierungstests für die 15 kritischsten Module — automatisch generiert von Claude Code, manuell reviewt und ergänzt.
• Wochen 2-6: Schrittweise Migration Modul für Modul, immer mit Tests als Sicherheitsnetz. Claude Code erklärt jeden Unterschied, kein blindes Umschreiben.
• Ergebnis: Migration in 6 Wochen statt geschätzten 4 Monaten. Kein Production-Ausfall.

Der entscheidende Unterschied: nicht Geschwindigkeit durch Abkürzungen, sondern Geschwindigkeit durch vollständiges Verständnis. Claude Code hat nicht geraten — es hat den Code tatsächlich gelesen und verstanden.