# Fallstudie: 52.000 Zeilen Legacy-Code mit Claude Code auf .NET 10 migriert – in einem halben Tag

Jeder .NET-Entwickler kennt sie: Die Legacy-Anwendung, die seit Jahren zuverlässig auf einem Windows Server läuft, deren Migration aber „irgendwann" auf der Roadmap steht – nur hat dieses „irgendwann" die unangenehme Eigenschaft, nie einzutreten. Bei TimeWizard war es nicht anders. Eine über zehn Jahre gewachsene Enterprise-Anwendung mit 52.000 Zeilen Code, 23 SignalR Hubs und 13 proprietären NuGet-Paketen. Der Migrationsbedarf war offensichtlich, der manuelle Aufwand ebenso abschreckend.

Der letztendliche Auslöser war dann doch kein strategisches Erwachen, sondern schlicht Microsofts Kalender: Windows Server 2016 näherte sich dem Ende der Sicherheitsupdates. Da unsere Hosting-Infrastruktur mittlerweile auf Rancher RKE2 Kubernetes läuft, wäre ein Upgrade auf eine neue Windows-Server-Version nicht nur kostenpflichtig gewesen, sondern hätte den parallelen Tech-Stack dauerhaft aufgebläht. Die Migration per Coding Agent war daher ein Test – nicht nur wegen der erzielbaren Zeitersparnis, sondern auch des Vorgehenskonzepts.

Dieser Artikel dokumentiert, wie wir die Migration mit Claude Code als Coding Agent in weniger als einem halben Manntag durchgeführt haben – und welche Patterns sich dabei als übertragbar erwiesen.

TimeWizard ist eine mandantenfähige Enterprise-Anwendung für Zeiterfassung und Aufgabenverwaltung (Ersterstellung 2015). Das System basierte auf .NET Framework 4.7 mit ASP.NET MVC 5 und Web API 2 im Backend, kombiniert mit einer AngularJS 1.4 Single-Page-Application im Frontend. Die Echtzeitkommunikation lief über SignalR 2.4, die Datenhaltung über Entity Framework 6.3 gegen MS-SQL Server.

Die Backend-Solution umfasste 10 C#-Projekte mit 151 Klassen und rund 20.300 Zeilen Code. Besonders charakteristisch: 23 SignalR Hubs – nahezu jede Entität hatte einen eigenen Hub mit standardisierten CRUD-Operationen über eine generische Basisklasse. Sämtliche Datenbankzugriffe liefen über eine einzige Repository-Klasse TWRepository mit 29 öffentlichen Methoden – ein klassisches God-Object-Antipattern.

Das Frontend war als AngularJS-SPA mit 49 Routen, 88 HTML-Templates und rund 16.200 Zeilen JavaScript umgesetzt. Ein separater Windows Service mit Quartz.NET erledigte zeitgesteuerte Aufgaben.

Wer das Repository öffnete, stolperte über eine beeindruckende Sammlung technischer Schulden – jede einzelne mit dem untrüglichen Geruch von „das war damals eine gute Idee":

Die Migration folgte einem bewusst sequenziellen Ablauf in elf Schritten. Das Grundprinzip: Zuerst das Backend vollständig migrieren, dann das Frontend nur soweit anpassen, dass es mit dem neuen Backend kommunizieren kann, und abschließend die JavaScript-Abhängigkeiten aktualisieren. Jeder Schritt wurde als eigenständiger Prompt an Claude Code formuliert – die wörtlichen Prompts sind im Folgenden als Blockquotes dokumentiert.

Bevor der Agent produktiv arbeiten kann, braucht er ein Verständnis der bestehenden Codebasis. Dafür setzten wir das Custom Command /create-rules ein – eine erweiterte Variante des eingebauten /init-Befehls. Das Command analysiert automatisch den Tech Stack, erkennt Projekttyp und Verzeichnisstruktur, extrahiert Namenskonventionen aus dem bestehenden Code und generiert daraus eine CLAUDE.md-Datei im Projektstamm.

