AngularJS zu Angular migrieren: ein Monat mit Claude Code

Sep 3, 2026 von Karin Huber

Der Web-Client von time cockpit ist zwölf Jahre alt. Seit 2018 liefen darin zwei Frameworks auf derselben Seite, AngularJS und Angular, verbunden über eine Brücke, die als Übergang gedacht war. Im August 2026 haben wir diese AngularJS-zu-Angular-Migration abgeschlossen, innerhalb eines Monats und mit Claude Code an fast jedem Commit. Dieser Artikel beschreibt, was dabei konkret passiert ist: welche fünf Schritte zusammengehörten, wie die Arbeit zwischen Menschen und zwei KI-Modellen aufgeteilt war, was sich an Build-Zeit, Bundle-Größe und Testabdeckung verändert hat, welche Features im selben Release ausgeliefert wurden und was der Einsatz von Claude Code zu API-Listenpreisen gekostet hätte. Alle Zahlen stammen aus dem Repository, den Build-Ausgaben und den Claude-Code-Transkripten. Wie sie ermittelt wurden, steht am Ende des Artikels.

Ausgangslage: ein AngularJS-Angular-Hybrid seit 2018

time cockpit ist eine Plattform für Zeiterfassung und Projektmanagement. Unternehmen erfassen damit Arbeitszeiten, planen Projekte und rechnen mit Kunden ab. ASP.NET-Backend, Angular-Web-Client, an jedem Arbeitstag im Browser geöffnet.

Genau das machte die Migration schwierig. Man kann nicht Bildschirm für Bildschirm neu schreiben und abhaken, weil die Bildschirme den Kunden gehören und wir die meisten davon nie gesehen haben. Jeder Zellentyp muss sich weiterhin exakt so verhalten wie zuvor, und zwar für Datenmodelle, die wir nicht aufzählen können.

Wie es zum Hybrid kam

Der Web-Client entstand im Juli 2014 in AngularJS. Im Januar 2018 stellten wir Angular 5 mit @angular/upgrade daneben, der offiziellen Brücke, mit der sich Angular- und AngularJS-Komponenten eine Seite teilen.

Die Brücke ist als Übergangslösung gedacht. Unsere hielt achteinhalb Jahre. Dazu kommt: Der Long-Term-Support für AngularJS endete am 31. Dezember 2021. Seither gibt es für die alte Hälfte keine Sicherheitsupdates mehr, jede Lücke wäre unsere Sache gewesen. Neue Arbeit floss in die Angular-Hälfte, die AngularJS-Hälfte wurde gewartet, aber nie fertig abgelöst, und die Kosten summierten sich leise:

• Die Build-Ausgabe von AngularJS war im Repository eingecheckt: 39,71 MB, darunter eine vendor.js mit 15,5 MB und 378.725 Zeilen sowie eine Source Map mit 18,3 MB. Jeder Clone lud sie mit.
• Zwei Build-Systeme. Zwei Test-Runner. Zwei Arten, eine Komponente zu schreiben.
• ESLint war so lange unbemerkt kaputt, dass sich ein beträchtlicher Rückstand an Verstößen angesammelt hatte.
• Jedes neue Feature begann mit der Frage: “In welche Hälfte der App gehört das?”

Im August 2026 haben wir den Hybrid aufgelöst. Ausgangspunkt war die am 3. August ausgelieferte Version. Der letzte AngularJS-Code verschwand am 13. August, das Release drumherum war am 3. September fertig.

Die AngularJS-zu-Angular-Migration in fünf Schritten

AngularJS zu entfernen erwies sich als der kleinste von fünf Schritten, die zusammen passieren mussten, weil jeder den nächsten blockierte: Ohne Angular-Upgrade lässt sich die Brücke nicht entfernen, ohne neuen Build kein Angular-Upgrade, ohne neuen Test-Runner kein neuer Build.

