Contentful-Onboarding: Wiederauffindbarkeit sichern, aus Frontend-SichtBeim Contentful-Onboarding en…
Warum B2B-Magento-Händler schneller aus dem Default-Theme herauswachsen als B2C
Warum B2B-Magento-Händler schneller aus dem Default-Theme herauswachsen als B2C
Wenn Dein Magento-Shop B2B-Kunden bedient, stößt Dein Default-Theme früher an Grenzen als bei einem reinen B2C-Shop. Nicht weil Dein Team schlechter arbeitet, sondern weil die Anforderungen strukturell anders sind: Konfiguratoren, Staffelpreise, kontospezifische Kataloge und mehrstufige Bestellstrecken sind Frontend-Last. Luma und Hyva sind für gleichförmige B2C-Storefronts gebaut, nicht für B2B-Komplexität pro Kunde.
Was heißt "aus dem Theme herauswachsen" konkret?
Bei B2C sieht das Theme für die große Mehrheit der Kunden gleich aus: Produktliste, Produktdetailseite, Warenkorb, Checkout. Bei B2B verändert sich diese Grundstruktur pro Kunde. Ein Kunde sieht eigene Preislisten, ein anderer einen eigenen Produktkatalog, ein dritter braucht Punchout-Anbindung an sein Procurement-System, ein vierter eine mehrstufige Freigabestrecke, bevor eine Bestellung überhaupt ausgelöst wird. Jede dieser Anforderungen bricht die Standard-Theme-Logik von Luma oder Hyva, weil beide Themes für eine einheitliche Storefront gebaut sind, nicht für kontospezifische Varianten.
Das Ergebnis kennst Du vermutlich: Dein Team forkt das Theme. Erst ein kleiner Custom-Block für Staffelpreise, dann ein eigenes Template für den Konfigurator, dann ein Sonderweg für Punchout, dann eine Extra-Logik für die Freigabestrecke bei Bestellungen über einem bestimmten Wert. Nach zwei Jahren hat kein Entwickler mehr den vollständigen Überblick, welcher Custom-Code wo greift, und jeder Magento-Patch wird zum Risiko-Test statt zur Routine.
Bei B2C-Shops passiert dieser Prozess auch, aber deutlich langsamer, weil die Storefront-Anforderungen sich über Kunden hinweg kaum unterscheiden. Bei B2B ist jeder größere Account potenziell ein eigener Sonderfall, und genau das treibt das Theme schneller in die Fork-Spirale.
Das Problem: B2B-Anforderungen sind Frontend-Last, nicht Backend-Last
Magentos Backend-Logik, also Preisregeln, Kataloge und Kundengruppen, ist im Kern B2B-tauglich. Die Open-Source-Edition hat zwar keine native B2B-Suite (Account-Hierarchien und ein vollständiger Quotation-Flow bleiben Adobe Commerce vorbehalten), aber die Datenmodelle für Staffelpreise und Kundengruppen existieren bereits. Was fehlt, ist die Fähigkeit, diese Daten im Frontend flexibel darzustellen, ohne das Theme bei jeder neuen Anforderung erneut zu forken.
Genau hier verschätzen sich viele Teams: Sie behandeln ein Frontend-Problem als Backend-Problem und starten ein Magento-Upgrade-Projekt oder eine Adobe-Commerce-Migration, wenn eigentlich die Präsentationsschicht das eigentliche Problem ist. Wer prüfen möchte, ob genau das bei ihm der Fall ist, findet in unserem Readiness-Check für Magento-Decoupling eine strukturierte erste Einschätzung.
Konfiguratoren sind ein gutes Beispiel für diese Frontend-Last. Eine B2C-Produktdetailseite zeigt Bild, Preis und Warenkorb-Button. Ein B2B-Konfigurator für ein Maschinenbau-Sortiment braucht dagegen bedingte Logik (Option A schließt Option B aus), Staffelpreis-Berechnung live im Browser und oft eine Angebotserstellung statt Direktkauf. Luma kann das technisch abbilden, aber jede Iteration bedeutet PHTML-Template-Arbeit und JavaScript-Patches, die beim nächsten Magento-Update erneut getestet werden müssen. Bei Hyva ist die Ausgangslage moderner, aber das Grundproblem bleibt: Jede B2B-Sonderlogik landet im Theme, nicht in einer wiederverwendbaren Komponente.
Wie Du das löst: Frontend vom Backend entkoppeln, statt das Theme weiter zu forken
Der pragmatischste Weg ist nicht, noch tiefer in Hyva zu investieren oder auf PWA Studio zu wechseln, sondern die Experience-Schicht als eigenständigen Layer zu behandeln, der gegen die Magento-GraphQL-API spricht. Mit Laioutr setzt Du diesen Layer auf, ohne Magento als Backend zu ersetzen.
Konkret heißt das: Konfiguratoren, Staffelpreis-Anzeigen und kontospezifische Kataloge werden zu Komponenten in einer zentralen UI-Library, nicht zu Theme-Forks. Ändert sich die Logik für einen Kunden, änderst Du die Komponente, nicht das ganze Theme. Magento bleibt die Commerce-Engine für Preisregeln, Kataloge und Bestellabwicklung, das Frontend wird zum austauschbaren, wartbaren Teil, unabhängig davon, ob Du in Zukunft bei Magento bleibst oder zu Adobe Commerce migrierst.
Für B2B-Merchants, die schon selbstbedienbare Bestellstrecken für Wiederkäufer, Kontoverwalter oder Filial-Einkäufer bauen wollen, lohnt sich ein Blick in unsere Muster für B2B-Self-Service-Frontends, die genau diese Account-spezifischen Bestellstrecken beschreiben.
Für Entwickler: Laioutr koppelt sich über Standard-Connectoren an die Magento-GraphQL-API, ohne Custom-Glue-Code. Dein Team behält die Backend-Logik, Preisregeln und Kundengruppen unverändert. Der Frontend-Layer läuft unabhängig vom Theme-Renderer, sodass ein Magento-Patch nicht automatisch einen Frontend-Regressionstest nach sich zieht. Extension-Kompatibilität, ein typischer Schmerzpunkt bei 30 bis 80 Extensions pro Shop, wird auf den API-Vertrag reduziert statt auf das Theme-Rendering.
Was Du gewinnst
- Dimension | Theme-Fork-Ansatz | Entkoppeltes Frontend
- Zeit pro neuem B2B-Feature | Wochen (PHTML- und JS-Patch plus Test) | Tage (Komponenten-Anpassung)
- Wartungsaufwand | Steigt mit jedem Custom-Block | Zentral in einer UI-Library
- Patch-Risiko | Jeder Magento-Patch triggert Frontend-Retest | Frontend entkoppelt vom Theme-Renderer
- Skalierung über Konten | Neue Sonderfälle bedeuten neue Templates | Neue Konten bedeuten neue Komponenten-Konfiguration
FAQ
Muss ich für B2B-Frontend-Anforderungen auf Adobe Commerce wechseln? Nein. Die Frontend-Komplexität lässt sich unabhängig von der Backend-Edition lösen. Wenn Dir tatsächlich Account-Hierarchien oder ein vollständiger Quotation-Flow fehlen, ist das ein separates Backend-Thema, kein Grund, das Frontend nicht schon jetzt zu entkoppeln.
Wie lange dauert die Umstellung? Migrationen mit Founder-Begleitung sind bei einem Single-Store-Shop üblicherweise in wenigen Wochen erledigt. Bei Multi-Konto- oder Multi-Brand-Setups skaliert der Aufwand linear mit der Anzahl der Varianten, nicht mit der Theme-Komplexität.
Was kostet das im Vergleich zu einer Hyva-Migration? Details zu unserem Preismodell findest Du unter laioutr.com/pricing. Zum Vergleich: Eine Hyva-Migration allein dauert typischerweise sechs Wochen bis acht Monate, abhängig vom Custom-Modul-Stack, bevor überhaupt neue B2B-Features gebaut werden können.
Was passiert mit meinen bestehenden B2B-Extensions? Extensions, die reine Backend-Logik abbilden (Preisregeln, Genehmigungs-Workflows), bleiben unverändert. Extensions, die Frontend-Rendering übernehmen, werden schrittweise durch Komponenten in der UI-Library ersetzt, in der Reihenfolge, die für Dein Team am meisten Wartungsaufwand spart.
Nächste Schritte
Wenn Dein Magento-Team gerade darüber diskutiert, ob der nächste Schritt eine Hyva-Migration, ein PWA-Studio-Aufbau oder ein vollständiges Replatforming ist: Buche ein 30-Minuten-Gespräch und lass uns gemeinsam durchgehen, wo genau Deine Frontend-Last liegt und ob sich das ohne Backend-Wechsel lösen lässt.
Über den Autor: Marcel Thiesies, Co-Founder von Laioutr, begleitet B2B-Magento-Merchants dabei, ihr Frontend unabhängig vom Backend zu modernisieren.