Dieser Schritt steht bewusst am Anfang, weil die Qualität aller nachfolgenden Planungen und Implementierungen direkt vom Projektverständnis des Agenten abhängt.

Im zweiten Schritt beauftragten wir Claude Code im /plan Modus mit einem detaillierten Migrationsplan. Die zentrale strategische Entscheidung: Backend zuerst, den Windows Service zunächst ausklammern, das AngularJS-Frontend nur soweit anfassen, wie es für die SignalR-Anbindung nötig ist. Die proprietären Evanto.Common-Bibliotheken sollten weitestgehend eliminiert werden.

Warum dieser Prompt funktioniert: Er gibt klare Leitplanken (Backend zuerst, Scheduler ausklammern), benennt explizit das Ziel für die proprietären Bibliotheken, fordert Rückfragen bei Unklarheiten ein und erlaubt dem Agent, die Komplexität selbst einzuschätzen und bei Bedarf aufzuteilen. Claude Code erstellte daraufhin einen mehrstufigen Plan, identifizierte nicht migrierbare Abhängigkeiten mit Alternativvorschlägen und stellte Rückfragen zu Implementierungsoptionen.

Die Ausführung des Migrationsplans lief vollständig autonom ab – 75 Minuten ohne eine einzige Unterbrechung oder Rückfrage auf einem Mac M4 Pro. Claude Code migrierte in dieser Zeit die gesamte Backend-Codebasis von .NET Framework 4.7 auf .NET 10.0, portierte die SignalR-Hubs auf ASP.NET Core SignalR, ersetzte die Evanto.Common-Bibliotheken durch projektspezifische Implementierungen und passte die Frontend-seitige SignalR-Anbindung an.

Nach Abschluss forderten wir einen detaillierten Report über den aktuellen Status an. Dieser Schritt dient der Validierung: Welche Teile wurden erfolgreich migriert, welche offenen Punkte gibt es? Ein konkretes Beispiel: Das Quellprojekt verwendete zwei Connection Strings (Anwendungsdatenbank + Authentifizierung), das migrierte Projekt nur noch einen.

Mit dem funktionierenden Backend als Grundlage zogen wir in einer Serie von gezielten Prompts aktuelle .NET Best Practices nach. Jeder Prompt adressierte ein spezifisches Thema:

Central Package Management – Directory.Packages.props, Directory.Build.props und global.json für zentralisierte Versionsverwaltung:

Da das Projekt über keinerlei automatisierte Tests verfügte, validierten wir das migrierte Backend durch manuelles Testen. Das einzige unmittelbare Problem: Die PDF-Generierung. Die Originalanwendung verwendete Windows-Systemfonts, die unter macOS und in Linux-Containern schlicht nicht existieren. Ein typisches Migrationsproblem beim Wechsel zu Cross-Platform .NET. Die Lösung – ein eigener PdfSharp FontResolver, der Schriften aus eingebetteten Ressourcen auflöst – generierte Claude Code automatisch, nachdem wir die Fehlermeldung aus dem Anwendungslog als Prompt übergeben hatten.

Für die Frontend-Modernisierung wählten wir bewusst ein dreistufiges Vorgehen: Research → Plan → Execute. Im ersten Schritt sollte Claude Code ermitteln, auf welche AngularJS-Version ein gefahrloses Upgrade möglich ist:

Das Ergebnis: Version 1.8.3 ist die letzte tatsächlich verfügbare Release (1.8.4 existiert nicht als vollständiges Release). Claude Code erstellte daraufhin einen Upgrade-Plan und führte diesen nach Freigabe aus.

