OXID eSales für B2B-Großhändler: Modernes Frontend ohne Backend-Wechsel

B2B-Großhändler auf OXID eSales können ihre Frontend-Ebene modernisieren, Staffelpreise, Angebotsanfragen und Self-Service-Portale einbauen, ohne dafür auf das OXID-6-zu-7-Upgrade zu warten oder es davon abhängig zu machen. Die Frontend-Modernisierung und die Backend-Upgrade-Entscheidung sind zwei getrennte Projekte, die sich nicht gegenseitig blockieren müssen.

Was heißt Frontend-Modernisierung für OXID-B2B-Händler konkret?

OXID eSales hat eine starke Kundenbasis im DACH-B2B- und Großhandelsbereich - Maschinenbau-Zulieferer, Fachhändler, Distributoren mit mehrstufigen Kundenhierarchien. Diese Händler haben andere Frontend-Anforderungen als klassische B2C-Shops: Kundinnen und Kunden loggen sich mit einem Firmenaccount ein, sehen individuell verhandelte Preise, bestellen in Bulk-Mengen, fragen Sonderkonditionen per Angebotsanfrage an und verwalten mehrere Nutzerinnen und Nutzer pro Firmenaccount selbst. Das klassische OXID-Standard-Theme ist für diese Use-Cases nicht gebaut, und die meisten B2B-Händler haben ihre Self-Service-Logik über die Jahre als Custom-Erweiterung direkt in den OXID-Frontend-Code gebaut.

Frontend-Modernisierung bedeutet hier: eine composable Frontend-Ebene oben auf dem bestehenden OXID-Backend, die genau diese B2B-Muster - Staffelpreise, RFQ-Flows, Self-Service-Portale - als konfigurierbare Komponenten abbildet, statt als gewachsenen Custom-Code.

Das Problem, das viele OXID-B2B-Händler aktuell haben

Die meisten OXID-B2B-Setups haben ihre Self-Service-Funktionen über mehrere Jahre inkrementell ausgebaut. Das Ergebnis: ein Frontend, das funktioniert, aber schwer zu iterieren ist. Eine neue Staffelpreis-Logik für ein neues Kundensegment braucht Wochen, weil die Preislogik tief im Theme-Code verwoben ist. Ein neues Self-Service-Feature - zum Beispiel Wiederbestellung aus der Bestellhistorie mit einem Klick - wird zum mehrmonatigen Projekt, weil das Frontend nicht für schnelle Iteration gebaut wurde.

Gleichzeitig steht vielen dieser Händler die OXID-6-zu-7-Migration bevor. Das führt zu einem häufigen Fehlschluss: Weil das Backend-Upgrade ohnehin ansteht, wird die Frontend-Modernisierung auf "danach" verschoben - manchmal auf Jahre. In der Zwischenzeit bleiben Kernfunktionen für B2B-Wiederkäufer unverändert: keine modernen Self-Service-Portale, keine schnellen RFQ-Flows, keine mobil-optimierte Bestellwiederholung. Das kostet direkt Umsatz, weil Einkäuferinnen und Einkäufer im Großhandel zunehmend dieselbe Self-Service-Erfahrung erwarten, die sie aus B2C-Kontexten kennen.

Wichtig: Diese Frontend-Modernisierung ist ein anderes Thema als der EOL-Kalender des OXID-6-Supports (dazu haben wir bereits eine eigene Analyse zu den Frontend-Implikationen des OXID-6-End-of-Life veröffentlicht) und auch getrennt von der reinen technischen Migrations-Schritt-für-Schritt-Frage (siehe OXID Headless Migration Schritt für Schritt). Hier geht es konkret um den B2B-Wiederverkäufer-Use-Case: Was ändert sich für Einkäuferinnen und Einkäufer, die täglich im Portal bestellen.

Wie Laioutr das für OXID-B2B-Händler löst

Der Kern-Hook: Frontend-Modernisierung von der OXID-6-zu-7-Backend-Upgrade-Entscheidung entkoppeln. Laioutr setzt sich als Frontend-Ebene über das bestehende OXID-Backend, egal ob Version 6 oder 7, und verbindet sich über den Unified Data Layer (Orchestr) mit den OXID-Daten - Produkte, Preise, Kundenhierarchien, Bestellhistorie.

