Wer heute auf Spring Boot 4.0 aktualisiert, bekommt dafür noch gut fünf Monate Open-Source-Support: Am 31. Dezember 2026 endet das OSS-Fenster des erst im November 2025 erschienenen Release (endoflife.date, Stand Juli 2026). Die 3.5-Linie hat ihr Fenster am 30. Juni bereits geschlossen — kommerzieller Support ist bis 2032 verfügbar, aber gegen Gebühr. Rund 13 Monate Open-Source-Pflege pro Minor-Release: Das ist der Takt, den das Spring-Ökosystem seinen Nutzern inzwischen vorgibt, und der häufigste Anlass, aus dem IT-Entscheider mit uns über einen Ausstieg sprechen.
Ob NestJS gegenüber Spring Boot überhaupt die richtige Zielplattform ist, haben wir im Entscheider-Vergleich NestJS vs. Spring Boot auseinandergenommen. Dieser Leitfaden setzt einen Schritt später an: Die Entscheidung ist gefallen — jetzt geht es um Weg, Reihenfolge, Risiken und Aufwände. Kein Code-Tutorial, sondern das Vorgehen auf der Flughöhe, auf der Sie es verantworten müssen.
Warum die Migration architektonisch kein Kulturbruch ist
NestJS ist erkennbar von Spring geprägt. Der Kern des Frameworks ist ein IoC-Container: Klassen werden mit @Injectable() registriert, Abhängigkeiten per Constructor-Injection anhand des TypeScript-Typs aufgelöst — das direkte Gegenstück zu @Component und @Autowired (offizielle NestJS-Dokumentation, Stand 2026). Module kapseln Provider und machen nur explizit Exportiertes für andere Module sichtbar; das Root-Modul bildet den Application Graph — funktional das, was in Spring @Configuration und Component-Scan leisten, nur mit strikterer Kapselung. Und Guards übernehmen mit dem CanActivate-Interface die Rolle, die in Spring Security Filter und Interceptors spielen: Sie entscheiden anhand von Rollen, Berechtigungen oder ACLs über die Zulassung eines Requests — mit vollem Zugriff auf den Execution-Kontext (NestJS-Dokumentation zu Guards, Stand 2026).
Für die Migration heißt das: Ihre Architektur überlebt den Wechsel. Service-Schnitte, Schichtenmodell und Dependency-Graph lassen sich weitgehend eins zu eins übertragen. Was sich ändert, sind Sprache und Laufzeitumgebung — nicht das Denkmodell Ihres Teams. Das Muster-Mapping im Überblick:
| Spring-Boot-Konzept | NestJS-Äquivalent | Anmerkung |
|---|---|---|
| Annotations (@...) | Decorators (@...) | Gleiche deklarative Denkweise, gleiche Optik |
| @RestController / @RequestMapping | @Controller() mit Routen-Decorators | Controller-Schicht bleibt strukturell identisch |
| Beans, @Component / @Autowired | Provider, @Injectable() + Constructor-Injection | Auflösung über TypeScript-Typen im IoC-Container |
| @Configuration / Component-Scan | @Module() mit explizitem Import/Export | Strikter gekapselt: nur exportierte Provider sind sichtbar |
| application.yml / Profiles | ConfigModule mit Umgebungs-Validierung | Konfiguration pro Umgebung, typisiert statt konventionsbasiert |
| Spring Security (Filter, Interceptors) | Guards (CanActivate-Interface) | Autorisierung mit Zugriff auf den Execution-Kontext |
| JPA / Hibernate | Typisierte ORMs (Prisma, TypeORM, Drizzle) | Schema als Code, Typsicherheit bis in die Query |
| JUnit / Mockito | Jest + Testing-Module | DI-Container steht auch im Test zur Verfügung |
| Actuator | Health-Check-Endpoints (Terminus) | Liveness/Readiness für Kubernetes analog abbildbar |
Eine ehrliche Einordnung gehört an diese Stelle: Belastbare Fallstudien mit harten Zahlen zu Dauer und Kosten gibt es für den Pfad Spring Boot → NestJS bislang kaum. Ein aktueller Erfahrungsbericht eines Enterprise-SaaS-Teams (Medium, Mai 2026) nennt als Hauptgewinn End-to-End-Typsicherheit und geteilte TypeScript-DTOs zwischen Frontend und Backend — bleibt aber rein qualitativ. Wir behandeln ihn als Einzelstimme, nicht als Studie. Die tragfähige Begründung für Ihre Migration liefert kein fremder Case, sondern Ihre eigene Support-, Team- und TCO-Lage.
Die Migrations-Reihenfolge: fünf Schritte, keine Abkürzung
Der wichtigste Beschluss ist ein Verzicht: kein Big Bang. Strangler-Projekte — die schrittweise Ablösung hinter einer stabilen Fassade — scheitern rund 40 % seltener als Big-Bang-Rewrites (Security Boulevard, 2026). Alles Folgende ist die Übersetzung dieses Prinzips in eine konkrete Reihenfolge.
Schritt 1: Service-Inventur
Bevor irgendetwas migriert wird, entsteht eine Landkarte: Welche Services existieren, auf welcher Boot-Version laufen sie, wie hoch ist ihr Änderungsdruck, wie eng ihre Kopplung, ist ihr Lastprofil I/O- oder CPU-lastig? Aus diesen fünf Kriterien ergibt sich ein Ranking der Migrationskandidaten — und fast immer auch eine Liste von Services, die bleiben, wo sie sind. Für eine mittelständische Landschaft mit 10 bis 20 Services ist das in unseren Projekten eine Arbeit von ein bis zwei Wochen, kein Quartalsprojekt.
Schritt 2: Der erste Service — I/O-lastig und gut abgegrenzt
Der ideale Erstkandidat ist ein I/O-lastiger Service mit klarer fachlicher Grenze und möglichst eigenem Datenmodell — ein Notification-, Export- oder Reporting-Service ist ein typisches Beispiel. Nicht der kritischste (zu viel Risiko), nicht der trivialste (zu wenig Erkenntnis). Ziel des ersten Durchstichs ist nicht Tempo, sondern Beweisführung: Build-Pipeline, Deployment, Observability und Team-Workflow funktionieren im neuen Stack, bevor Sie skalieren.
Schritt 3: Fassade davor — Gateway einziehen
Bevor der zweite Service angefasst wird, kommt ein Gateway oder Reverse-Proxy vor die Landschaft. Es entkoppelt alle Konsumenten von der Frage, welcher Stack eine Route gerade bedient. API-Verträge werden ab diesem Punkt eingefroren und versioniert — das Gateway ist der Ort, an dem Alt und Neu über Monate koexistieren, ohne dass Clients davon etwas bemerken.
Schritt 4: Route für Route — das Strangler-Muster
Jetzt wandern Endpunkte einzeln oder in fachlichen Bündeln in den neuen Stack. Die alte Route bleibt aktiv, bis die neue nachweislich Parität liefert; erst dann schaltet das Gateway um. Kein Endpunkt wird abgebaut, bevor sein Nachfolger sich im Produktionsverkehr bewährt hat. Das klingt langsam, ist aber der Mechanismus, der das Projekt jederzeit anhaltbar macht — und damit budgetierbar: Jeder Zwischenstand ist ein lauffähiger Zustand, kein halb fertiger Umbau.
Schritt 5: Parallelbetrieb mit Vertrags-Tests
Die Absicherung des Parallelbetriebs sind Vertrags-Tests: Aus der API-Spezifikation der Alt-Services generierte Prüfungen laufen gegen beide Implementierungen; jede Abweichung stoppt die Pipeline, bevor sie einen Kunden erreicht. Wer zusätzliche Sicherheit will, ergänzt Shadow-Traffic — der neue Service erhält gespiegelte Produktionsanfragen, ohne zu antworten. Der Rückbau der Java-Seite folgt erst, wenn vorab definierte Kriterien erfüllt sind: Fehlerraten, Latenzen, ein voller Monatszyklus inklusive Lastspitzen.
Team-Realität: Ihre Java-Entwickler sind näher dran, als Sie denken
Die häufigste Sorge im Steering-Termin ist das Team — und sie ist kleiner als vermutet. Dependency Injection, Modul-Kapselung, Guards, testbare Container: Erfahrene Spring-Entwickler erkennen in NestJS ihre eigenen Muster wieder und finden sich in der Projektstruktur schnell zurecht. Was tatsächlich neu ist und Zeit kostet: das strukturelle Typsystem von TypeScript, asynchrone Programmierung auf einer Event-Loop statt vertrauter Thread-Pools und die Hygiene-Regeln des npm-Ökosystems mit seinen kurzen Release-Zyklen.
Diese Lernkurve sollten Sie ehrlich einplanen: mehrere Wochen bis zur vollen Produktivität, und der erste Durchstich gehört unter Anleitung von Entwicklern, die TypeScript im Produktionsmaßstab kennen — ob intern oder extern. Mittelfristig dreht sich das Personalargument zu Ihren Gunsten: Laut Stack Overflow Developer Survey 2025 arbeiten 48,8 % der Entwickler mit TypeScript, 29,6 % mit Java. Die Nachbesetzungsfrage stellt sich im Zielstack entspannter als im Quellstack.
Wann Sie NICHT migrieren sollten
CPU-intensive Workloads und Massiv-Parallelität. Batch-Verarbeitung, rechenintensive Pipelines, hochparallele Verarbeitung: Hier ist die JVM objektiv die stärkere Plattform. Solche Services gehören nicht auf die Migrationsliste — sie bleiben auf Java, und zwar dauerhaft, nicht als Übergangslösung.
Stabile Kern-Services ohne Änderungsdruck. Ein Service, der seit zwei Jahren unverändert läuft und keine fachliche Roadmap hat, rechtfertigt keinen Umbau. Kommerzieller Support für Boot 3.5 ist bis 2032 verfügbar (endoflife.date, Stand Juli 2026) — Zeit kaufen ist für solche Systeme eine legitime Strategie. Auch für Boot-2.7-Bestand, seit Mitte 2023 ohne OSS-Patches, existiert dieser Weg noch bis Mitte 2029; die Optionen dafür haben wir im Beitrag zum Support-Ende von Spring Boot 2.7 durchgerechnet.
Fehlende Team-Basis. Ohne einen einzigen TypeScript-erfahrenen Entwickler im Haus und ohne Einstellungs- oder Partnerplan wird schon der erste Service zäh. Dann zuerst die Personalfrage klären — oder den Durchstich bewusst extern begleiten lassen und den Wissenstransfer vertraglich festschreiben.
Kurze Restlebensdauer. Steht die Anwendung in zwei bis drei Jahren ohnehin zur Ablösung durch Standardsoftware an, ist jeder Migrationseuro verloren. Absichern, einfrieren, geordnet auslaufen lassen — das ist in diesem Fall die wirtschaftlich richtige Antwort, auch wenn sie unspektakulär klingt.
Was der Einstieg kostet
Zur Einordnung unsere publizierten Preisanker: Das erste ablösbare Modul in MVP-Größe liegt bei 8.000–20.000 €, vollständige Module mit Auth und Rollenmodell bei 20.000–60.000 €. Eine vorgeschaltete Integrationsschicht samt Identity-Setup rechnet sich mit 5.000–20.000 €, laufende Begleitung im Parallelbetrieb als Retainer mit 4.000–12.000 €/Monat. Das Modernisierungs-Assessment am Anfang — Service-Inventur, Kandidaten-Ranking, Zielbild — bepreisen wir als Festpreis nach einer kurzen Discovery. Wichtiger als jede Zahl: Der Strangler-Ansatz macht die Kosten tranchierbar. Sie beauftragen einen Schritt, sehen das Ergebnis im Betrieb und entscheiden dann über den nächsten.
Der nächste Schritt
Der konkrete Anfang ist keine Technologie-Entscheidung, sondern eine Inventur: die Liste Ihrer Services mit Boot-Version, Support-Status, Änderungsdruck und Lastprofil. Diese Liste können Sie noch diese Woche intern starten — oder als Modernisierungs-Assessment mit uns aufsetzen. Wenn Sie vorab klären wollen, ob Ihr Fall überhaupt für den Strangler-Pfad taugt: 30-minütiges Erstgespräch, unverbindlich und ohne Folien.
Stand: 22. Juli 2026. Alle Preise netto; Spannen aus realen Projekten der Radscheit GmbH. Support-Daten nach endoflife.date, Juli 2026.
