Wer die Customer Journey im Automobilgeschäft aufzeichnet, bekommt fast immer dieselbe Folie: Aufmer…
OXID Headless Migration, Schritt für Schritt
Eine OXID-Headless-Migration ist DACH-B2B-Architektur-Arbeit, kein Theme-Update mit Extras. Sie ist ein eigenständiges Projekt mit Phasen, Stakeholdern, Risiken und einem klaren Übergangsplan. Für OXID-Käufer mit B2B-Workflows, deutscher-ERP-Integration und DSGVO-Anforderungen sind die Phasen wichtiger als bei reinen B2C-Plattformen.
Dieser Guide zeigt sechs Phasen, jeweils mit Zielen, typischer Dauer und den häufigsten Stolperfallen.
Phase 0: Vorbereitung, bevor das Projekt offiziell startet
Ziel: Klarheit über Geschäftsziel, Stakeholder, Budget, OXID-Edition.
Typische Dauer: 2 bis 3 Wochen.
In dieser Phase fixieren Sie das „Warum": Marketing-Velocity, B2B-Workflow-Beschleunigung, Modernisierung, Total-Cost-of-Ownership-Reduktion, BFSG-Compliance. Plus die OXID-Edition-Strategie: bleiben Sie bei der aktuellen Edition, oder ist ein Upgrade auf EE für B2B-Funktionen geplant?
Identifizieren Sie drei Schlüssel-Stakeholder: einen OXID-Architekten, einen B2B-Workflow-Owner (typischerweise aus Vertrieb oder Customer Success) und einen Marketing-Owner.
Häufiger Fehler: Migration starten, ohne den OXID-Edition-Kontext zu klären. Wenn B2B-Workflows zentral sind, ist OXID EE die Voraussetzung.
Phase 1: Discovery und Architektur
Ziel: Technische Bestandsaufnahme, Architektur-Entscheidung.
Typische Dauer: 3 bis 5 Wochen.
Inventarisieren Sie Ihren bestehenden OXID-Stack: aktive Module aus dem OXID-Marketplace, B2B-Konfigurationen (Account-Selection, Permission-Sets, kundenspezifische Sortimente), ERP-Anbindung, Drittsysteme, Analytics-Setup.
Treffen Sie die Frontend-Entscheidung: bleiben Sie bei Flow oder Wave, gehen Sie auf Custom Build mit GraphQL StoreFront, oder zu einer FMP wie Laioutr? Diese Frage wird im Detail in OXID Frontend Alternative entschieden.
Häufiger Fehler: OXID-Module mit Frontend-Komponenten werden im Audit unterschätzt. Smarty-Templates aus Modulen müssen in Studio nachgebaut werden, das kostet Sprint-Zeit.
Phase 2: Setup und Integration
Ziel: Frontend-Plattform aufsetzen, OXID-API-Anbindung herstellen.
Typische Dauer: 2 bis 4 Wochen.
Mit Laioutr richten Sie Studio ein, verbinden das OXID GraphQL StoreFront-Modul, konfigurieren Multi-Edition- und B2B-Setups, docken Drittsysteme (Analytics, Marketing-Tools, ERP, PIM) über den App Store an.
Häufiger Fehler: B2B-API-Endpoints (Account-Selection, Permission-Sets) werden zu spät getestet. OXID-EE-B2B-Schemas sind reichhaltig. Frühe API-Tests mit echten Account-Daten sind kritisch.
Phase 3: Komponenten- und Theme-Aufbau
Ziel: Tatsächliche Storefront bauen, inklusive B2B-Workflows.
Typische Dauer: 4 bis 8 Wochen, je nach B2B-Komplexität.
Mit Laioutrs B2B-Komponenten starten Sie nicht bei null. Account-Selection-Frontends, Permission-UIs, kundenspezifische Sortiments-Renderings und Preislisten-Komponenten sind verfügbar. Branding, projektspezifische Workflows und OXID-spezifische Logik bauen Sie darauf auf.
Häufiger Fehler: OXID-Modul-Frontend-Logik wird parallel zur Storefront entwickelt, statt vorgelagert zu integrieren oder durch Laioutr-Komponenten zu ersetzen.
Phase 4: Datenmigration und Inhalts-Transfer
Ziel: Bestehende Inhalte sicher übertragen.
Typische Dauer: 2 bis 3 Wochen.
OXID-CMS-Pages, Content-Snippets aus Modulen, Blog-Posts. Bei Flow- oder Custom-Build-Migration: Inhalte werden in Studio nachgebaut.
Häufiger Fehler: Modul-eingebundene Inhalte werden nicht 1:1 übertragbar sein, manche Komponenten müssen neu gebaut werden.
Phase 5: SEO-Übergang und Redirects
Ziel: Bestehende Rankings retten.
Typische Dauer: 2 Wochen, parallel zu Phase 4.
301-Redirect-Map (besonders wichtig bei OXID-spezifischen URL-Mustern), Hreflang- und Canonical-Tags, Schema.org-Markup neu setzen.
Häufiger Fehler: OXID-spezifische URL-Settings (SEO-URL-Module, Sortiments-URLs) werden in der Redirect-Map vergessen.
Phase 6: Go-live, Monitoring, Iteration
Ziel: Live gehen und sicherstellen, dass nichts kippt.
Typische Dauer: Go-live an einem Werktag, Stabilisierung 2 bis 3 Wochen.
Gehen Sie nicht freitags live. Beobachten Sie in den ersten 72 Stunden besonders: Conversion-Rate (B2C plus B2B getrennt), B2B-Workflow-Completion, Core Web Vitals, OXID-API-Latenzen, Search-Console-Auffälligkeiten.
Häufiger Fehler: B2B-Workflow-Tests werden auf das letzte Sprint-Wochenende verschoben. B2B-Käufer haben weniger Geduld als B2C-Käufer, ein gebrochener Account-Selection-Flow kostet Vertrauen.
Typische Gesamt-Timeline
Für ein OXID-Projekt mit B2B-Workflows, deutscher-ERP-Integration und Multi-Edition-Setup: 10 bis 18 Wochen vom Kickoff bis zum Go-live. Die Timeline reflektiert die DACH-B2B-Komplexität und die OXID-Modul-Landschaft.
Welche Partner Sie unterstützen
Eine Migration auf eigene Faust ist möglich, aber selten der schnellste Weg. In Deutschland haben sich für OXID-Frontend-Projekte mit Laioutr besonders die klassischen OXID-Häuser mit zehn Jahren Plus Erfahrung bewährt. Eine vollständige Liste finden Sie im Bereich Partner.
Fazit: Migration ist DACH-B2B-Architektur-Arbeit
Eine erfolgreiche OXID-Frontend-Migration scheitert selten an der Technologie, meistens an unklaren Edition-Strategie-Entscheidungen, B2B-Workflow-Komplexität-Unterschätzung oder einer SEO-Phase, die zu spät bedacht wird.
Wenn Sie eine konkrete Migration planen, gehen wir mit Ihnen einen Audit durch, ehrlich, mit konkretem Phasenplan und realistischer Timeline.
Weiterführende Ressourcen: Composable Headless Frontend und Content-Management.