Mitgezogen wurden die Kendo-UI-Komponenten von v24 auf v25, Microsofts Authentifizierungsbibliothek MSAL von v5 auf v6 und Font Awesome 4 auf Font Awesome Pro 7. Storybook, @angular/flex-layout und zwei verwaiste Bibliotheken für Benachrichtigungen und Tastenkürzel flogen raus. Die Abhängigkeitsliste enthielt außerdem vier Pakete, die gar nichts taten: i, install, force und npm selbst, eingetragen als Laufzeitabhängigkeit.

Drei ganze Projekte verließen die Solution: die AngularJS-Host-Anwendung und ihre zwei Testprojekte. Ein viertes, die ASP.NET-Assembly, die früher das AngularJS-Frontend auslieferte, lebt als reiner Backend-Code weiter, geschrumpft von 165 auf 104 Dateien.

Und trotzdem gab es neue Features

Eine Framework-Migration ist intern leicht und gegenüber Kunden schwer zu rechtfertigen. Deshalb sollte das Release auch für Kunden sichtbare Neuerungen enthalten. 34 der 233 Commits des Release sind Feature-Arbeit, keine Migration, und gut ein Drittel des in diesem Monat geschriebenen Codes stammt aus ihnen.

Das größte Feature sind erweiterte Listenfilter: Zeilen aus Eigenschaft, Operator und Wert, aufgebaut auf der zugrunde liegenden Entität der Liste, über bis zu fünf Beziehungsebenen hinweg, pro Benutzer zusammen mit Spalten- und Sortiereinstellungen gespeichert. Damit zieht der Web-Client mit unserem Desktop-Client gleich, und er kam mit einem neu gestalteten Filterbereich, den Listen, Dashboards und der Urlaubskalender gemeinsam nutzen.

Das zweitgrößte, verteilt über 90 Dateien, ist die Validierung. Serverseitige Fehler erscheinen jetzt an der Formularzelle, die sie verursacht hat, und erst, wenn man das Feld berührt oder zu speichern versucht hat. Keine Formulare mehr, die rot werden, bevor man etwas eingetippt hat. Gebaut wurde das Test-first: zwei Commits mit absichtlich fehlschlagenden Tests vor jeder Implementierung.

Ebenfalls neu: Hyperlink-Spalten mit typisierten Filterparametern, mit denen eine Zeile in einer Liste eine andere Liste oder ein Dashboard öffnet, vorgefiltert mit den Werten dieser Zeile; ein clientseitiger Konfigurations-Cache mit Prefetching, sodass das erste geöffnete Formular keinen zusätzlichen Roundtrip braucht; Dateiaktionen, die herunterladen oder direkt anzeigen; und ein Bereich für zuletzt verwendete Einträge in Beziehungsauswahlen, der die letzten fünf Auswahlen pro Feld im Browser speichert.

Die Feature-Arbeit brachte ihre eigenen Tests mit: 62 % dessen, was diese 34 Commits geschrieben haben, ist Testcode.

Wie die Arbeit mit Claude Code aufgeteilt war

Fast jeder Commit im Release entstand mit Claude Code, aber nicht mit einem einzelnen Modell, das allein arbeitet.

Im Repository liegt eine AGENTS.md, Anweisungen für KI-Coding-Agenten, eingecheckt neben dem Code, die die Arbeitsteilung ausdrücklich festlegt: ein Modell für Erkundung, Architektur, Planung und Review; ein zweites, als Subagent losgeschickt, für die mechanische Umsetzung und das Ausführen der Tests.

Die Transkripte bestätigen diese Aufteilung. Claude Fable führte die Hauptsitzungen: 7.024 von 9.774 Anfragen in den Hauptsitzungen. Claude Opus 5 führte die Subagenten: 13.088 von 16.195. Planung und Review lagen bei einem Modell, die Ausführung ging an ein anderes, parallel und jedes Mal mit frischem Kontext. Das Token-Diagramm weiter unten schlüsselt beides nach Version auf (Fable 5 und 5.1, Opus 4.8 und 5).

