There is one decision in almost every commerce replatforming that gets postponed until it is too lat…
OXID Headless: When Is the Switch Worth It?
OXID eShop is the established German B2B platform for DACH mid-market: account selection, permission sets, customer-specific catalogs, VAT workflows, German ERP integration. All of this in the backend. But the frontend is mostly Flow Theme or Wave, both Smarty-based. Headless with OXID GraphQL StoreFront is the strategic question.
Anyone who started their OXID frontend stack two or three years ago with Flow often sees symptoms today that argue for a switch. Anyone running a custom build with Next.js and OXID GraphQL StoreFront notices after six to nine months of build that maintenance is just the beginning.
This guide helps you make the decision cleanly.
What does "OXID headless" mean?
OXID headless decouples the frontend, everything your buyers see, from the OXID backend with products, account selection, permission sets, and order processes. Instead of Flow or Wave, the frontend connects through the OXID GraphQL StoreFront module. A complete overview of the options is on our hub page on Headless for OXID.
Five symptoms that argue for a switch
1. Flow Theme looks dated, conversion rate falls
You've been running Flow Theme for years. It works, but looks like 2018. Mobile performance is mediocre, A/B tests bring little because the theme architecture slows down iterations. The marketing wishlist "a modern storefront" has been on the table for two years.
With an FMP that ships modern themes and components, that becomes a weeks job.
2. Marketing can't iterate independently
Every new landing page, every microsite, every seasonal campaign is a Smarty template edit that runs through engineering. Marketing iterations need sprints, A/B tests are realistically only monthly.
With a visual builder, marketing iterates independently, without an engineering sprint per page.
3. B2B workflows bind engineering sprints
You use OXID EE B2B: account selection, permission sets, customer-specific catalogs. But every new workflow (permission UI, catalog configurator, approval flow) is a Smarty template edit or a custom-build sprint in the Next.js stack.
With an FMP that ships B2B components as standard, this accelerates significantly.
4. Performance numbers are no longer competitive
B2B buyers today expect B2C performance. If your OXID frontend hangs at Lighthouse 50 to 70 despite caching and CDN, you lose conversions. Custom build can reach Lighthouse 100, but only with dedicated performance engineering.
Component-based FMPs with a Lighthouse 100 target value break through this structurally.
5. Custom-build maintenance gets too expensive
You have a custom build with Next.js and OXID GraphQL StoreFront, perhaps set up two years ago. It works, but: the frontend team needs two or three people, OXID API changes force adjustments, every new page is an engineering ticket.
With an FMP, maintenance is bundled, updates run via the platform, marketing becomes independent.
When a switch is (still) not worth it
Three constellations where we actively advise against switching:
You just freshly set up Flow or Wave. If you set up a new theme six months ago and it works, headless is the next iteration, not the immediate one.
You are mid OXID edition switch. Backend migration and frontend migration in parallel is double risk.
No architect on staff. An FMP migration without a technical owner rarely goes well.
Three rules of thumb for the decision
- Flow Theme older than 3 years and conversion rate dropping? Clear signal toward an FMP.
- Marketing wishlist "modern storefront" older than 6 months? Clear signal toward an FMP.
- Custom-build maintenance binds two or more engineers permanently? Clear signal toward an FMP.
If two of these three apply, the question is no longer "if" but "how".
What a frontend switch concretely changes
From the OXID projects we have supported, three effects emerge:
Marketing velocity rises significantly because marketing iterates independently in Studio.
B2B time to feature drops significantly because standard B2B workflows are available as components.
Operational costs drop because hosting, component maintenance, and compliance audits are included in the FMP license.
Pragmatic entry point
A complete migration in one step is rarely the right path. What works: start with a single storefront, for example for a new brand or a new market. The complete migration path is described in the post OXID headless migration, step by step.
Conclusion: frontend strategy is an architecture decision
Anyone with more than two hits on the symptom list should seriously consider the switch. Anyone with zero or one hit who runs Flow Theme stably is often better served by the existing architecture.
If you are unsure, we are happy to walk through it with you. We show Laioutr live on your OXID setup and tell you honestly whether a switch makes sense for you.