Für den B2B-Großhandel-Use-Case heißt das konkret:

• Staffelpreise als konfigurierbare Komponente: Mengenrabatte und kundenspezifische Preislisten werden im Frontend als eigenständige, wiederverwendbare Bausteine abgebildet statt als Custom-Theme-Logik, die bei jeder Preisstruktur-Änderung neu angefasst werden muss.
• RFQ-Flows (Angebotsanfrage): Ein Self-Service-Anfrage-Flow für Sonderkonditionen oder große Bestellmengen, der direkt in den Bestellprozess integriert ist, statt als separates Kontaktformular außerhalb der Storefront.
• Self-Service-Portale: Firmenaccounts mit mehreren Nutzerinnen und Nutzern, eigenen Freigabe-Workflows und Bestellhistorie-Wiederbestellung - als Frontend-Komponenten, die sich in Tagen statt Monaten anpassen lassen.

Das Backend bleibt dabei unverändert - Laioutr ersetzt keine OXID-Funktion, sondern liegt als eigenständige, steuerbare Ebene darüber. Das ist dieselbe Decoupling-Logik, die wir grundsätzlich für OXID vertreten: Frontend jetzt modernisieren, das Backend-Upgrade separat und zu einem selbst gewählten Zeitpunkt angehen. Mehr zur technischen Basis auf unserer Composable Headless Frontend-Plattformseite und speziell für OXID auf der OXID-Backend-Seite.

Was Du gewinnst

• Dimension: Zeit / OXID-Standard-Theme (B2B-Custom-Code): Wochen bis Monate pro neuer Self-Service-Funktion / Mit Laioutr-Frontend-Ebene: Tage, Marketing- und Produktteam passt Komponenten selbst an
• Dimension: Geld / OXID-Standard-Theme (B2B-Custom-Code): Custom-Entwicklung pro Preisregel-Änderung / Mit Laioutr-Frontend-Ebene: Konfiguration statt Neuentwicklung, OXID-Backend-Investment bleibt erhalten
• Dimension: Qualität / OXID-Standard-Theme (B2B-Custom-Code): RFQ- und Self-Service-Flows oft als Insel-Lösungen / Mit Laioutr-Frontend-Ebene: Ein durchgängiger, mobil-optimierter B2B-Bestellprozess

Für den B2B-Kontext speziell lohnt sich auch ein Blick auf unser Growth Kit B2B, das genau diese Portal-, Preis- und RFQ-Muster als vorkonfiguriertes Set bereitstellt.

FAQ

Müssen wir zuerst auf OXID 7 upgraden, bevor wir das Frontend modernisieren? Nein. Die Frontend-Ebene verbindet sich über Orchestr sowohl mit OXID 6 als auch mit OXID 7. Ihr könnt die Frontend-Modernisierung jetzt starten und das Backend-Upgrade unabhängig davon terminieren.

Wie lange dauert die Umsetzung eines B2B-Self-Service-Portals? Typisch 2-3 Wochen für die Kernkomponenten (Login, Preislisten, Bestellhistorie), abhängig davon, wie viele individuelle Preislogiken bereits im Bestand existieren.

Können wir bestehende Kundenhierarchien und Freigabe-Workflows übernehmen? Ja. Diese Daten liegen im OXID-Backend und werden über Orchestr in die neuen Frontend-Komponenten übernommen, keine Datenmigration notwendig.

Nächste Schritte

Wenn Euer OXID-B2B-Portal aktuell mehr Wartungsaufwand als Wachstum produziert: Bucht einen OXID-B2B-Frontend-Check und wir zeigen konkret, wie sich Staffelpreise, RFQ-Flows und Self-Service-Portale in Eurem bestehenden OXID-Setup modernisieren lassen.

Weitere Themen aus der Laioutr-Plattform

• Composable Headless Frontend
• Headless Frontend für OXID
• Growth Kit B2B

Über den Autor: Marcel Thiesies ist Co-Founder & CEO von Laioutr. Er arbeitet regelmäßig mit OXID-Händlern an der Frage, wie sich Frontend-Modernisierung und Backend-Upgrade-Entscheidungen sauber trennen lassen.