Die Arbeit war in 95 benannte Arbeitsstränge gegliedert, jeder eine abgegrenzte und für sich prüfbare Einheit statt einer einzigen offenen Anweisung: Brücke abbauen, Nx entfernen, Komponenten-Inputs auf Signals migrieren, die End-to-End-Suite beschleunigen, und 91 weitere. Insgesamt: 80 Sitzungen, 564 getippte Prompts, 320 Subagenten-Aufrufe, 33.915 Tool-Aufrufe.

Der größte Teil dieses Gerüsts ist älter als das Release. Das Repository enthielt bereits schriftliche Anleitungen für wiederkehrende Aufgaben, etwa wie man eine Übersetzung hinzufügt oder einen neuen Zellentyp testet. Die mussten nie neu erklärt werden. Dass die Regeln für Agenten vorher schriftlich vorlagen, war die Voraussetzung für 233 Commits in einem Monat. Es ist derselbe Gedanke, den wir für Anpassungen in Anpassbare Standardsoftware trifft KI beschrieben haben: Ein KI-Agent arbeitet gut, wenn das System sich selbst beschreibt.

Die Zahlen: Commits, Codezeilen, Signals

233 Commits an 25 Tagen Arbeit, Wochenenden eingeschlossen, 218 davon gemeinsam mit Claude. Der Spitzenwert lag bei 28 an einem einzigen Tag, mit einer anhaltenden Phase von 17 bis 27 pro Tag bis Mitte August.

Der rohe Diff umfasst 1.897 Dateien, +1.284.122 / −1.836.172, aber das meiste davon ist maschinell erzeugt. Drei Blöcke dominieren: die 438.039 Zeilen eingecheckter AngularJS-Build-Ausgabe, 1,22 Millionen Zeilen Locale-Daten, die lediglich neu formatiert wurden, und Lockfiles der Abhängigkeiten.

Diffs taugen ohnehin schlecht, um ein Release zu bemessen: Wer eine Zeile ändert, bekommt von git eine Löschung plus eine Ergänzung, und eine stark überarbeitete Datei sieht aus wie neu geschrieben. Einfacher ist es, den Code zu zählen, der vorher und nachher existiert, ohne generierte Dateien:

Zwei Zeilen brauchen eine Erklärung. “Modellgetriebene Testskripte” sind Testdatenmodelle in derselben Skriptsprache, mit der Kunden ihre eigenen Entitäten und Formulare definieren. “Anpassungen und Tooling” umfasst kundenspezifische Erweiterungen und Build-Werkzeuge, die die Migration nicht berührt hat.

Zwei Zeilen gehen auf null, das war das Ziel der Migration. Der Rest zeigt die Form des Tauschs: Das Angular-Frontend übernahm die Arbeit beider Hälften und wuchs um 12.300 Zeilen, während 14.357 Zeilen AngularJS samt Testprojekten vollständig verschwanden.

Auffällig ist die Aufteilung zwischen beiden: Produktcode wuchs um 6.263 Zeilen, Testcode um 9.706. Mehr neuer Code floss ins Testen des Produkts als ins Produkt.

Die Nettoänderung verbirgt allerdings, wie viel tatsächlich geschrieben wurde. Wer den finalen Code Zeile für Zeile per Blame zuordnet, findet 48.794 der heute vorhandenen Zeilen, die in diesem Monat geschrieben wurden. Die Lücke zu den +15.969 netto ist alter Code, der verschwunden ist. Davon stammen 18.238, gut ein Drittel, aus den neuen Features, die übrigen 30.556 aus der Migration. Der Feature-Anteil stützt sich stark auf Tests: 11.373 seiner 18.238 Zeilen sind Testcode, gegenüber 6.865 Zeilen Produktcode.