Nach dem gleichen Research → Plan → Execute-Muster aktualisierten wir die übrigen Frontend-Abhängigkeiten. Den größten Sprung machte jQuery von 2.1.4 auf 3.7.1. Das dreistufige Vorgehen hat sich als zuverlässiges Pattern für Upgrades über mehrere Major-Versionen hinweg bewährt, weil der Agent vor der Ausführung Breaking Changes identifiziert und im Plan berücksichtigt.

Nach Abschluss aller Migrationsschritte generierten wir die CLAUDE.md erneut mit /create-rules. Dieser Schritt ist notwendig, weil sich der Projektstand grundlegend verändert hat: neues Framework, neue Projektstruktur, andere Abhängigkeiten. Damit der Agent bei den folgenden Frontend-Fixes mit aktuellem Kontext arbeitet, muss die CLAUDE.md den migrierten Stand widerspiegeln.

Nach den JavaScript-Upgrades über mehrere Major-Versionen war mit Regressionen zu rechnen. Bei auftretenden Problemen standen zwei Wege zur Verfügung: Screenshots und Console Logs als Prompt übergeben – oder, deutlich effizienter, dem Agent die URL der laufenden Anwendung mitteilen und ihn den Fehler selbst untersuchen lassen. Für letzteres kamen zwei Browser-Automation-Tools zum Einsatz: das claude-in-chrome Plugin und Playwright MCP.

Insgesamt mussten rund 10 UI-Probleme behoben werden. Der Zeitbedarf lag bei 90 Minuten. Eine wichtige Erkenntnis: Das Auslesen der Browser-Konsole und die Behebung von JavaScript-Fehlern gelingt mit Playwright zuverlässiger und schneller als mit claude-in-chrome.

Als Abschluss generierte Claude Code eine entwicklerorientierte README.md, die als Einstiegspunkt für neue Entwickler Setup, Konfiguration und Architekturentscheidungen dokumentiert.

Die Codebasis schrumpfte um 31 % bei identischer Funktionalität – hauptsächlich durch die Eliminierung der proprietären Bibliotheken und die schlankeren Patterns von ASP.NET Core. Die Anwendung läuft nun plattformunabhängig in Linux-Containern auf unserem RKE2-Cluster. Autofac wurde durch den integrierten Microsoft-DI-Container ersetzt, der E-Mail-Versand auf Coravel Mailables migriert, und die Konfiguration nutzt .env-Dateien statt Web.config-Transformationen. Die Frontend-Sicherheitslücken (jQuery XSS, AngularJS Prototype Pollution) sind durch die Updates auf aktuelle Versionen geschlossen.

Nicht jede technische Schuld wurde adressiert – das war eine bewusste Scope-Entscheidung:

Die größte Herausforderung war die Ablösung der 13 internen Evanto.Common-NuGet-Pakete. Diese Bibliotheken waren als gemeinsame Basis für mehrere Anwendungen konzipiert und entsprechend eng verwoben – von der Repository-Basisklasse über Authentifizierung bis zur SignalR-Infrastruktur. Claude Code musste die relevanten Teile identifizieren, in projektspezifische Bibliotheken extrahieren und sämtliche Referenzen anpassen. Die Entscheidung, diese Abhängigkeiten komplett aufzulösen statt sie mitzumigrieren, erhöhte den initialen Aufwand, eliminiert aber langfristig eine wesentliche Wartungslast.

Lesson Learned: Proprietäre Bibliotheksabhängigkeiten sind für einen Coding Agent keine Blackbox – vorausgesetzt, der Quellcode liegt vor. Den Pfad zum Quellcode explizit im Prompt anzugeben war entscheidend.

Die Originalanwendung setzte für PDFsharp/MigraDoc auf Windows-Systemfonts, die unter macOS und in Linux-Containern nicht verfügbar sind. Dieses Problem wurde erst beim manuellen Test sichtbar. Der FontResolver war dann allerdings eine Sache von einem Prompt mit der Fehlermeldung.

Lesson Learned: Plattformspezifische Hürden beim Wechsel von Windows-.NET lassen sich vorab schwer antizipieren. Ein manueller Testlauf nach der Backend-Migration ist unerlässlich.

