OXID eSales for B2B Wholesalers: A Modern Frontend, No Backend Swap
B2B wholesalers running on OXID eSales can modernize their frontend layer, add tiered pricing, RFQ flows, and self-service portals, without waiting on the OXID 6-to-7 upgrade or making frontend work depend on it. Frontend modernization and the backend upgrade decision are two separate projects that do not need to block each other.
What Does Frontend Modernization Mean for OXID B2B Merchants?
OXID eSales has a strong customer base in DACH B2B and wholesale, machinery suppliers, specialist dealers, distributors with multi-tier customer hierarchies. These merchants have different frontend requirements than classic B2C shops: buyers log in with a company account, see individually negotiated prices, order in bulk quantities, request special terms through an RFQ, and manage multiple users per company account themselves. The standard OXID theme is not built for these use cases, and most B2B merchants have built their self-service logic as custom extensions directly inside the OXID frontend code over the years.
Frontend modernization here means: a composable frontend layer sitting on top of the existing OXID backend that maps exactly these B2B patterns, tiered pricing, RFQ flows, self-service portals, as configurable components instead of grown custom code.
The Problem Many OXID B2B Merchants Have Right Now
Most OXID B2B setups have built out their self-service functionality incrementally over several years. The result: a frontend that works but is hard to iterate on. A new tiered-pricing rule for a new customer segment takes weeks because the pricing logic is woven deep into the theme code. A new self-service feature, one-click reordering from order history, for example, turns into a multi-month project because the frontend was never built for fast iteration.
At the same time, many of these merchants have the OXID 6-to-7 migration ahead of them. That leads to a common misstep: because the backend upgrade is coming anyway, frontend modernization gets pushed to "after that", sometimes for years. In the meantime, core functionality for B2B repeat buyers stays frozen: no modern self-service portals, no fast RFQ flows, no mobile-optimized reorder flow. That costs revenue directly, because wholesale buyers increasingly expect the same self-service experience they know from B2C contexts.
Important distinction: this frontend modernization angle is separate from the OXID 6 end-of-life calendar (we already published a dedicated analysis of the frontend implications of OXID 6 end-of-life) and separate from the pure step-by-step migration mechanics (see OXID Headless Migration Step by Step). This is specifically about the B2B reseller use case: what actually changes for buyers who order in the portal every day.
How Laioutr Solves This for OXID B2B Merchants
The core hook: decouple frontend modernization from the OXID 6-to-7 backend upgrade decision. Laioutr sits as a frontend layer on top of the existing OXID backend, whether version 6 or 7, and connects through the unified data layer (Orchestr) to the OXID data, products, prices, customer hierarchies, order history.
For the B2B wholesale use case, that means concretely:
- Tiered pricing as a configurable component: volume discounts and customer-specific price lists become standalone, reusable building blocks in the frontend instead of custom theme logic that needs rework every time the pricing structure changes.
- RFQ flows: a self-service request flow for special terms or large order quantities, integrated directly into the ordering process instead of living as a separate contact form outside the storefront.
- Self-service portals: company accounts with multiple users, their own approval workflows, and one-click reorder from order history, built as frontend components that can be adjusted in days instead of months.
The backend stays untouched. Laioutr does not replace any OXID functionality, it sits as an independent, controllable layer on top. That is the same decoupling logic we advocate for OXID generally: modernize the frontend now, handle the backend upgrade separately and on your own timeline. More on the technical foundation on our Composable Headless Frontend platform page, and specifically for OXID on the OXID backend page.
What You Gain
- Dimension: Time / OXID standard theme (B2B custom code): Weeks to months per new self-service feature / With the Laioutr frontend layer: Days, marketing and product teams adjust components directly
- Dimension: Money / OXID standard theme (B2B custom code): Custom development for every pricing rule change / With the Laioutr frontend layer: Configuration instead of new development, OXID backend investment stays intact
- Dimension: Quality / OXID standard theme (B2B custom code): RFQ and self-service flows often built as isolated one-offs / With the Laioutr frontend layer: One consistent, mobile-optimized B2B order flow
For the B2B context specifically, it is worth checking our Growth Kit B2B, which packages exactly these portal, pricing, and RFQ patterns as a pre-configured set.
FAQ
Do we need to upgrade to OXID 7 first before modernizing the frontend? No. The frontend layer connects through Orchestr to both OXID 6 and OXID 7. You can start frontend modernization now and schedule the backend upgrade independently.
How long does implementing a B2B self-service portal take? Typically 2-3 weeks for the core components (login, price lists, order history), depending on how many individual pricing rules already exist in your setup.
Can we carry over existing customer hierarchies and approval workflows? Yes. That data lives in the OXID backend and is pulled into the new frontend components through Orchestr, no data migration required.
Next Steps
If your OXID B2B portal is producing more maintenance work than growth right now, book an OXID B2B frontend check and we will show you concretely how tiered pricing, RFQ flows, and self-service portals can be modernized inside your existing OXID setup.
More From the Laioutr Platform
About the author: Marcel Thiesies is Co-Founder & CEO at Laioutr. He regularly works with OXID merchants on how to cleanly separate frontend modernization from backend upgrade decisions.