Die Modernisierung zeigt sich am deutlichsten daran, wie Komponenten ihre Schnittstellen deklarieren. Angular bewegt sich seit einiger Zeit von Decorators zu Signals, einem reaktiven Grundbaustein, der den Datenfluss explizit macht und dem Framework erlaubt, Arbeit zu überspringen, von der es weiß, dass sich nichts geändert haben kann. Decorator-basierte Deklarationen gingen von 266 auf 7 zurück, Signal-basierte stiegen von 145 auf 485.

webpack zu esbuild: Build-Zeit und Bundle-Größe

Wir haben beide Versionen zur Kontrolle auf derselben Maschine gebaut und die Ausgabe vermessen:

Ein 8× schnellerer Build und 38 % weniger, was ein Browser laden muss, bevor die App startet.

Die Gesamtmenge an ausgeliefertem Code hat sich kaum bewegt (die Anwendung tut dasselbe), aber der neue Bundler teilt sie deutlich besser auf: 0,7 MB gzip wanderten vom kritischen Pfad in Chunks, die bei Bedarf nachgeladen werden. Wo der alte Build eine einzige JavaScript-Datei mit 7,49 MB auslieferte, verteilt der neue denselben Code auf 25 Dateien, von denen sechs zum Start nötig sind.

Die zusätzlichen 72 Sekunden in der ersten Spalte verdienen eine Anmerkung: Für das alte Release musste eine zweite, völlig eigenständige Toolchain laufen, um die AngularJS-Bundles zu erzeugen, die die Seite ebenfalls lud. Diesen Build gibt es nicht mehr.

Was die Migration sicher gemacht hat: Tests, Pinning, Lint-Budget

Drei Entscheidungen waren dafür ausschlaggebend.

Die Tests wuchsen schneller als der Code.

Die Zahl der Testfälle stieg von 542 auf 1.331: Unit-Tests von 123 auf 626, browsergestützte End-to-End-Tests von 419 auf 705. Weil das Produkt kundendefinierte Modelle darstellt, arbeiten viele dieser Tests so, dass sie ein kleines synthetisches Datenmodell definieren und prüfen, wie die Oberfläche es darstellt. Dieser Katalog wuchs von 28 auf 43 Modelle. Der Produktcode wuchs um 3,6 %, die Zahl der Testfälle um 146 %. Dieses Verhältnis war die Voraussetzung dafür, das Framework eines täglich genutzten Produkts auszutauschen.

Gefunden hat es auch etwas. Der Excel-Export in der Listenansicht war irgendwann früher in der Migration stillschweigend abgeklemmt worden, und niemand hatte es bemerkt. Ebenso die Startseite: Für Kunden, deren konfigurierte Startseite eine Liste, ein Formular oder eine Importseite ist, führte das Öffnen der App unter / nicht mehr dorthin. Der Abbau hatte die AngularJS-Weiterleitung entfernt, die das erledigte, und nur eine Positivliste mit drei Routen behalten, die diese Weiterleitung immer nur ergänzt hatte. Beides ist behoben, und keines von beiden wäre beim Lesen des Diffs aufgefallen.

Das Upgrade durfte das Verhalten nicht ändern. Angular 22 ändert die Standardstrategie der Change Detection, eine stille, weitreichende Verhaltensänderung in jeder Komponente, wenn man sie einfach übernimmt. Also tat der Versionssprung das nicht. Jede bestehende Komponente wurde ausdrücklich auf das alte Verhalten festgelegt, und das Upgrade ging als reiner Versionswechsel raus.

Erst danach wurde die Change Detection modernisiert, als eigene Arbeit, in Etappen: eine Familie von Komponenten unter der neuen Strategie sicher machen, dann umstellen. Komponenten, die noch nicht umgestellt werden konnten, behielten ihre Festlegung und einen Kommentar mit der Begründung: // stays Eager: template reads mutable ApplicationService fields. Am 14. August fielen die letzten 24 Festlegungen in einem Commit. Jede Komponente läuft jetzt mit der modernen Strategie, und sie ist in elf prüfbaren Schritten dort angekommen statt mit einem einzigen Schalter.

