Next.js als Integrationsschicht für Legacy-Systeme: Modernisieren ohne Big Bang

SAP geht nicht weg. TYPO3 geht nicht weg. Das ERP, das seit 2009 die Auftragslogik trägt, geht auch nicht weg. Diese Systeme sind nicht das Problem, das man löst — sie sind die Realität, in der man arbeitet. Die Frage ist nicht, wie man sie ablöst, sondern wie man ein modernes Frontend davorsetzt, ohne sich in einer dreijährigen Migration zu verlieren.

Genau hier wird Next.js interessant, und zwar nicht in der Rolle, in der es üblicherweise verkauft wird. Nicht als Renderer für die schnelle Marketing-Site, sondern als Schicht zwischen Browser und Backend-Zoo. Über Route Handlers aggregiert Next.js mehrere Datenquellen, normalisiert sie und liefert dem Frontend genau das, was es braucht. Es wird zur Integrationsschicht vor dem Backend, nicht zu seinem Ersatz. Das klingt unspektakulär. Es ist der Grund, warum Modernisierung in vielen Organisationen überhaupt erst realistisch wird.

Die teuerste Entscheidung in der Legacy-Modernisierung ist die, das Altsystem in einem Rutsch zu ersetzen. Sie klingt sauber: ein neues System, eine Migration, ein Stichtag, danach ist alles besser. In der Praxis ist es eine Wette mit hohem Einsatz und schlechter Quote. Während der gesamten Bauzeit liefert das Projekt keinen Wert, das Altsystem läuft parallel weiter, und am Go-Live-Tag entscheidet sich, ob zwei Jahre Arbeit funktionieren oder nicht. Bei einem SAP-Commerce-Stack, dessen Implementierung sich nach Partnerschätzungen schnell im sechsstelligen bis siebenstelligen Bereich bewegt (das sind Schätzungen eines Migrations-Dienstleisters, keine offizielle Preisliste — entsprechend vorsichtig zu lesen), ist diese Wette schlicht nicht verantwortbar.

Die Alternative ist eine Next.js Integrationsschicht vor dem Legacy-Bestand, die das Risiko zerlegt. Martin Fowler hat dafür das Bild der Strangler Fig geprägt: die Würgefeige, die einen Baum umwächst und Stück für Stück ersetzt, bis sie selbst trägt. Übersetzt heißt das: kleine Ergänzungen neben dem Altsystem, Verhalten Funktion für Funktion übernehmen, das Legacy schrumpft, während das Neue wächst. Fowler ist dabei ehrlich — das Muster macht die Übung nicht *einfach*, und es verlangt die Akzeptanz einer Übergangsarchitektur, die für eine Weile hässlich aussieht. Aber es liefert ab Woche eins Wert, und kein einzelner Tag entscheidet über Erfolg oder Misserfolg. Microsoft beschreibt denselben Strangler-Fig-Mechanismus als Facade, die Requests abfängt und je nach Stand zum Legacy oder zum neuen Service routet.

Die Würgefeige braucht eine Schicht, die dieses Routing übernimmt. Eine Stelle, an der entschieden wird: Diese Daten kommen noch aus SAP, jene schon aus dem neuen Service, und das Frontend merkt nichts davon. Diese Stelle kann Next.js sein.

Technisch ist das Muster unspektakulär, und das ist gut so. Next.js dokumentiert das Backend for Frontend offiziell über Route Handlers, die proxy-Konvention und — im Pages Router — API Routes. Ein Route Handler nimmt einen Request des eigenen Frontends entgegen, ruft im Hintergrund das ERP, das CMS und vielleicht noch einen Pricing-Service auf, fügt die Antworten zusammen, filtert das Überflüssige heraus und liefert eine saubere, auf die UI zugeschnittene Antwort zurück. Die internen Systeme bleiben unsichtbar. Das Frontend spricht nie direkt mit SAP, es spricht mit Ihrer Schicht.

Sam Newman, der den BFF-Begriff geprägt hat, formuliert das Prinzip als "one experience, one BFF": Die Schicht gehört dem Frontend-Team und ist auf genau ein Erlebnis zugeschnitten. Sie ist kein universelles Gateway, sondern der maßgeschneiderte Adapter zwischen einer konkreten Oberfläche und der unordentlichen Backend-Welt dahinter. Das ist die Stärke — und gleichzeitig die Grenze, auf die ich später zurückkomme.

Die offizielle Dokumentation ist an einer Stelle bemerkenswert ehrlich, und diesen Satz sollten Entscheider sich merken: Die Backend-Fähigkeiten von Next.js sind kein vollwertiger Backend-Ersatz, sie sind eine API-Schicht. Das ist keine Schwäche, das ist die korrekte Selbstverortung. Wer Next.js als BFF einsetzt, ersetzt damit nicht das System of Record. Er entkoppelt das Frontend von dessen Eigenheiten. Die Auftragslogik bleibt im ERP, wo sie hingehört. Die Schicht macht sie nur konsumierbar.

