Next.js Medusa statt SAP Commerce: Warum ich den Open-Source-Stack vorziehe

Die Wahl SAP Commerce + Angular wird in den meisten Pitches als Enterprise-Standard verkauft, ohne dass jemand die Gesamtrechnung aufmacht. Genau das ist der teure Teil – nicht die Lizenz, sondern die Annahme, dass „sicher" und „SAP" dasselbe seien.

Wir bauen Commerce-Stacks selbst, betreiben sie auf eigener Infrastruktur und sitzen in Pitches, in denen am Ende ein CFO die Zahlen sehen will. Aus dieser Perspektive ist die Frage „Next.js Medusa statt SAP Commerce" keine Geschmacksfrage zwischen zwei Frameworks. Sie ist eine Entscheidung über Total Cost of Ownership, Vendor-Lock-in und darüber, wie viele Menschen deinen Code in fünf Jahren überhaupt noch anfassen können. Diese drei Dimensionen entscheiden sich, bevor die erste Produktseite gerendert ist.

Technisch kannst du mit SAP Commerce Cloud einen exzellenten Shop bauen. Das ist nicht der Streitpunkt. SAP steht seit Jahren durchgehend als Leader im Gartner Magic Quadrant for Digital Commerce – wer behauptet, SAP Commerce sei ein schlechtes Produkt, hat es nie ernsthaft betrieben.

Der Punkt ist ein anderer. Eine Technologieentscheidung ist immer auch eine strategische, kulturelle und machtpolitische Entscheidung. Wenn du SAP Commerce + Angular wählst, kaufst du nicht nur Software. Du kaufst ein Operating Model, einen Lizenzpfad, einen Zertifizierungsmarkt für Dienstleister und einen Hiring-Markt für Entwickler. Diese vier Dinge bestimmen deine Kostenkurve über Jahre – und sie tauchen in keinem Architektur-Diagramm auf.

Die architektonische Realität von SAP Commerce ist dabei selbst schon ein Argument. Im Kern ist CCv2 eine Java/Spring-Anwendung (das ehemalige Hybris) auf eingebettetem Tomcat, mit der OCC-REST-API als Schnittstelle. Die Composable Storefront, Spartacus, ist ein Angular-Frontend, das ausschließlich über diese Commerce-REST-API spricht. In der Praxis brauchst du also gleichzeitig Java/Spring-Kompetenz im Backend und Angular-Kompetenz im Frontend. Das ist kein Detail, das ist dein Personalplan für die nächsten Jahre.

Fangen wir bei der Lizenz an, weil sie das ehrlichste Signal ist. Die offizielle SAP-Pricing-Seite für Commerce Cloud nennt keinerlei Editions- oder Preisangaben. Sie verweist auf „Request a demo" und „Request a quote". Das ist kein Versäumnis im Marketing, das ist das Geschäftsmodell: ein verhandlungsbasiertes, intransparentes Enterprise-Lizenzmodell.

Für einen Entscheider, der vor dem Vorstand eine TCO-Rechnung verteidigen muss, ist das ein strukturelles Problem. Du kalkulierst gegen eine Zahl, die du erst nach Vertragsverhandlung kennst und die typischerweise an dein Bruttowarenvolumen gekoppelt ist – also mit deinem Erfolg steigt. Kursierende Schätzungen sechs- bis siebenstelliger Jahresbeträge plus Implementierungskosten stammen ausnahmslos von SAP-Partnern, nicht von SAP selbst. Ich zitiere sie bewusst nicht als Fakt, sondern als das, was sie sind: interessengeleitete Spannen. Genau diese Intransparenz ist Teil der Rechnung.

Der Betrieb ist im Lizenzmodell elegant gelöst und gleichzeitig der Kern der Abhängigkeit. CCv2 läuft als managed PaaS auf Microsoft Azure, mit Kubernetes und Azure SQL, SAP betreibt die Build- und Deploy-Pipelines. Hosting ist enthalten. Das klingt bequem – und ist es auch.

Du zahlst diese Bequemlichkeit nur damit, dass du die Infrastruktur, auf der dein Umsatz läuft, nie selbst in der Hand hast. Datensouveränität und Datenlokalisierung sind dann keine Stellschrauben mehr, sondern Vertragsanhänge. Im Drittstaatentransfer werden sie schnell ein NIS2- und DSGVO-Thema, das du nicht selbst steuerst.

Dann die Agenturabhängigkeit. SAP betreibt mit PartnerEdge ein eigenes Build/Sell/Service/Run-Programm, und Einführung wie Betrieb laufen praktisch über zertifizierte Systemintegratoren. Das ist ein struktureller Kostenfaktor: Du wählst nicht aus dem freien Markt, du wählst aus einem zertifizierten Pool. Ein proprietäres Format wie ImpEx (SAPs modellnahes Import/Export-Format, das Typhierarchien und Katalogversionen versteht) verstärkt das. Es ist technisch sinnvoll und gleichzeitig eine Datenstruktur, die dein Wissen an ein Ökosystem bindet.