Der Lint-Rückstand wurde per Ratsche abgebaut, nicht in einem Rutsch. Statt eines riesigen, nicht prüfbaren Formatierungs-Commits wurden die bestehenden Verstöße als Warnungen mit einem Budget pro Projekt eingefroren: 781 für die Kernbibliothek, bis hinunter zu null für die Hauptanwendung. Fehler müssen bei null bleiben, und jede neue Warnung lässt den Build fehlschlagen. Datei anfassen, ihre Warnungen beheben, Budget senken.

Was die Migration mit Claude Code gekostet hat

Über das Release hinweg verarbeitete Claude Code rund 4,34 Milliarden Tokens. Der Großteil davon war allerdings kein neuer Text: 4,23 Milliarden davon, 97,4 %, waren Cache-Lesezugriffe, derselbe Projektkontext, Anfrage für Anfrage günstig erneut gelesen statt neu berechnet. Aussagekräftiger ist, was neu war: rund 110 Millionen Tokens, davon 10,31 Millionen Output, also der Code, die Tests und die Commit-Nachrichten, die tatsächlich geschrieben wurden.

Verteilt auf 25.969 Anfragen und 25 Tage Arbeit, Wochenenden eingeschlossen, sind das rund 412.000 Output-Tokens pro Tag. Was das Review überstanden hat und heute noch im Repository steht, ist viel kleiner: etwa 1.950 Zeilen pro Tag. Das meiste, was ein Modell produziert, ist Erkundung, Gerüst und verworfene Versuche. Die Lücke zwischen diesen beiden Zahlen zeigt, warum der menschliche Review-Schritt nicht optional ist.

Zu Anthropics öffentlichen API-Preisen entspricht dieser Verkehr rund 4.250 Euro (4.926 US-Dollar, umgerechnet zum EZB-Referenzkurs von 0,8637 am 2. September). Aufgeteilt nach Preiskomponenten:

Neun Zehntel der Rechnung sind Kontext, also das Lesen und Zwischenspeichern der Codebasis, nicht das Schreiben des Codes. Pro Einheit gelieferter Arbeit sind das rund 18 Euro pro Commit oder neun Cent pro Codezeile, die heute noch steht.

Was noch offen ist

Der Hybrid ist weg, aber die Modernisierung ist nicht abgeschlossen. Sechzehn alte NgModules umhüllen noch Komponenten, die Standalone sein könnten. Der Lint-Rückstand ist real und wird Datei für Datei abgetragen. Und die App läuft noch mit Angulars zonenbasierter Change Detection. Zoneless zu werden ist der nächste Schritt, lange an einer Grid-Komponente eines Drittanbieters geparkt und jetzt fällig für eine erneute Prüfung.

Ein Monat hat uns ein Framework statt zwei gebracht, ein Build-System, einen Test-Runner, einen Build, der in 45 Sekunden statt sechs Minuten fertig ist, ein um 39,71 MB leichteres Repository und ein Release mit für Kunden sichtbaren Neuerungen, weil die Filter und die Validierung gleich mitgekommen sind. Achteinhalb Jahre “die Migration machen wir später fertig”, dann eine AngularJS-zu-Angular-Migration in einem Monat. Was bleibt, ist gewöhnliche Wartungsarbeit.

Es ist auch der Teil, der leicht unterschätzt wird, wenn ein Unternehmen überlegt, seine Zeiterfassung selbst mit KI zu programmieren. Die erste Version ist der günstige Teil. Sie zwölf Jahre lang aktuell zu halten, durch Framework-Wechsel wie diesen hindurch, ist der Teil, in dem die echten Kosten stecken. Warum wir deshalb Anpassen statt Neuentwicklung empfehlen, steht auf unserer Seite Zeiterfassung programmieren oder anpassen.

Häufige Fragen zur AngularJS-Migration

Was ist der Unterschied zwischen AngularJS und Angular?