In Kombination mit der Rendering-Mechanik von Next.js entsteht daraus mehr als ein Proxy. Server Components reduzieren das an den Browser gesendete JavaScript, und Incremental Static Regeneration liefert für die meisten Requests vorgerenderte Seiten aus dem Cache — was die Last auf den dahinterliegenden Legacy-Systemen real senkt. Ein altes ERP, das jede Produktseite live beantworten müsste, geht bei Traffic in die Knie. Hinter einer ISR-Schicht beantwortet es nur noch die Cache-Revalidierungen. Wie sehr Antwortzeiten am Ende auf Conversion durchschlagen, habe ich an anderer Stelle ausführlicher behandelt — die Verbindung von Performance und Umsatz ist kein Nebenschauplatz, sondern oft das eigentliche Geschäftsargument für die ganze Übung.

Das Muster ist nicht auf E-Commerce beschränkt, auch wenn SAP Commerce das Lehrbuchbeispiel liefert. Dessen Composable Storefront ist ein Angular-Frontend, das ausschließlich über die OCC-REST-API spricht. Wer dieses Frontend nicht mag — und viele Teams mögen es nicht, weil es Java/Spring- *und* Angular-Kompetenz im Haus verlangt — kann dieselbe REST-API von einem Next.js-Frontend aus konsumieren. Die Commerce-Engine bleibt SAP, das Erlebnis wird ein anderes.

Beim Content gilt dasselbe. Ein altes TYPO3 oder ein in die Jahre gekommenes CMS liefert Inhalte über eine API, und Next.js rendert sie modern. Das ist im Kern der Headless-Ansatz mit WordPress und Next.js, nur dass das "Headless" hier nachträglich vorgesetzt wird, statt von Anfang an geplant zu sein. Wer ohnehin grundsätzlich über die CMS-Strategie nachdenkt, sollte den Unterschied zwischen CMS und DXP kennen, bevor er die Schicht baut — die Architektur der Integrationsschicht sieht je nach Antwort anders aus. Und wer noch grundsätzlich entscheidet, ob TYPO3 überhaupt die Basis bleibt, findet meine Argumente gegen TYPO3 im Jahr 2026 an anderer Stelle.

Salesforce, Microsoft-Dynamics-ERP, hauseigene Systeme aus den Nullerjahren — alle haben heute eine API oder lassen sich mit überschaubarem Aufwand eine vorsetzen. Die Integrationsschicht aggregiert sie. Der Kunde sieht eine Oberfläche, die Daten aus drei Systemen zieht, und merkt nichts von der Fragmentierung dahinter. Das ist der eigentliche Wert: Die organisatorische und technische Zersplitterung im Backend wird vor dem Nutzer verborgen, ohne dass man sie vorher auflösen muss. Das Auflösen kann danach kommen, Funktion für Funktion, im Strangler-Fig-Takt.

Hier muss ich gegen die eigene These argumentieren, sonst wäre der Artikel unehrlich. Ein Next.js-BFF ist eine Integrationsschicht *für ein Frontend*. Sobald die Aufgabe primär Integration ohne Frontend-Bezug ist — Backend spricht mit Backend, System synchronisiert mit System, Daten fließen zwischen ERP, CRM und Data Warehouse — ist ein Frontend-Framework das falsche Werkzeug.

Für diese Fälle existieren dedizierte Integrationsplattformen: ein API-Gateway wie Kong, eine Integrations-Middleware wie MuleSoft, oder ein eigenes Backend in der Sprache Ihrer Wahl. Diese lösen Aggregation sprachunabhängig, zentral und für beliebig viele Konsumenten. Sie bringen Rate Limiting, Protokoll-Transformation, Observability und Authentifizierung als Plattformfunktion mit, nicht als selbstgebauten Route-Handler-Code. Wenn fünf verschiedene Konsumenten dieselben aggregierten Daten brauchen, ist ein zentrales Gateway robuster als fünf BFFs, die dieselbe Logik duplizieren — und Newman benennt Code-Duplikation zwischen BFFs ausdrücklich als eines der zwei Hauptrisiken des Musters.

Die ehrliche Faustregel: Hat die Aggregation einen direkten, spezifischen Frontend-Bezug, ist das Next.js-BFF näher am Problem und schneller gebaut, weil es genau die Daten in genau der Form liefert, die diese eine Oberfläche braucht. Ist die Aggregation eine generische Backend-Aufgabe, gehört sie auf eine Integrationsplattform. Wer ein Frontend-Framework zum Enterprise-Integrationsbus umfunktioniert, baut sich ein Problem, das er später teuer wieder auseinandernimmt.