Stell dem die andere Seite gegenüber. Medusa ist unter echter MIT-Lizenz verfügbar – kein Open-Core, kein BSL, kein Lizenz-Bait-and-Switch. Der Kern ist vollständig self-hostbar, PostgreSQL ist die produktive Datenbank.

Bei einem self-hosted Stack auf eigener Infrastruktur (wir betreiben so etwas DSGVO-konform in Deutschland auf Hetzner) liegt der Einstieg im niedrigen zweistelligen Euro-Bereich pro Monat, ein hochverfügbares Setup mit redundanten Instanzen und separater Datenbank grob im Bereich einiger hundert Euro pro Monat. Die saubere Erstimplementierung kostet einmalig im fünfstelligen Bereich, der laufende Betrieb wenige Stunden im Monat.

Der entscheidende Unterschied ist die Richtung der Kostenkurve. Self-hosted Kosten sinken über die Zeit, weil Hardware billiger und dein Team routinierter wird. Lizenz- und Managed-Kosten steigen mit dem Projekterfolg, weil sie an Volumen, Nutzer oder GMV hängen. Diese Mechanik haben wir auch im Vergleich Hetzner statt Vercel durchgerechnet – sie kippt eine Make-or-Buy-Entscheidung oft erst im zweiten oder dritten Jahr.

Die Framework-Frage wird gern als Religionskrieg abgetan. Sie ist aber knallhart ein Thema der Entwicklerverfügbarkeit, und damit ein FinOps- und Risiko-Thema.

Die Zahlen sind eindeutig. Die Stack Overflow Developer Survey 2025 weist React bei rund 45 Prozent aller Befragten aus, Angular bei rund 18 Prozent – React wird also etwa zweieinhalbmal so häufig genutzt. Bei professionellen Entwicklern verschiebt sich das Verhältnis kaum.

Im State of JS 2024 führt React klar, Angular wurde bei der Nutzung sogar von Vue auf Platz drei verdrängt. Die npm-Download- und GitHub-Zahlen zeigen dieselbe Richtung, auch wenn rohe npm-Werte durch CI-Pipelines aufgebläht sind und nur eine Größenordnung liefern, kein exaktes Verbreitungsmaß. Mehrere unabhängige Quellen, dieselbe Konvergenz: React wird breiter getragen.

Was bedeutet das operativ? Wenn du auf Angular setzt, rekrutierst du aus einem kleineren Pool, zahlst tendenziell mehr für Spezialisten und bist stärker an einen Dienstleister gebunden, der das Skill-Set vorhält. Wenn du auf React/Next.js setzt, greifst du auf den größten Frontend-Entwicklermarkt der Welt zu – einfacheres Hiring, größerer Freelancer-Pool, geringeres Risiko, dass ein Agenturwechsel dich monatelang lähmt. Für einen CIO, der Entwicklerverfügbarkeit als Run-the-Business-Risiko führt, ist das kein Nice-to-have, sondern Vendor Risk Management.

Ich will fair bleiben, denn hier liegt eine echte Stärke. Angular ist opinionated, stabil und langfristig gewartet. In großen, governance-getriebenen Organisationen ist genau das ein Vorteil: weniger Wildwuchs, klare Konventionen, ein Framework, das Entscheidungen vorgibt, statt sie jedem Team zu überlassen. Wer ein 200-köpfiges Frontend-Team über fünf Jahre konsistent halten muss, hat mit Angular gute Gründe. Diese Stärke ist real. Sie rechtfertigt nur nicht jede Greenfield-Entscheidung, in der du ohnehin neu aufsetzt und den breiteren Markt mitnehmen könntest.

Damit das kein abstraktes Souveränitäts-Argument bleibt: Der Stack trägt auch funktional. Next.js mit React Server Components reduziert das an den Browser gesendete JavaScript spürbar, weil nur explizit als Client markierte Komponenten im Client-Bundle landen. Das verbessert laut Dokumentation den First Contentful Paint. Incremental Static Regeneration liefert für die meisten Requests vorgerenderte statische Seiten nach dem stale-while-revalidate-Prinzip und senkt die Serverlast – relevant, wenn aus Performance Conversion wird.

Beim Self-Hosting ist die gute Nachricht: Die offizielle Next.js-Self-Hosting-Doku bestätigt, dass ein Node.js-Server und Docker alle Features unterstützen. Die next/image-Optimierung läuft self-hosted ohne Zusatzkonfiguration, Middleware ebenso. Was du ohne Vercel verlierst, ist nicht die Funktion, sondern die global verteilte Edge-Ausführung. Das ist ein ehrlicher, kleiner Preis für die meisten DACH-Shops, deren Traffic ohnehin regional ist.