AngularJS ist die 2010 erschienene Version 1.x, ein JavaScript-Framework mit Scopes und Zwei-Wege-Datenbindung. Angular, ab Version 2 im Jahr 2016, ist eine Neuentwicklung in TypeScript mit Komponentenarchitektur, heute mit Signals und Standalone-Komponenten. Der Support für AngularJS endete am 31. Dezember 2021, Angular erscheint weiterhin halbjährlich in einer neuen Major-Version. Die Brücke @angular/upgrade erlaubt den Parallelbetrieb beider Frameworks in einer Seite, gedacht als Übergang, nicht als Dauerzustand.

Lohnt sich eine Migration von AngularJS zu Angular noch?

Ja, aus zwei Gründen. AngularJS erhält seit 2022 keine Sicherheitsupdates mehr. Und ein Hybrid kostet laufend, bei uns zwei Build-Systeme, zwei Test-Runner, 39,71 MB eingecheckte Build-Ausgabe und bei jedem Feature die Frage, in welche Hälfte es gehört. Nach der Migration baut die Anwendung 8× schneller, der Browser lädt 38 % weniger, und es gibt nur noch einen Bootstrap, ein Framework und einen Test-Runner.

Wie lange dauert eine AngularJS-zu-Angular-Migration mit KI-Unterstützung?

Bei uns 25 Arbeitstage inklusive Wochenenden für einen Hybrid aus rund 4.660 Zeilen AngularJS, zwei Testprojekten und einem Web-Client mit 57.000 Zeilen Angular-Code, samt Wechsel von webpack auf esbuild und von Karma und Jest auf Vitest. Die Dauer hängt weniger von der Menge AngularJS-Code ab als davon, wie gut das Verhalten der bestehenden Anwendung durch Tests abgesichert ist.

Was kostet eine AngularJS-Migration mit Claude Code?

Der API-Gegenwert der verarbeiteten Tokens lag bei rund 4.250 Euro für 233 Commits, also etwa 18 Euro pro Commit. Neun Zehntel davon entfallen auf das Lesen und Zwischenspeichern des Projektkontexts, nicht auf das Schreiben von Code. Dazu kommt die menschliche Arbeitszeit für Planung, Review und Tests, die den größeren Teil der tatsächlichen Kosten ausmacht.

Wie migriert man ohne Verhaltensänderungen für Nutzer?

Drei Regeln haben sich bewährt: Tests wachsen schneller als der Produktcode, bei uns von 542 auf 1.331 Testfälle. Framework-Upgrades ändern kein Verhalten, jede Komponente wird zunächst auf das alte Verhalten festgelegt und erst danach in kleinen, einzeln prüfbaren Schritten modernisiert. Und Altlasten wie Lint-Verstöße werden per Budget schrittweise abgebaut statt in einem großen, nicht prüfbaren Commit.

So wurden diese Zahlen ermittelt: Die Zeilenzahlen sind eine einfache Zählung der in jeder Version vorhandenen Dateien (kein Diff), ohne generierte, eingebettete Fremd- und Locale-Dateien. Die Aufteilung in Feature und Migration stammt aus git blame über den finalen Code, gezählt wurden nur Zeilen, die überlebt haben, jeweils dem Commit zugeordnet, der sie zuletzt geschrieben hat. Die 233 Commits wurden von Hand als Feature- oder Migrationsarbeit eingestuft, diese Hälfte ist also eine Einschätzung. Die Token-Zahlen sind aus den lokalen Claude-Code-Transkripten dieses Repositorys zusammengeführt (81 Hauptsitzungs- und 660 Subagenten-Dateien), nach Anfrage-ID dedupliziert, auf den 4. August bis 3. September beschränkt und ohne die Sitzungen, in denen dieser Artikel entstand. Die Build- und Bundle-Zahlen stammen aus dem Bau beider Versionen auf derselben Maschine und dem Vermessen der Ausgabe.