There is one decision in almost every commerce replatforming that gets postponed until it is too lat…
OXID Headless Migration Step by Step
An OXID headless migration is DACH B2B architecture work, not a theme update with extras. It is a separate project with phases, stakeholders, risks, and a clear transition plan. For OXID buyers with B2B workflows, German ERP integration, and GDPR requirements, the phases are more important than for pure B2C platforms.
This guide shows six phases, each with goals, typical duration, and the most common pitfalls.
Phase 0: preparation, before the project officially starts
Goal: Clarity on business goal, stakeholders, budget, OXID edition.
Typical duration: 2 to 3 weeks.
In this phase you fix the "why": marketing velocity, B2B workflow acceleration, modernization, total cost of ownership reduction, BFSG compliance. Plus the OXID edition strategy: do you stay on the current edition, or is an upgrade to EE planned for B2B functions?
Identify three key stakeholders: an OXID architect, a B2B workflow owner (typically from sales or customer success), and a marketing owner.
Common mistake: Starting the migration without clarifying the OXID edition context. If B2B workflows are central, OXID EE is the prerequisite.
Phase 1: discovery and architecture
Goal: Technical inventory, architecture decision.
Typical duration: 3 to 5 weeks.
Inventory your existing OXID stack: active modules from the OXID Marketplace, B2B configurations (account selection, permission sets, customer-specific catalogs), ERP connection, third-party systems, analytics setup.
Make the frontend decision: stay with Flow or Wave, go to custom build with GraphQL StoreFront, or to an FMP like Laioutr? This question is decided in detail in OXID frontend alternative.
Common mistake: OXID modules with frontend components are underestimated in the audit. Smarty templates from modules must be rebuilt in Studio, that costs sprint time.
Phase 2: setup and integration
Goal: Set up frontend platform, establish OXID API connection.
Typical duration: 2 to 4 weeks.
With Laioutr, you set up Studio, connect the OXID GraphQL StoreFront module, configure multi-edition and B2B setups, dock third-party systems (analytics, marketing tools, ERP, PIM) via the App Store.
Common mistake: B2B API endpoints (account selection, permission sets) are tested too late. OXID EE B2B schemas are rich. Early API tests with real account data are critical.
Phase 3: component and theme build
Goal: Build the actual storefront, including B2B workflows.
Typical duration: 4 to 8 weeks, depending on B2B complexity.
With Laioutr's B2B components, you do not start from zero. Account selection frontends, permission UIs, customer-specific catalog renderings, and price list components are available. Branding, project-specific workflows, and OXID-specific logic you build on top.
Common mistake: OXID module frontend logic is developed in parallel to the storefront, instead of integrated upstream or replaced by Laioutr components.
Phase 4: data migration and content transfer
Goal: Transfer existing content safely.
Typical duration: 2 to 3 weeks.
OXID CMS pages, content snippets from modules, blog posts. For Flow or custom-build migration: content is rebuilt in Studio.
Common mistake: Module-embedded content will not be 1:1 transferable, some components must be rebuilt.
Phase 5: SEO transition and redirects
Goal: Save existing rankings.
Typical duration: 2 weeks, parallel to Phase 4.
301 redirect map (especially important with OXID-specific URL patterns), hreflang and canonical tags, reset Schema.org markup.
Common mistake: OXID-specific URL settings (SEO URL modules, catalog URLs) are forgotten in the redirect map.
Phase 6: go-live, monitoring, iteration
Goal: Go live and ensure nothing tips over.
Typical duration: Go-live on a weekday, stabilization 2 to 3 weeks.
Do not go live on Fridays. Watch in the first 72 hours especially: conversion rate (B2C and B2B separately), B2B workflow completion, Core Web Vitals, OXID API latencies, Search Console anomalies.
Common mistake: B2B workflow tests are pushed to the last sprint weekend. B2B buyers have less patience than B2C buyers, a broken account selection flow costs trust.
Typical overall timeline
For an OXID project with B2B workflows, German ERP integration, and multi-edition setup: 10 to 18 weeks from kickoff to go-live. The timeline reflects the DACH B2B complexity and the OXID module landscape.
Which partners can support you
A migration on your own is possible, but rarely the fastest path. In Germany, particularly proven for OXID frontend projects with Laioutr: the classic OXID houses with ten years plus experience. A complete list is in the Partners area.
Conclusion: migration is DACH B2B architecture work
A successful OXID frontend migration rarely fails on technology, mostly on unclear edition strategy decisions, B2B workflow complexity underestimation, or an SEO phase considered too late.
If you are planning a concrete migration, we walk through an audit with you, honestly, with a concrete phase plan and realistic timeline.