Jede Integrationsschicht hat einen Preis, und der wird im Pitch gern unterschlagen. Sie ist ein zusätzlicher Netzwerk-Hop. Mehr Latenz, ein weiterer Deploy, ein weiterer Ausfallpunkt. Die Next.js-Dokumentation sagt das selbst mit ungewöhnlicher Klarheit: Für on-demand Server Components ist das Fetchen über eigene Route Handlers langsamer, weil ein zusätzlicher HTTP-Round-Trip dazwischenliegt. Server Components sollten direkt aus der Quelle fetchen, nicht den Umweg über die eigene API-Schicht nehmen. Wer das ignoriert, baut sich Latenz ein, die niemand braucht.

Es kommt schlimmer, wenn die Schicht anfängt, Geschäftslogik anzusammeln. Ein BFF, das synchron in SAP, dann in Salesforce, dann ins ERP kettet und auf jede Antwort wartet, bevor es die nächste Anfrage stellt, degeneriert zum verteilten Monolithen: separat deployte, aber eng gekoppelte Services mit synchronen Chatty-Calls, Latenzketten und kaskadierenden Ausfällen. Fällt das ERP aus, fällt die ganze Seite. Das ist schwerer zu betreiben als der Monolith, den die Schicht ablösen sollte — man hat sich die Nachteile der Verteilung eingekauft, ohne ihre Vorteile zu bekommen.

Und selbst wenn alles sauber bleibt: Die Grenzen der Legacy-Systeme verschwinden nicht, sie werden kaschiert. Ein ERP, das keine Echtzeit-Bestände kann, kann sie auch hinter einer eleganten Next.js-Schicht nicht. Das Caching, das die Last senkt, ist gleichzeitig der Mechanismus, der veraltete Daten ausliefert. Self-hosted funktioniert ISR-Caching automatisch nur bei *einer* next start-Instanz mit persistentem Disk — sobald Sie auf Multi-Instance oder CDN gehen, brauchen Sie einen Custom Cache Handler, etwa auf Redis-Basis, mit Tag-Koordination über mehrere Knoten. Das ist der technisch genuin schwierige Teil dieses Musters, und er wird unterschätzt, weil der Happy Path so einfach aussieht.

Den Betrieb dieser Schicht haben wir mehrfach self-hosted aufgesetzt — auf Hetzner, via Coolify und Docker, mit output: 'standalone'. Der Einstieg liegt bei rund 20 bis 50 Euro im Monat, eine hochverfügbare Variante mit redundanten Instanzen und separater Datenbank eher bei 150 bis 400 Euro. Die saubere Erstimplementierung eines solchen Stacks rechnen wir mit 5.000 bis 20.000 Euro einmalig, der laufende Betrieb mit zwei bis fünf Stunden im Monat. Das ist überschaubar — solange die Schicht eine Schicht bleibt und kein zweites Backend wird.

Bauen Sie die Schicht so dünn wie möglich. Sie proxyt, sie aggregiert, sie transformiert, sie cached — mehr nicht. In dem Moment, in dem jemand vorschlägt, "ein bisschen Geschäftslogik" hineinzulegen, weil es gerade praktisch ist, halten Sie inne. Geschäftslogik gehört ins System of Record oder in einen dedizierten Service, nicht in die Integrationsschicht. Diese Disziplin ist der Unterschied zwischen einer eleganten Entkopplung und einem verteilten Monolithen.

Behandeln Sie die Schicht als temporär, auch wenn sie es nicht ist. Die Würgefeige soll den alten Baum ersetzen, nicht permanent umklammern. Microsoft warnt zu Recht: Die Routing-Facade darf nicht zur ossifizierten technischen Schuld erstarren. Planen Sie von Anfang ein, dass Funktionen aus dem Legacy in echte neue Services wandern und die Schicht entsprechend schrumpft. Eine Integrationsschicht, die nach drei Jahren genauso fett ist wie am Tag eins, hat ihren Zweck verfehlt.

Und entscheiden Sie ehrlich, ob Sie überhaupt ein Frontend-Problem oder ein Backend-Integrationsproblem haben. Hat die Aggregation Frontend-Bezug, ist Next.js eine gute, schnell lieferbare Wahl — das haben wir mehrfach von der Entscheidung bis zum Go-Live in unter 90 Tagen gebracht. Ist es reine Backend-zu-Backend-Integration, nehmen Sie eine Plattform, die dafür gebaut ist. Die ganze Mechanik, die Next.js self-hosted und souverän betreibbar macht, habe ich in der Übersicht zu Next.js als strategischer Architekturentscheidung zusammengefasst. Die Technologie ist nicht das Schwierige an diesem Muster. Die Disziplin ist es.