Wenn Ihr nächstes digitales Produkt erst live gehen kann, nachdem das Java-Kernsystem modernisiert ist, geht es nicht live. Das ist keine Polemik, sondern Arithmetik: Laut New Relic 2024 liefen knapp 30 Prozent aller Java-Produktionsanwendungen noch auf Java 8 — einer Sprachversion von 2014. Die Zahl stammt nicht aus einer Umfrage, sondern aus Telemetriedaten von 62 Millionen JVM-Instanzen. Ein Backlog dieser Größe wird nicht in einem Geschäftsjahr abgetragen, und Ihre Produkt-Roadmap kann nicht so lange warten.
Die üblichen zwei Antworten auf dieses Dilemma sind beide falsch. Antwort eins: der Big-Bang-Rewrite — das Kernsystem komplett neu bauen und hoffen, dass der Markt zwei Jahre stillhält. Antwort zwei: neue Funktionen weiter in das Altsystem hineinentwickeln, wo jedes Feature durch Release-Zyklen, Abhängigkeiten und Wissensmonopole gebremst wird. Es gibt einen dritten Weg, und er ist unsere Default-Empfehlung für neue digitale Produkte neben einem stabilen, aber unbeweglichen Java-Kern: Two-Speed IT — das Kernsystem läuft weiter, Neues entsteht daneben im TypeScript-Stack und wird per API angedockt.
Warum Ihre Roadmap am langsamsten System hängt
Am Geld liegt es nicht. Laut der Lünendonk-Studie 2025/26 planen 83 Prozent der DACH-Unternehmen für 2026 höhere Modernisierungsbudgets, und laut Gartner haben 72 Prozent der CIOs den Abbau technischer Schulden zur Priorität für 2026 erklärt — bei 60 bis 80 Prozent der IT-Budgets, die ohnehin schon in Betrieb und Wartung von Bestandssystemen fließen. Das Problem ist die Reihenfolge: Solange jede Produktidee hinter der Migration in der Warteschlange steht, konkurriert Innovation mit Instandhaltung um dasselbe Team, dasselbe Budget und dieselben Release-Fenster. Und verliert.
Dazu kommt der Takt des Java-Ökosystems selbst. Spring Boot kennt kein LTS-Modell: Jede Minor-Version erhält nur zwölf Monate Open-Source-Support, und Ende Juni 2026 — also in wenigen Tagen — läuft laut endoflife.date mit Spring Boot 3.5 die letzte 3.x-Linie aus dem OSS-Support. Wer im Bestand modernisiert, modernisiert also nicht einmal, sondern dauerhaft. Das ist kein Argument gegen Java. Es ist ein Argument dafür, neue Produkte nicht an diesen Takt zu koppeln.
Drei Wege aus dem Backlog — nüchtern verglichen
Aus Entscheider-Sicht gibt es drei Optionen, und jede hat einen legitimen Anwendungsfall. So bewerten wir sie in Architektur-Reviews:
| Weg | Zeit bis zum ersten neuen Produkt | Risiko | Kostenprofil | Wann sinnvoll |
|---|---|---|---|---|
| Modernisieren im Bestand (Java 17/21, Spring Boot 3/4) | Spät — Neues wartet auf die Migration | Mittel: Upgrade-Treadmill bleibt, jede Spring-Boot-Minor-Version hat nur 12 Monate OSS-Support | Laufender Migrationsaufwand, ggf. Extended Support | Das Kernsystem ist selbst das Produkt; Java-Team stark besetzt |
| Big-Bang-Rewrite | Sehr spät — Jahre ohne sichtbaren Geschäftsnutzen | Hoch: Feature-Freeze, Parallelbetrieb, Scope-Explosion | Hoch und schwer planbar | Praktisch nie als Erstoption |
| Two-Speed: TypeScript-Greenfield neben dem Kern | Früh — erstes Produkt in Monaten, nicht Jahren | Begrenzt: Kern bleibt unangetastet, Risiko im neuen Service isoliert | Planbares Neubau-Budget plus API-Schicht | Neue kundennahe Produkte; Kern stabil, aber unbeweglich |
Der Big-Bang-Rewrite scheidet in der Praxis fast immer aus: Er bindet jahrelang Kapazität, liefert lange keinen sichtbaren Nutzen und trägt das höchste Scheiternsrisiko. Die eigentliche Entscheidung fällt zwischen „im Bestand modernisieren" und Two-Speed — und sie hängt an einer einzigen Frage: Ist das Kernsystem selbst das Produkt, oder ist es die Plattform, auf der neue Produkte aufsetzen sollen? Im zweiten Fall gewinnt Two-Speed, weil es die einzige Option ist, bei der Produktentwicklung und Modernisierung nicht um dieselben Ressourcen konkurrieren.
Two-Speed konkret: Strangler-Pattern mit TypeScript-Geschwindigkeit
Das Muster dahinter ist als Strangler-Pattern etabliert: Neue Funktionalität entsteht als eigenständiger Service neben dem Altsystem und kommuniziert mit ihm über definierte Schnittstellen. Das Kernsystem bleibt unangetastet — kein Eingriff in gewachsenen Code, kein Feature-Freeze, kein Parallelbetrieb zweier Komplettsysteme. Über die Zeit können einzelne Fähigkeiten aus dem Kern in neue Services wandern, aber das ist Option, nicht Pflicht. Two-Speed ist zuerst eine Sequenzierungsstrategie: Es entkoppelt die Geschwindigkeit Ihrer Produktentwicklung von der Geschwindigkeit Ihrer Modernisierung.
Dass die schnelle Spur bei uns TypeScript heißt, ist keine Geschmacksfrage. Seit August 2025 ist TypeScript laut GitHub Octoverse 2025 die meistgenutzte Sprache auf GitHub, mit 66 Prozent mehr Contributors im Jahresvergleich — GitHub nennt das den größten Sprachwechsel seit über einem Jahrzehnt. Laut Stack Overflow Developer Survey 2025 nutzen 48,8 Prozent der professionellen Entwickler TypeScript, Java liegt bei 29,6 Prozent. Für die Greenfield-Spur bedeutet das: größerer Talentpool, ein Sprachstack vom Frontend bis zum Backend und keine Oracle-Lizenzdiskussion im neuen Produkt. Die vollständige Kostenrechnung inklusive der Fälle, in denen Java gewinnt, haben wir im TCO-Vergleich TypeScript vs. Java aufgemacht.
Auch der klassische Referenzfall argumentiert genau auf dieser Ebene: PayPal baute bereits 2013 seine erste Node-Anwendung parallel zur laufenden Java-Entwicklung — mit zwei statt fünf Entwicklern, 33 Prozent weniger Code und doppeltem Durchsatz. Der Fall ist alt, aber die Pointe bleibt aktuell: Der Gewinn lag nicht in der Rohleistung, sondern in kleineren Teams und kürzerer Time-to-Market. Das sind exakt die Kennzahlen, an denen neue digitale Produkte gemessen werden — nicht Requests pro Sekunde.
Die Zalando-Lektion: Koexistenz ja, Wildwuchs nein
Bevor der zweite Stack zur Strategie wird, gehört eine Warnung auf den Tisch. Zalando betreibt seit Jahren Microservices in Java, Scala und Node.js parallel — Koexistenz ist im Enterprise Normalität, nicht Ausnahme. Der Zalando-Engineering-Rückblick auf ein Jahrzehnt Technologiegeschichte dokumentiert aber auch die Kehrseite: Sechs Sprachen für ähnliche CRUD-Services verhinderten gute Plattform-Unterstützung und kosteten messbar Produktivität — am Ende stand Konsolidierung. Die Lektion für den Mittelstand: Two-Speed heißt genau zwei Stacks mit dokumentierter Zuständigkeit — Java für den Kern, TypeScript für neue Produkte. Nicht „jedes Team wählt sein Lieblingsframework". Eine bewusste Zwei-Stack-Strategie ist das Gegenteil von Polyglot-Wildwuchs, nicht sein Anfang.
Drei Leitplanken, die den zweiten Stack kontrollierbar machen
1. API-Verträge statt Datenbank-Durchgriff
Die neue Anwendung greift niemals direkt in die Datenbank des Kernsystems. Die Schnittstelle ist ein Vertrag: OpenAPI-Spezifikation zuerst, daraus generierte, typisierte Clients auf TypeScript-Seite. So wird jede Änderung am Kern als Vertragsänderung sichtbar — im Code-Review, nicht als nächtlicher Produktionsfehler. Wie eine solche Integrationsschicht vor einem Altsystem in der Praxis aussieht, haben wir im Guide Next.js als Integrationsschicht für Legacy-Systeme beschrieben.
2. Team-Schnitt entlang der Produkte, nicht der Schichten
Der häufigste Organisationsfehler: Das TypeScript-Team wird zum „Frontend-Lieferanten" des Java-Teams degradiert — dann braucht jede Funktion zwei Backlogs, zwei Priorisierungen und ein Eskalationsmeeting, und die zweite Geschwindigkeit ist nach einem Quartal wieder die erste. Tragfähig ist der umgekehrte Schnitt: Ein Produktteam verantwortet den neuen Service vollständig, vom Interface bis zur API-Anbindung. Das Kernsystem-Team stellt seine Schnittstellen als internes Produkt bereit — versioniert, dokumentiert, mit Ansprechpartner. Zwei Geschwindigkeiten brauchen zwei Verantwortlichkeiten, keine Abhängigkeitskette.
3. Datenhoheit klären, bevor die erste Zeile Code entsteht
Für jede Geschäftsentität muss vor Projektstart feststehen, welches System führt. Kundenstamm im Kern, Interaktions- und Produktdaten im neuen Service — das funktioniert, solange es dokumentiert ist und die Synchronisation in eine definierte Richtung fließt. Was Two-Speed zuverlässig zerstört, sind Schatten-Datenbestände: Kopien von Kerndaten, die im neuen Stack ein Eigenleben entwickeln und nach einem Jahr niemand mehr abgleichen kann. Datenhoheit ist eine Governance-Entscheidung, keine technische — sie gehört in den Projektauftrag, nicht ins Sprint-Backlog.
Wann Two-Speed die falsche Wahl ist
Ehrlichkeit gehört zur Beratung, also drei Gegenanzeigen. Erstens: Ist das neue Produkt CPU-intensiv — Pricing-Engines, Simulationen, massive Parallelverarbeitung —, spricht die Physik für die JVM: Unabhängige Benchmarks zeigen dort 30 bis 68 Prozent Vorsprung gegenüber Node.js, und Java 25 LTS hat mit ausgereiften Virtual Threads nachgelegt. Solche Services gehören auf die JVM, auch in einer Two-Speed-Landschaft. Node und TypeScript spielen ihre Stärken bei I/O-lastigen Web- und API-Services aus — dort, wo die meisten kundennahen digitalen Produkte tatsächlich leben.
Zweitens: Wer keine zwei Stacks betreiben kann, sollte es nicht heimlich versuchen. Ein kleines IT-Team ohne Erfahrung im Node-Ökosystem gewinnt mit einem zweiten Stack zunächst Komplexität, nicht Geschwindigkeit — dann ist ein externes Produktteam der realistischere Einstieg als der Aufbau eigener Parallelstrukturen. Drittens: Läuft Ihr Kern bereits auf Java 21, ist das Team eingespielt und liefert in kurzen Zyklen, gibt es schlicht kein Problem, das Two-Speed lösen müsste. Der Ansatz ist ein Werkzeug gegen Blockade, kein Selbstzweck.
Der nächste Schritt: ein Produkt, ein API-Vertrag, 90 Tage
Der Einstieg in Two-Speed ist kein Strategiepapier, sondern ein Pilotprojekt. Wählen Sie das eine digitale Produkt, das am längsten auf Ihrer Roadmap wartet und fachlich klar vom Kern abgrenzbar ist. Definieren Sie den API-Vertrag zum Kernsystem, setzen Sie ein Produktteam auf — und messen Sie nach 90 Tagen, was live ist. Wir bauen solche Greenfield-Produkte als TypeScript-Agentur mit Senior-Teams: typischerweise als MVP zwischen 8.000 und 20.000 Euro oder als vollwertige Webapp zwischen 20.000 und 60.000 Euro. Wenn Sie prüfen wollen, ob Ihr Kandidat trägt: In einem kostenlosen Erstgespräch gehen wir Schnittstellen, Datenhoheit und Team-Schnitt in 30 Minuten durch.
Stand: Juni 2026. Alle Studien- und Support-Daten wie im Text attribuiert; Preisspannen netto, abhängig von Scope und Integrationsgrad.
