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 Ihren Code in fünf Jahren überhaupt noch anfassen können. Diese drei Dimensionen entscheiden sich, bevor die erste Produktseite gerendert ist.
Warum „Next.js Medusa statt SAP Commerce" eine strategische, keine technische Frage ist
Technisch können Sie 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 Sie SAP Commerce + Angular wählen, kaufen Sie nicht nur Software. Sie kaufen ein Operating Model, einen Lizenzpfad, einen Zertifizierungsmarkt für Dienstleister und einen Hiring-Markt für Entwickler. Diese vier Dinge bestimmen Ihre 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 brauchen Sie also gleichzeitig Java/Spring-Kompetenz im Backend und Angular-Kompetenz im Frontend. Das ist kein Detail, das ist Ihr Personalplan für die nächsten Jahre.
Die Gesamtrechnung: Lizenz, Betrieb, Agenturabhängigkeit
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. Sie kalkulieren gegen eine Zahl, die Sie erst nach Vertragsverhandlung kennen und die typischerweise an Ihr Bruttowarenvolumen gekoppelt ist – also mit Ihrem 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. Sie zahlen diese Bequemlichkeit nur damit, dass Sie die Infrastruktur, auf der Ihr Umsatz läuft, nie selbst in der Hand haben. Datensouveränität und Datenlokalisierung sind dann keine Stellschrauben mehr, sondern Vertragsanhänge – und im Drittstaatentransfer schnell ein NIS2- und DSGVO-Thema, das Sie nicht selbst steuern.
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: Sie wählen nicht aus dem freien Markt, Sie wählen 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 Ihr Wissen an ein Ökosystem bindet.
Stellen Sie 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 Ihr 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.
Angular vs React: ein Skill-Set, das nicht mithält
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 Sie auf Angular setzen, rekrutieren Sie aus einem kleineren Pool, zahlen tendenziell mehr für Spezialisten und sind stärker an einen Dienstleister gebunden, der das Skill-Set vorhält. Wenn Sie auf React/Next.js setzen, greifen Sie auf den größten Frontend-Entwicklermarkt der Welt zu – einfacheres Hiring, größerer Freelancer-Pool, geringeres Risiko, dass ein Agenturwechsel Sie 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 Sie ohnehin neu aufsetzen und den breiteren Markt mitnehmen könnten.
Was Next.js + Medusa technisch tatsächlich liefert
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 Sie ohne Vercel verlieren, 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 Sie über mehrere Instanzen hinter einem CDN skalieren, brauchen Sie 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 Sie bei SAP an die Lizenz delegieren. Wer Medusa und Next.js neu bewertet, sollte vorher verstehen, was Medusa.js eigentlich ist und für welche Commerce-Profile es gedacht ist.
Der unbequeme Punkt: Wenn SAP die wirtschaftlich richtige Wahl bleibt
Jetzt die ehrliche Komplikation, ohne die jede Empfehlung Marketing wäre.
Wenn Ihre Organisation bereits tief in einer SAP-ERP-Landschaft steckt, zahlen Sie 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 bauen Sie 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: Sie bekommen einen Startpunkt, kein Produkt. Was Sie damit bauen, pflegen Sie 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.
Was ich Entscheidern rate
Trennen Sie 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 Ihrer Ausgangslage, nicht an SAPs Gartner-Position.
Machen Sie die Gesamtrechnung auf, bevor Sie unterschreiben. 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. Rechnen Sie über drei Jahre, nicht über das erste. Und rechnen Sie die Richtung der Kostenkurve mit, nicht nur den Startpunkt.
Wenn Sie ein Greenfield-Projekt ohne tiefe SAP-ERP-Bindung haben, ist Next.js + Medusa für mich der Default – aus strategischen Gründen, nicht aus technischer Mode. Sie kaufen Investitionssicherheit, technologische Souveränität und Entwicklerverfügbarkeit statt eines Vertrags, der mit Ihrem Erfolg teurer wird. Wenn Sie tief in SAP stecken und hochkomplexe B2B-Prozesse fahren, bleibt SAP eine verteidigbare Wahl – solange Sie wissen, was Sie mit der Bequemlichkeit mitkaufen. Was Sie nicht tun sollten: 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-Übersicht zusammengeführt.
