94 Prozent der Kompilierfehler in KI-generiertem Code sind Typfehler — das meldet GitHub Octoverse 2025. Wer KI-Assistenten auf eine untypisierte JavaScript-Codebasis loslässt, hat also genau die Prüfschicht abgeschaltet, die den häufigsten Fehlertyp maschinell erzeugten Codes vor dem Merge abfängt. Damit ist die TypeScript-Migration keine Stilfrage der Entwicklungsabteilung mehr, sondern Teil Ihrer KI-Governance: Das Typsystem prüft jeden KI-Vorschlag automatisch — ohne dass ein Mensch dafür Review-Zeit investiert.
Die Frage nach dem Ob hat der Markt beantwortet: Laut State of JS 2025 schreiben 40 Prozent der Befragten ausschließlich TypeScript, nur noch 6 Prozent reines JavaScript. Dieser Leitfaden behandelt deshalb das Wie — die Reihenfolge, die realen Aufwände, die Stellen, an denen Migrationen tatsächlich scheitern. Und, weil Ehrlichkeit hier billiger ist als später: die Fälle, in denen Sie besser gar nicht migrieren.
Warum jetzt: Untypisierter Bestand ist ein doppeltes Risiko
Das erste Risiko ist klassisch. In einer untypisierten Codebasis lebt das Wissen darüber, welche Funktion welche Datenform erwartet, in den Köpfen der Entwickler, die sie geschrieben haben. Jede Nachbesetzung, jedes Refactoring, jede Integration wird zur Archäologie. TypeScript verschiebt dieses Wissen aus Köpfen in den Compiler — das ist der eigentliche Wartbarkeitsgewinn, nicht die Autovervollständigung im Editor.
Das zweite Risiko ist neu. KI-Assistenten erhöhen das Änderungsvolumen in Ihrer Codebasis drastisch, während die menschliche Review-Kapazität konstant bleibt. Die einzige Kontrollschicht, die mit diesem Volumen skaliert, ist maschinell — und die 94-Prozent-Zahl aus GitHub Octoverse 2025 zeigt, dass sie beim dominanten Fehlertyp greift. Dass sich die Talent- und Kostenseite ohnehin Richtung TypeScript konsolidiert, haben wir im TCO-Vergleich TypeScript vs. Java durchgerechnet; für JavaScript-Bestände gilt die Logik erst recht, weil der Umstieg hier keine Sprache wechselt, sondern nur ein Typsystem ergänzt.
Big Bang oder inkrementell?
Der offizielle Migrationspfad ist inkrementell und im TypeScript-Handbook dokumentiert: allowJs in der Compiler-Konfiguration aktivieren, Dateien einzeln von .js zu .ts umbenennen, Strictness schrittweise erhöhen. JavaScript und TypeScript koexistieren dabei beliebig lange im selben Projekt — es gibt keinen Stichtag, an dem alles fertig sein muss. Big-Bang-Migrationen funktionieren nachweislich auch, aber nur unter Bedingungen, die im Mittelstand selten gegeben sind: Pinterest migrierte 2025 rund 3,7 Millionen Zeilen per Codemod in einem Zug — abgesichert durch Byte-für-Byte-Vergleich des transpilierten Outputs; Stripe brauchte 2022 für eine ähnliche Größenordnung monatelange Codemod-Vorbereitung, bevor der eine große Pull Request gemergt werden konnte. Wer kein dediziertes Migrationsteam mit dieser Tooling-Tiefe hat, fährt inkrementell. Das ist keine Verlegenheitslösung, sondern der vom Hersteller vorgesehene Weg.
Der Stufenplan: In sechs Stufen von allowJs zum CI-Gate
Die folgende Staffelung hat sich in unseren Projekten bewährt und deckt sich mit dem offiziellen Pfad. Entscheidend ist, dass jede Stufe einen messbaren Abschluss hat — sonst wird die Migration zum Dauerzustand, den niemand mehr steuert.
| Stufe | Maßnahme | Abgeschlossen, wenn |
|---|---|---|
| 1 — Koexistenz-Setup | TypeScript-Compiler in den Build integrieren, allowJs aktivieren; keine einzige Datei wird umbenannt | Der Build läuft unverändert grün, das Laufzeitverhalten ist identisch |
| 2 — Neue Dateien nur noch TypeScript | Team-Regel: Jede neue Datei entsteht als TypeScript-Datei; das Code-Review setzt sie durch | Im Repository entstehen keine neuen JavaScript-Dateien mehr |
| 3 — Bestand nach Berührungsprinzip | Wer eine Datei fachlich ändert, benennt sie im selben Zug um und typisiert sie | Die Migrationsquote steigt monatlich mit der normalen Feature-Arbeit — ohne dediziertes Budget |
| 4 — Typgrenzen zu Altmodulen | Deklarationsdateien für noch nicht migrierte Module und ungetypte Abhängigkeiten definieren | Migrierte Dateien importieren nichts mehr ungeprüft als any |
| 5 — strict gestaffelt scharf stellen | noImplicitAny zuerst, dann strictNullChecks, zuletzt das volle strict-Bündel | Alle Flags aktiv, die Fehlerliste ist leer, verbleibende Ausnahmen sind dokumentiert |
| 6 — CI-Gate | Typprüfung blockiert Merges; die Migrationsquote wird als Kennzahl berichtet | Rückschritte sind technisch unmöglich; der Fortschritt ist Teil des Management-Reportings |
Das Berührungsprinzip in Stufe 3 ist der wirtschaftliche Kern des Plans: Es koppelt die Migrationsarbeit an Code, der ohnehin angefasst wird — also an Stellen, wo das Team den Kontext gerade im Kopf hat und der Typisierungsaufwand am geringsten ist. Selten berührte, stabile Module bleiben bewusst zuletzt liegen. Das ist kein Schönheitsfehler, sondern Priorisierung: Typen bringen den größten Ertrag dort, wo sich Code ändert.
Stufe 4 ist die unscheinbarste und wird am häufigsten übersprungen — mit Folgen. Solange migrierte Dateien ihre Importe aus Altmodulen ungeprüft als any entgegennehmen, ist die Typsicherheit an genau diesen Grenzen ein Versprechen ohne Deckung: Der Compiler meldet grün, prüft dort aber nichts. Deklarationsdateien für die wichtigsten Altmodule und ungetypten Abhängigkeiten schließen diese Lücke, ohne dass der Bestand selbst angefasst werden muss — beschrieben werden nur die öffentlichen Schnittstellen, nicht die Implementierung. Als Faustregel priorisieren wir die Module, die von den meisten bereits migrierten Dateien importiert werden: Dort kauft jede Deklarationszeile die meiste Sicherheit.
Die strict-Flags in der richtigen Reihenfolge
Der häufigste Fehler in Stufe 5 ist, das volle strict-Bündel sofort zu aktivieren. Das erzeugt tausende Fehler auf einen Schlag, das Team gewöhnt sich an rote Builds, und die Migration verliert ihre Autorität. Die im Handbook empfohlene Reihenfolge beginnt mit noImplicitAny — dem Flag mit dem besten Verhältnis aus Aufwand und Sicherheitsgewinn, weil es stillschweigend untypisierte Stellen sichtbar macht. Danach folgt strictNullChecks, das erfahrungsgemäß die meisten echten Fehler findet, aber auch die meiste Arbeit macht. Erst am Ende kommt das komplette strict-Bündel — die Sammel-Option, die alle Strict-Checks auf einmal aktiviert. Wer parallel checkJs aktiviert, bekommt Typprüfung sogar in noch nicht umbenannten JavaScript-Dateien — nützlich als Frühwarnsystem, aber optional.
Mit Stufe 6 wird die Migration vollständig steuerbar: Die Typprüfung blockiert Merges, die Migrationsquote — der Anteil typisierter Dateien oder Zeilen — wandert als Kennzahl ins reguläre Reporting. Der Fortschritt hängt dann nicht mehr an Erinnerung und gutem Willen, sondern ist messbar wie jede andere technische Kennzahl. Für Sie als Entscheider ist das der Punkt, an dem aus einem Entwickler-Vorhaben ein Programm mit Kennzahl, Verantwortlichem und Zieltermin wird — auch wenn der Zieltermin bewusst weit hinten liegt.
Aufwand ehrlich: Kalenderzeit ist nicht Teamzeit
Die belastbarsten öffentlichen Zahlen kommen aus drei Engineering-Blogs. Airbnb baute 2020 das Codemod-Tool ts-migrate (heute Open Source) und konvertierte damit Projekte mit über 50.000 Zeilen und mehr als 1.000 Dateien an einem einzigen Tag — und war zum Zeitpunkt des Berichts trotzdem erst bei 86 Prozent seines 6-Millionen-Zeilen-Monorepos, weil die Migration nebenläufig lief. Stripe stellte 2022 sein größtes Frontend mit 3,7 Millionen Zeilen in einem einzigen Pull Request um — nach monatelanger Codemod-Vorbereitung. Pinterest schaffte 2025 dieselbe Größenordnung in acht Monaten, vorfallsfrei. Die ehrliche Spanne lautet also: Monate bei fokussiertem, toolgestütztem Vorgehen — Jahre, wenn die Migration nebenläufig zur Feature-Arbeit läuft.
Zwei Einordnungen gehören dazu. Erstens: Stripe und Pinterest migrierten von Flow, einem bereits typisierten System — der Startpunkt war günstiger als bei rohem JavaScript, wo Typen erst erarbeitet werden müssen. Zweitens: Ihre Codebasis hat vermutlich keine Millionen Zeilen. Für den Mittelstand ist die relevante Kennzahl deshalb nicht die Kalenderzeit, sondern die Teamzeit: Nach Berührungsprinzip bindet die Migration keinen dedizierten Entwickler, sondern verteilt sich als kleiner Aufschlag auf ohnehin anfallende Arbeit. Die Kalenderzeit wird dadurch länger — das ist der bewusst gewählte Preis. Was Sie dafür brauchen, ist Geduld im Reporting: Eine Quote, die von 20 auf 80 Prozent klettert, ist ein Erfolg, auch wenn sie dafür vier Quartale braucht.
Wann Sie NICHT migrieren sollten
Ein Leitfaden, der nur das Für kennt, ist Verkaufsprosa. Es gibt Konstellationen, in denen die Migration betriebswirtschaftlich nicht trägt — und ein sauberes Nein spart dort mehr Geld als ein halbherziges Ja. Die vier häufigsten:
Kleine, stabile Codebasis: Wenn eine Anwendung seit Jahren läuft, kaum noch Änderungen sieht und ihre Fehlerrate unauffällig ist, kauft Ihnen die Typisierung fast nichts. Typen zahlen sich bei Änderungen aus — wo nichts geändert wird, reicht Absichern durch Tests und Monitoring.
Kurze Restlaufzeit: Steht die Ablösung der Anwendung ohnehin auf der Roadmap, gehört jeder Euro in den Nachfolger, nicht in den Bestand. Eine Migration, deren Ergebnis abgeschaltet wird, bevor sie sich amortisiert, ist Beschäftigungstherapie.
Reines Konfigurations- und Glue-Scripting: Build-Skripte, Deployment-Automatisierung, kleine interne Werkzeuge — hier ist JavaScript in Ordnung. Der Governance-Fall aus der Einleitung betrifft Produktcode, den KI-Assistenten und wechselnde Teams über Jahre weiterentwickeln.
Wenn das eigentliche Risiko woanders liegt: Sitzt unter Ihrem JavaScript-Frontend ein PHP-Backend auf einer Version ohne Security-Patches, ist die Typisierung nicht Ihr dringendstes Problem. Für diesen Fall haben wir einen eigenen Leitfaden: PHP-Legacy auf den TypeScript-Stack migrieren.
Der nächste Schritt
Der Einstieg ist bewusst klein: Stufe 1 — Koexistenz-Setup mit allowJs — ist in wenigen Tagen erledigt und verändert nichts am Laufzeitverhalten. Danach entscheidet nicht Technik, sondern Disziplin: die Review-Regel für neue Dateien, das Berührungsprinzip, die gestaffelten strict-Flags, das CI-Gate. Als TypeScript-Agentur übernehmen wir genau diesen Part — vom Setup über die strict-Staffelung bis zur Team-Einführung, typischerweise im Retainer-Modell für 4.000–12.000 € pro Monat parallel zu Ihrer Feature-Arbeit.
Wenn Sie erst wissen wollen, wo Ihre Codebasis steht: Den Startpunkt bildet unser Modernisierungs-Assessment zum Festpreis nach Discovery — Inventur, Risikobild, Stufenplan mit Aufwandsschätzung. Details dazu auf unserer Seite zur Software-Modernisierung, oder Sie klären die Ausgangslage direkt in einem kostenlosen 30-Minuten-Gespräch.
Stand: Juli 2026. Alle Preise netto. Marktzahlen mit Quellenangabe im Text; Projektpreise sind publizierte happycoding-Anker aus realen Projekten.