Den genuin schwierigen Teil verschweige ich nicht: ISR-Caching funktioniert automatisch nur bei einer einzelnen Instanz mit persistentem Disk. Sobald du über mehrere Instanzen hinter einem CDN skalierst, brauchst du einen Custom Cache-Handler, etwa auf Redis- oder S3-Basis, plus geteilte Encryption-Keys und stabile Deployment-IDs. Das ist genau das Wertangebot, das Vercel schwer nachbaubar macht.

Es ist lösbar, mit Coolify, Docker und etwas Betriebsdisziplin. Aber es ist Betriebsverantwortung, die du bei SAP an die Lizenz delegierst. Wer Medusa und Next.js neu bewertet, sollte vorher verstehen, was Medusa.js eigentlich ist und für welche Commerce-Profile es gedacht ist.

Jetzt die ehrliche Komplikation, ohne die jede Empfehlung Marketing wäre.

Wenn deine Organisation bereits tief in einer SAP-ERP-Landschaft steckt, zahlst du bei Medusa genau die Integrationsarbeit, die SAP Commerce mitbringt. SAP Commerce ist in eine bestehende SAP-Welt (Bestand, Preise, Aufträge, Kunden) nativ eingebettet. Diese Integration ist real und teuer nachzubauen. Mit Medusa baust du die Brücke zwischen Shop und ERP selbst, und das ist kein Wochenendprojekt, sondern ein Integrationsprojekt mit eigenem Risikoprofil.

Zweitens ist Medusa jünger. Die 2.0-GA war im Oktober 2024, und der Sprung von v1 auf v2 brachte Breaking Changes und Migrationsaufwand. Wichtiger noch: Für tiefe B2B-Prozesse liefert der Kern nur begrenzte Bausteine – Sales Channels, Customer Groups, Price Lists. Funktionen wie Company-Management, Spending Limits oder Quote-/Approval-Workflows kommen aus dem offiziellen b2b-starter. Und der ist ausdrücklich Boilerplate und Referenzcode, kein gepflegtes Out-of-the-box-Produktfeature. Diese Unterscheidung ist entscheidend: Du bekommst einen Startpunkt, kein Produkt. Was du damit baust, pflegst du selbst.

Für hochkomplexe B2B-Commerce-Prozesse mit tiefer ERP-Verzahnung kann SAP Commerce deshalb die wirtschaftlich richtige Wahl bleiben. Nicht weil es „sicherer" klingt, sondern weil die Summe aus mitgelieferter Integration und reifen Enterprise-Modulen den Eigenbauaufwand überkompensiert. Das ist eine seltene, aber reale Konstellation. Wer sie hat, sollte SAP nehmen – mit offenen Augen für den Lock-in, nicht trotz ihm.

Welche Commerce-Profile gut zu Medusa passen und welche nicht, lässt sich entlang konkreter Anforderungen sauber durchspielen. Wir haben das nach der Frage für wen Headless Commerce mit Medusa taugt sortiert.

Trenn zwei Fragen, die in Pitches systematisch vermischt werden: „Ist SAP Commerce ein gutes Produkt?" und „Ist SAP Commerce die richtige Entscheidung für uns?". Die erste Antwort ist oft ja. Die zweite hängt an deiner Ausgangslage, nicht an SAPs Gartner-Position.

Mach die Gesamtrechnung auf, bevor du unterschreibst. Lizenz plus Renewals plus Implementierung plus zertifizierter Betrieb plus ein knapper, teurer Angular-und-Java-Hiring-Markt – gegen einen MIT-lizenzierten, PostgreSQL-nativen, self-hostbaren Stack mit dem größten Frontend-Entwicklerpool der Welt. Rechne über drei Jahre, nicht über das erste. Und rechne die Richtung der Kostenkurve mit, nicht nur den Startpunkt.

Wenn du ein Greenfield-Projekt ohne tiefe SAP-ERP-Bindung hast, ist Next.js + Medusa für mich der Default – aus strategischen Gründen, nicht aus technischer Mode. Du kaufst Investitionssicherheit, technologische Souveränität und Entwicklerverfügbarkeit statt eines Vertrags, der mit deinem Erfolg teurer wird.

Wenn du tief in SAP steckst und hochkomplexe B2B-Prozesse fährst, bleibt SAP eine verteidigbare Wahl – solange du weißt, was du mit der Bequemlichkeit mitkaufst. Was du nicht tun solltest: die Entscheidung als „sicheren Standard" kaufen, ohne die Rechnung gesehen zu haben.

Wer eine Architektur kauft, ohne die Gesamtkosten zu kennen, kauft die Interessen seines Dienstleisters gleich mit. Wie sich so ein Stack im größeren Next.js-Kontext einordnet, haben wir auf unserer Next.js-Agentur-Seite zusammengeführt.

Du stehst vor genau dieser Entscheidung und willst die Gesamtrechnung für deinen Fall aufmachen? Dann lass uns sprechen: In einem unverbindlichen Beratungsgespräch schauen wir gemeinsam auf deine Ausgangslage, deine ERP-Landschaft und die Richtung deiner Kostenkurve.