Die Frage kommt selten als Frage. Sie kommt als Feststellung: "Wir wollen headless gehen." Dahinter steht fast ausnahmslos etwas Konkretes -- ein Kundenportal, das sich im Standard-Template nur mit Gewalt abbilden lässt, eine Außendienst-Anwendung, ein Thekenterminal in der Niederlassung, ein Katalog mit sechsstelliger Artikelzahl. Die Architektur ist dabei nur die Antwort auf eine Frage, die vorher gestellt werden sollte: Wie viele Ausgabekanäle sollen aus einem Katalog bedient werden, und wer betreibt sie in drei Jahren? Dieser Beitrag sortiert die Begriffe, benennt die vier Treiber, die im B2B tatsächlich für eine Entkopplung sprechen, rechnet die Gegenseite offen mit -- und zeigt den hybriden Weg, mit dem die meisten mittelständischen Projekte am Ende besser fahren.
Das Wichtigste in Kürze
- Headless meint ein entkoppeltes Frontend an der Store API, Composable eine modular zusammengesetzte Systemlandschaft, API-first Funktionen, die als Schnittstelle bereitstehen. Ein Shop kann composable sein und trotzdem das Standard-Storefront nutzen.
- Für eine Entkopplung sprechen vier Konstellationen jeweils für sich: mehr als zwei Ausgabekanäle auf einem Katalog, Portal-Logik weit abseits des Standards, sehr große variantenreiche Kataloge mit eigener Suchschicht und ein dauerhaft besetztes Frontend-Team.
- Ein eigenes Frontend verlagert Aufgaben, statt sie zu sparen: doppelte Wartung, zweite Deployment-Strecke, Feature-Lücke gegenüber den Bordmitteln und die volle SEO-Verantwortung für Rendering, Statuscodes, Canonicals und hreflang im eigenen Code.
- Der hybride Zuschnitt lässt öffentliche Kategorie- und Produktseiten im serverseitigen Standard-Storefront und baut nur Kundenportal, Schnellerfassung, Konfigurator oder Auswertungen als eigene Anwendung – hinter dem Login entfällt das SEO-Risiko.
- Schneller wird ein Shop durch die Entkopplung nicht automatisch: Maßstab bleiben LCP 2,5 Sekunden, INP 200 Millisekunden und CLS 0,1 im 75. Perzentil (Google web.dev). Kundenindividuelle Preise senken zusätzlich die Cache-Trefferquote.
- Voll entkoppelt trägt nur, wenn Kanalzahl, Team und Betriebsbudget zusammenkommen; fehlt eines davon, bleibt der Standard wirtschaftlicher (Projekterfahrung). Der Umbau läuft in Etappen: erst Datenverträge zu PIM und ERP, dann ein Bereich hinter dem Login.
Drei Begriffe, die nicht dasselbe meinen
Headless beschreibt genau eine Sache: Das Frontend ist von der Shop-Anwendung getrennt und holt sich Daten und Funktionen über eine API. In Shopware ist das die Store API. Sie ist laut Hersteller die kundenseitige Oberfläche der Plattform, liefert JSON über HTTP und erlaubt damit eigenständige Frontends wie Single-Page-Anwendungen oder native Apps (Shopware Developer Documentation). Entscheidend für die Risikobewertung ist ein Detail aus derselben Quelle: Standard-Storefront und API-Konsumenten greifen auf dieselben darunterliegenden Services zu (Shopware Developer Documentation). Die Geschäftslogik wird also nicht dupliziert -- dupliziert wird die Darstellungsschicht.
Headless
Ein entkoppeltes Frontend spricht über die Store API mit dem Shop. Warenkorb, Preise, Verfügbarkeit und Checkout bleiben im Backend, die Oberfläche wird eigenständig gebaut und deployt.
Composable
Mehrere Systeme werden modular zusammengesetzt: Shop, PIM, ERP, Redaktionssystem und Suchschicht. Das ist eine Aussage über die Systemlandschaft, nicht über das Frontend.
API-first
Funktionen stehen vor der Oberfläche als Schnittstelle bereit. Das gilt in Shopware bereits im Standard und ist keine Entscheidung, die man erst treffen müsste.
Die Trennung ist keine Wortklauberei, sondern hat Kostenfolgen. Ein Shop kann headless sein, ohne composable zu sein -- ein eigenes Frontend auf einer einzigen Plattform. Und er kann composable sein, ohne headless zu sein: Standard-Storefront, dahinter aber saubere Schnittstellen zu ERP, PIM und Suche. Genau dieser zweite Fall ist im Mittelstand der Regelfall, und er ist deutlich günstiger zu betreiben. Wie weit die Integrationsdisziplin dafür trägt, zeigt das B2BEST Barometer: 51 Prozent (ECC Köln) der befragten Großhändler und Hersteller verbinden ihre Systeme über starre Punkt-zu-Punkt-Verbindungen, während erst 35 Prozent (ECC Köln) ein API-Management einsetzen. Wer auf dieser Basis modular werden möchte, baut zuerst die Integrationsschicht -- nicht das Frontend.
Die Frage vor der Technikfrage
Vier Treiber, die im B2B wirklich für Headless sprechen
Der digitale Kanal ist im Geschäftskundengeschäft längst der Hauptweg: 83 Prozent (Gartner) der B2B-Einkäufer bestellen und bezahlen am liebsten digital, und Gartner erwartet, dass bis 2027 rund 60 Prozent (Gartner) der E-Commerce-Unternehmen einem Composable-Ansatz folgen. Daraus folgt allerdings nicht, dass jedes Unternehmen ein eigenes Frontend braucht. In der Projektpraxis tragen vier Konstellationen die Entscheidung -- und zwar einzeln, nicht als Summe von Halbargumenten.
Mehrere Ausgabekanäle auf einem Katalog
Shop, Kundenportal, Außendienst-Anwendung, Kiosk oder Thekenterminal und Punchout-Katalog im Beschaffungssystem greifen auf dieselben Artikel, Preise und Bestände zu. Ab dem dritten echten Kanal wird die gemeinsame API zur tragenden Struktur statt zur Zusatzleistung.
Portal-Logik weit abseits des Standards
Rahmenverträge, Budgetgrenzen, mehrstufige Freigaben, Kostenstellen, Objektbestellungen: Wenn die Oberfläche eher Verwaltung als Katalog ist, arbeitet ein Template gegen die Anforderung. Solche Bereiche entstehen sinnvoll als eigene Anwendung in der B2B-Portal-Entwicklung.
Sehr große, variantenreiche Kataloge
Bei Hunderttausenden Artikeln mit technischen Attributen übernimmt eine eigene Suchschicht Filterung, Facetten und Artikelnummernlogik. Das Frontend wird dann ohnehin zum Konsumenten mehrerer Dienste -- die Entkopplung folgt der Datenlage.
Bestehendes Frontend-Team mit eigenem Stack
Wo bereits eine Entwicklungsmannschaft mit eigener Toolchain, Design-System und Release-Prozess arbeitet, ist ein entkoppeltes Frontend kein Zusatzaufwand, sondern die Fortsetzung vorhandener Arbeitsweise. Fehlt dieses Team, kehrt sich der Effekt um.
Der zweite und der dritte Punkt sind im Mittelstand die häufigsten. Der vierte ist der ehrlichste: Ohne dauerhaft verfügbare Frontend-Kompetenz wird aus der Entkopplung ein Klumpenrisiko. Das Barometer stützt diese Vorsicht -- 38 Prozent (ECC Köln) der befragten Unternehmen nennen zu wenig IT-Personal als Hemmnis, 39 Prozent (ECC Köln) die hohen Kosten für die Pflege der Infrastruktur. Gleichzeitig geben 34 Prozent (ECC Köln) an, dass der mobile Zugriff auf ihre Systeme eingeschränkt ist -- was den Wunsch nach Außendienst- und Terminal-Anwendungen erklärt, aber eben auch die Personalfrage verschärft.
- Mehr als zwei Ausgabekanäle, die denselben Katalog benötigen, sind konkret geplant -- nicht gewünscht, sondern terminiert
- Der Sonderbereich weicht in Datenmodell und Bedienlogik so stark ab, dass Template-Anpassungen zur Dauerbaustelle werden
- Eine eigene Suchschicht ist bereits im Einsatz oder unvermeidbar, etwa wegen Artikelnummernsuche und Nulltreffer-Vermeidung
- Frontend-Entwicklung ist als Rolle besetzt, nicht als Projektaushilfe eingeplant
- Für zwei Deployment- und Update-Strecken existiert ein Betriebsbudget, das über den Projektzeitraum hinausreicht
Die Gegenrechnung: was dauerhaft dazukommt
Ein entkoppeltes Frontend halbiert keine Arbeit, es verteilt sie anders. Was im Standard-Storefront durch Updates der Plattform mitkommt, wird im eigenen Frontend zur eigenen Aufgabe -- dauerhaft, nicht einmalig. Diese Posten gehören in jede Aufwandsschätzung, weil sie den Betrieb und nicht das Projekt belasten.
- Doppelte Wartung: Zwei Anwendungen mit eigenen Abhängigkeiten, Sicherheitsupdates und Release-Zyklen. Ein Shopware-Update kann Anpassungen im Frontend nach sich ziehen, wenn sich API-Antworten ändern
- SEO-Verantwortung: Serverseitiges Rendering, Statuscodes, Weiterleitungen, Canonicals, hreflang-Auszeichnung und strukturierte Daten liegen im eigenen Code
- Feature-Lücke gegenüber Bordmitteln: Erlebniswelten, Landingpages, Merchandising-Funktionen und Erweiterungen aus dem Ökosystem greifen im Standard-Template, im eigenen Frontend meist nicht
- Abhängigkeit von Frontend-Know-how: Der Bereich lässt sich kaum nebenbei betreuen; Urlaub, Wechsel und Krankheit werden zu Betriebsrisiken
- Höhere laufende Kosten: Zusätzliche Laufzeitumgebung, Build- und Deployment-Pipeline, Monitoring, Fehlerverfolgung und ein zweiter Sicherheitsprozess
Der SEO-Punkt wird am häufigsten unterschätzt. Google verarbeitet JavaScript-Anwendungen in drei Schritten -- Crawlen, Rendern, Indexieren -- und stellt Seiten dafür in eine Warteschlange: "The page may stay on this queue for a few seconds, but it can take longer than that" (Google Search Central). Die Empfehlung der gleichen Quelle ist unmissverständlich: "Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Search Central). Übersetzt heißt das: Ein entkoppeltes Frontend für öffentliche Kategorie- und Produktseiten ist machbar, verlangt aber serverseitiges Rendering, saubere Verlinkung über echte Anker mit href-Attribut und ein Team, das diese Themen aktiv verantwortet. Wie stark Ladeverhalten und Sichtbarkeit zusammenhängen, ordnet unsere Performance-Optimierung für B2B-Shops ein.
Was mitgeliefert wird, muss sonst nachgebaut werden
Der hybride Mittelweg
Zwischen "alles bleibt wie es ist" und "wir bauen alles neu" liegt der Weg, den die meisten B2B-Projekte tatsächlich brauchen. Das Standard-Storefront bleibt für Startseite, Kategorien, Produktdetails, Content und Checkout bestehen -- also für alles, was öffentlich, indexierbar und funktional gut abgedeckt ist. Nur einzelne Bereiche werden als eigenständige Anwendung über die Store API gebaut, dort, wo der Standard erkennbar an seine Grenzen kommt. Shopware stellt für solche Frontends eine eigene, auf Vue und Nuxt aufsetzende Referenzimplementierung samt API-Client und Composables bereit, die die Store API konsumiert (Shopware Developer Documentation).
Kundenportal hinter dem Login
Bestellhistorie, Rahmenverträge, Freigaben, offene Posten und Dokumente. Der Bereich ist ohnehin nicht indexierbar -- das SEO-Argument gegen Headless entfällt hier vollständig. Details im Beitrag zu B2B-Kundenportalen und Self-Service.
Schnellerfassung und Bestelllisten
Artikelnummern-Eingabe, CSV-Import, wiederkehrende Warenkörbe: eine tastaturgetriebene Maske, die von einer Katalogoberfläche grundverschieden ist und von eigener Zustandslogik profitiert.
Konfigurator und Varianten
Mehrstufige Auswahl mit Regeln, Abhängigkeiten und Preisfindung. Solche Strecken sind Anwendungen, keine Seiten -- und sie profitieren von einem eigenen Frontend deutlich stärker als eine Kategorieseite.
Dashboard und Auswertungen
Einkaufsvolumen je Kostenstelle, Budgetstände, Lieferstatus. Datenintensive Ansichten mit Filtern und Tabellen sind der klassische Fall für eine eigene Anwendung hinter der Anmeldung.
Der wirtschaftliche Vorteil dieses Zuschnitts liegt in der Risikoverteilung. Die suchmaschinenrelevanten Flächen bleiben serverseitig und in der Verantwortung der Plattform, während der Zusatzaufwand genau dort entsteht, wo er messbaren Nutzen stiftet. Fällt das Portal-Team aus, steht der Vertriebskanal weiter -- der Shop verkauft. Diese Trennung ist auch budgetseitig sauberer, weil sich der Sonderbereich als eigener Posten kalkulieren und in der Entwicklung eines B2B-Kundenportals etappenweise ausbauen lässt.
Die teuerste Architektur ist die, die für einen einzelnen Bereich gewählt und anschließend für alles verbindlich gemacht wurde.
Architektur: Datenfluss, Caching und Sessions
Unabhängig vom Frontend-Modell bleibt der Datenfluss die eigentliche Arbeit. Stammdaten und Medien kommen aus dem PIM, Preise, Bestände und Belege aus dem ERP, und Bestellungen laufen denselben Weg zurück. Der Shop ist in dieser Kette kein Datenhaushalt, sondern ein Verteiler mit Vertrag -- und dieser Vertrag ist im Headless-Fall die API. Grundsätzliche Entwurfsmuster dafür beschreibt der Beitrag zur Schnittstellen-Architektur im B2B, die konkrete Umsetzung gehört in die Schnittstellen- und Integrationsarbeit.
- PIM liefert die Beschreibung: Attribute, Klassifikationen, Medien, Texte und Übersetzungen -- vollständig und versioniert, nicht als Ad-hoc-Export
- ERP liefert die Fakten: Preise inklusive Kunden- und Staffelkonditionen, Bestände, Lieferzeiten, Kreditlimits und Belegstatus
- Delta-Synchronisation statt Vollimport: Zeitstempel oder Änderungszähler begrenzen die Last; Vollabgleiche laufen als planbarer Sonderfall
- Index- und Suchschicht: Facetten, Artikelnummernlogik und Sortierungen werden aufbereitet, damit das Frontend nicht bei jeder Anfrage rechnet
- Frontend konsumiert die Store API: Katalog, Warenkorb, Kundenkonto und Checkout laufen über dieselben Services wie das Standard-Storefront
- Rücklauf ins ERP: Bestellungen, Kundenanlagen, Adressänderungen und Zahlungsinformationen fließen zurück -- inklusive der Frachtlogik, die der Beitrag zu Versandkosten und Speditionsfracht im B2B-Shop im Detail behandelt
Beim Caching wird es im B2B unbequem. Shopware bezeichnet den HTTP-Cache in der eigenen Dokumentation als "a must-have for every production system" und empfiehlt für Produktivsysteme einen vorgelagerten Reverse-Proxy-Cache; für den Objekt-Cache wird ein speicherbasierter Adapter statt der Dateiablage empfohlen (Shopware Developer Documentation). Zusätzlich lassen sich Zwischenspeicherung und Laufzeit einzelner Store-API-Routen über Cache-Richtlinien steuern (Shopware Developer Documentation). Der B2B-Haken: Kundenindividuelle Preise, Kontingente und Sichtbarkeiten personalisieren fast jede Antwort. Cachebar bleiben dann vor allem Struktur und Beschreibung, während Preis und Verfügbarkeit gezielt nachgeladen werden. Die Invalidierung über Cache-Tags braucht eine eigene Betriebsroutine, weil verwaiste Einträge sonst mit der Zeit den Speicher füllen (Shopware Developer Documentation).
Der dritte Klassiker sind Anmeldung und Sitzung. Die Store API arbeitet je Verkaufskanal mit einem Zugriffsschlüssel und führt den Zustand einer Sitzung -- Warenkorb, Anmeldung, Kontext -- über ein Kontext-Token; anonyme und angemeldete Zugriffe sind ausdrücklich vorgesehen (Shopware Developer Documentation). Bei Firmenkunden kommt die Organisationsebene dazu: mehrere Benutzer je Kundenkonto, unterschiedliche Rollen, Freigabegrenzen und Kostenstellen. Läuft das Frontend auf einem anderen Host als der Shop, gehören Cookie-Domäne, SameSite-Verhalten, Token-Lebensdauer und der Wechsel zwischen Portal und Checkout in die Architekturskizze -- nicht in die Testphase.
Rechte gehören ins Backend
Performance: Headless ist nicht automatisch schneller
Die Erwartung, ein entkoppeltes Frontend sei per se schneller, hält der Messung selten stand. Maßstab sind die Core Web Vitals mit ihren Schwellenwerten: 2,5 Sekunden für den Largest Contentful Paint, 200 Millisekunden für Interaction to Next Paint und 0,1 für Cumulative Layout Shift, jeweils bewertet am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop (Google web.dev). Das ist die Messlatte -- unabhängig davon, welche Architektur dahinter arbeitet.
Wie schwer diese Latte zu nehmen ist, zeigen die Felddaten: 43 Prozent (HTTP Archive Web Almanac) der Websites erreichten mobil gute Werte in allen drei Metriken, auf dem Desktop waren es 54 Prozent (HTTP Archive Web Almanac). Bei den Einzelmetriken erreichten mobil 59 Prozent (HTTP Archive Web Almanac) einen guten LCP, 74 Prozent (HTTP Archive Web Almanac) einen guten INP und 79 Prozent (HTTP Archive Web Almanac) einen guten CLS. Der Engpass liegt also mehrheitlich beim Ladeverhalten der größten Inhalte -- einem Bereich, den ein Frontend-Wechsel allein nicht löst.
Die Rendering-Dokumentation von Google benennt die Zielkonflikte deutlich. Serverseitiges Rendern spart Auslieferung von JavaScript: "Running page logic and rendering on the server lets you avoid sending lots of JavaScript to the client" -- kostet aber Zeit bis zur ersten Antwort: "Generating pages on the server takes time, which can increase your page's TTFB" (Google web.dev). Für rein clientseitiges Rendern gilt die Gegenrichtung: "The amount of JavaScript required tends to grow as an application grows, which can impact a page's INP" (Google web.dev). Und die Hydration hat ihre eigene Falle: Serverseitig gerenderte Seiten können geladen aussehen, ohne auf Eingaben zu reagieren, solange die zugehörigen Skripte nicht ausgeführt sind (Google web.dev).
- Serverantwortzeit: Ein zusätzlicher Netzwerksprung zwischen Frontend-Server und Store API verlängert den Weg, statt ihn zu verkürzen
- Bildstrategie: Formate, Größenvarianten und Priorisierung des LCP-Elements wirken stärker als das Framework darunter
- JavaScript-Umfang: Wächst die Anwendung, wächst die Reaktionszeit -- besonders auf den Geräten, mit denen im Lager und im Außendienst gearbeitet wird
- Cache-Trefferquote: Personalisierte Antworten senken die Wirkung des HTTP-Caches; die Strategie muss zwischen Struktur und Personalisierung trennen
- Datenmenge je Ansicht: Ein Facettenfilter über viele Varianten ist im Backend teuer -- unabhängig davon, wer die Oberfläche rendert
Belastbar wird die Diskussion erst mit Feldwerten aus dem eigenen Shop. Welche Hebel im Shopware-Umfeld messbar wirken und in welcher Reihenfolge sie sinnvoll sind, behandelt der Beitrag zur Performance-Optimierung von B2B-Shops.
Entscheidungsmatrix: drei Wege, sechs Kriterien
Die folgende Matrix ist kein Punktesystem, sondern eine Sortierhilfe. In der Praxis entscheidet selten ein einzelnes Kriterium, sondern die Frage, welche Zeile im eigenen Haus die härteste Grenze setzt -- meistens ist es die Teamgröße oder das Betriebsbudget, nicht die technische Machbarkeit.
| Kriterium | Standard-Storefront | Hybrider Ansatz | Voll entkoppelt |
|---|---|---|---|
| Ausgabekanäle | ein Kanal, klassischer Shop | Shop plus ein bis zwei Sonderbereiche | drei und mehr Kanäle auf einem Katalog |
| Teamgröße | Agentur oder einzelne interne Rolle | Backend-Team plus punktuelle Frontend-Kapazität | eigenes Frontend-Team mit dauerhafter Zuständigkeit |
| Budget | Aufbau und Betrieb im Standardrahmen | Zusatzbudget nur für den Sonderbereich | Budget für Aufbau und Betrieb zweier Anwendungen |
| Time-to-Market | kurz, Bordmittel decken den Standard ab | mittel, der Shop läuft während des Ausbaus weiter | lang, das Frontend entsteht vor dem ersten Umsatz |
| Betriebsaufwand | ein Deployment, ein Monitoring | zwei Deployments mit klar getrennter Verantwortung | zwei Stacks, zwei Update-Zyklen, zwei Sicherheitsprozesse |
| SEO-Risiko | gering, Rendering und Metadaten liefert die Plattform | gering, öffentliche Flächen bleiben serverseitig | erhöht, Rendering, Canonicals und hreflang liegen im eigenen Code |
Lesehilfe für die Praxis: Wer in vier von sechs Zeilen in der linken Spalte landet, hat mit einem gepflegten Standard-Storefront und sauberer Integration die wirtschaftlichere Lösung -- inklusive der B2B-Funktionen, die Shopware in der Open-Source-Variante bereits mitbringt. Wer überwiegend in der mittleren Spalte steht, sollte den Sonderbereich isolieren statt die Gesamtarchitektur zu wechseln. Die rechte Spalte trägt sich, wenn Kanalzahl und Team und Betriebsbudget zusammenkommen -- fehlt eine dieser drei Zeilen, wird der Umbau erfahrungsgemäß teurer als der Nutzen (Projekterfahrung).
Migrationspfad in Etappen statt Big Bang
Wenn die Entscheidung für eine Entkopplung fällt, entscheidet die Reihenfolge über das Risiko. Ein Komplettaustausch der Oberfläche bindet Budget über Monate, ohne dass in dieser Zeit ein einziger Nutzen sichtbar wird. Die etappenweise Strecke dreht das um: Jede Stufe ist für sich abnehmbar, und der Abbruch bleibt an jedem Punkt eine tragbare Option.
- Bestandsaufnahme: Kanäle, Sonderlogiken, Integrationen, Erweiterungen und deren Nutzung -- inklusive der Frage, welche Bordmittel im Frontend gebraucht würden
- Datenverträge festziehen: PIM- und ERP-Strecken stabilisieren, bevor eine zweite Oberfläche darauf zugreift
- Ersten Bereich isolieren: Meist das Kundenportal oder die Schnellerfassung -- hinter dem Login, ohne SEO-Risiko, mit klarem Nutzerkreis
- Messpunkte setzen: Feldwerte, Fehlerquote, Bearbeitungszeit je Bestellung und Supportaufwand vor und nach der Umstellung erfassen
- Zweiten Kanal andocken: Außendienst-Anwendung, Terminal oder Punchout-Strecke auf denselben Diensten -- erst hier zeigt sich der Skaleneffekt
- Öffentliche Flächen zuletzt bewerten: Kategorie- und Produktseiten nur dann entkoppeln, wenn Rendering, Metadaten und Weiterleitungen im eigenen Frontend nachweislich stehen
Diese Reihenfolge hat einen angenehmen Nebeneffekt: Die ersten beiden Etappen zahlen auf jede Architektur ein. Wer sie geht und danach beim Standard-Storefront bleibt, hat kein Geld verbrannt, sondern die Integrationsschicht saniert. Passend dazu lohnt ein Blick auf ohnehin anstehende Pflichten -- etwa die KI-Kennzeichnungspflichten für B2B-Shops, die sich in einem eigenen Frontend genauso wiederfinden müssen wie im Standard-Template.
Zwei Zahlen für die Budgetplanung
Wie ein Architektur-Assessment abläuft
Wir setzen vor solchen Entscheidungen ein kompaktes Assessment auf, weil die Frage "Headless ja oder nein" ohne Zahlen nicht seriös zu beantworten ist. Der Aufwand liegt im Bereich weniger Tage und endet mit einer schriftlichen Empfehlung, die sich auch gegenüber der Geschäftsführung vertreten lässt -- inklusive der Variante, dass der Umbau derzeit nicht empfohlen wird.
- Kanal- und Anforderungsaufnahme mit Zeithorizont, getrennt nach öffentlichen und angemeldeten Bereichen
- Bestandsaufnahme von Erweiterungen, Template-Anpassungen und Integrationen samt tatsächlicher Nutzung
- Bewertung der Datenstrecken aus PIM und ERP inklusive Delta-Fähigkeit und Fehlerbehandlung
- Feldwerte zur aktuellen Performance als Ausgangsbasis statt Laborwerten
- Empfehlung mit Aufwands- und Betriebskostenschätzung für alle drei Wege der Entscheidungsmatrix
- Etappenplan mit Abbruchpunkten, Messgrößen und Verantwortlichkeiten je Stufe
Aus dem Ergebnis wird entweder ein sauber geschnittener Sonderbereich, ein entkoppeltes Frontend mit klarem Betriebsmodell oder die begründete Empfehlung, beim Standard zu bleiben und stattdessen die Integrationsschicht zu stärken. Was wir dabei technisch umsetzen, beschreibt die Leistungsseite zu Headless Commerce mit Shopware; wenn Sie die Ausgangslage konkret einordnen lassen möchten, ist ein Gespräch über Ihr Architekturvorhaben der schnellste Weg zu einer belastbaren Zahl.
Quellen und Studien