AngularJS 1.4 → 1.8.3 und jQuery 2.1 → 3.7.1 über mehrere Major-Versionen hinweg zogen rund 10 UI-Probleme nach sich. Die Identifikation und Behebung dieser Regressionen war der zeitaufwendigste manuelle Anteil der Migration (90 Minuten), wurde jedoch effektiv durch Playwright MCP unterstützt.

Lesson Learned: Das dreistufige Research → Plan → Execute-Muster ist bei Multi-Major-Upgrades Gold wert. Der Agent identifiziert Breaking Changes vor der Ausführung und plant entsprechend.

Keinerlei Tests im Originalprojekt bedeutete: Vollständig manuelle Validierung nach jedem Schritt. In einem Projekt mit bestehender Testabdeckung hätte der Agent die Tests nach jeder Änderung automatisch ausführen und Probleme früher erkennen können.

Lesson Learned: Tests sind nicht nur für Menschen – sie sind der effektivste Feedback-Loop für Coding Agents.

Die gesamte Migration wurde in weniger als einem halben Manntag abgeschlossen (siehe Timeline oben). Bei rein manueller Durchführung wären mindestens 2 bis 3 Manntage realistisch gewesen – konservativ geschätzt, da allein das Verstehen und Umschreiben der proprietären Bibliotheksabhängigkeiten erheblichen Analyseaufwand erfordert hätte.

Die API-Kosten für die Claude Code Nutzung lagen im Bereich von ca. 30–40 € für die gesamte Migration. Gemessen an der eingesparten Arbeitszeit – selbst bei konservativer Kalkulation – ein hervorragender ROI.

Drei Patterns haben sich als projektübergreifend anwendbar erwiesen:

Research → Plan → Execute. Besonders bei Upgrades über mehrere Major-Versionen. Der Agent recherchiert Breaking Changes, erstellt einen konkreten Plan und führt diesen erst nach Freigabe aus. Das reduziert das Risiko von Fehlentscheidungen deutlich gegenüber einem direkten „mach mal"-Prompt.

CLAUDE.md als Steuerungsinstrument. Einmal zu Beginn generiert, um dem Agenten den Ist-Zustand zu vermitteln, und ein zweites Mal nach Abschluss der Migration, um den neuen Projektstand für alle Folgearbeiten festzuhalten.

Gezielte Prompts statt Mega-Prompt. Die Modernisierung (Schritt 5) zeigt: Eine Serie fokussierter Prompts – jeder mit einem klar abgegrenzten Thema – liefert bessere Ergebnisse als ein einzelner Prompt, der alles auf einmal erledigen soll.

Die Migration zeigt auch, wo agentengestützte Modernisierung aktuell an ihre Grenzen stößt. Das AngularJS-Frontend wurde bewusst nicht auf ein modernes Framework migriert – die fehlende Komponentenarchitektur von AngularJS und die zahlreichen Zusatzkomponenten machen eine vollautomatische Migration unrealistisch. Ebenso wurden weder automatisierte Tests noch Datenbankmigrationen eingeführt; beides hätte den Scope deutlich erweitert und den Zeitvorteil relativiert.

Besonders für Projekte, bei denen der manuelle Migrationsaufwand bisher als zu hoch eingeschätzt wurde und die Migration deshalb immer wieder aufgeschoben wurde – genau wie es bei TimeWizard der Fall war. Die Kombination aus strukturierter Planung durch den Agenten und gezielter manueller Validierung ermöglicht es, auch umfangreiche Legacy-Migrationen mit vertretbarem Aufwand durchzuführen.

Die Voraussetzung: Der Entwickler muss das Zielsystem verstehen und die Ergebnisse des Agenten kritisch bewerten können. Der Coding Agent ersetzt nicht die fachliche Kompetenz – er beschleunigt die Umsetzung.