OXID Migration & Upgrade: Der vollständige Leitfaden für den Wechsel auf OXID eShop 7

Warum eine OXID Migration jetzt notwendig ist

OXID eShop gehört seit Jahren zu den führenden E-Commerce-Plattformen im deutschsprachigen Raum — besonders im B2B-Segment. Doch viele Unternehmen betreiben ihren Shop noch auf veralteten Versionen: OXID 4.x (End of Life seit 2020) oder OXID 6.x (Sicherheits-Support ausgelaufen). Das ist nicht nur ein technisches Risiko, sondern ein ernsthaftes Geschäftsrisiko.

Mit der Einführung von OXID eShop 7 hat OXID esales den Plattformkern grundlegend modernisiert: PHP 8.2+, Composer-basiertes Deployment, GraphQL-API, überarbeitetes Modul-System und eine deutlich verbesserte Performance. Wer noch auf Version 4 oder 6 setzt, verpasst nicht nur neue Features — er betreibt einen Shop ohne aktive Sicherheits-Patches.

In diesem Leitfaden erfahren Sie alles, was Sie für eine erfolgreiche OXID-Migration wissen müssen: technische Grundlagen, typische Herausforderungen, Kosten, Zeitplanung und wie Sie den Wechsel ohne Umsatzverlust durchführen.

OXID 4.x, 6.x und 7 im Vergleich — was hat sich geändert?

Bevor wir in den Migrationsprozess einsteigen, lohnt ein Blick auf die wesentlichen Unterschiede zwischen den Versionen:

OXID eShop 4.x (End of Life)

Version 4 war über viele Jahre das Rückgrat vieler mittelständischer Shops. Doch die Architektur stammt aus einer anderen Ära: kein Composer-Support, keine modernen PHP-Standards, kein PSR-konformes Coding. Wer heute noch auf 4.x läuft, hat keinen Zugang zu Sicherheits-Updates und ist mit veralteter PHP-Infrastruktur unterwegs. Eine Migration ist hier dringend — nicht optional.

OXID eShop 6.x

Version 6 brachte bereits Composer-Integration und eine Modernisierung der Modul-Struktur. Viele Unternehmen sind hier noch aktiv. Allerdings: Der offizielle Sicherheits-Support ist ausgelaufen, neue Features werden ausschließlich für Version 7 entwickelt. Composer-basierte Module aus OXID 6 sind oft kompatibel mit OXID 7, erfordern aber eine Überprüfung und teils Anpassungen.

OXID eShop 7 — die aktuelle Version

OXID 7 ist ein vollständiger Neustart auf modernem Fundament:

• PHP 8.2+ Pflicht: Volle Unterstützung moderner PHP-Features wie Fibers, Enums, Named Arguments und Intersection Types.
• Composer-first: Alle Module und die OXID-Core-Dateien werden über Composer verwaltet — saubere, versionierte Deployments.
• GraphQL API: Native GraphQL-Unterstützung für Headless-Szenarien und Mobile-Apps.
• Überarbeitetes Theme-System: Twig als Template-Engine ersetzt Smarty schrittweise; sauberere Trennung von Logik und Darstellung.
• Verbessertes B2B-Modul: Erweiterte Kundengruppen-Logik, Freigabeworkflows und Netto-Preisdarstellung direkt im Core.
• Doctrine DBAL: Datenbankabstraktion statt Raw-SQL — sicherer und wartbarer.

Wann ist der richtige Zeitpunkt für eine OXID Migration?

Die ehrliche Antwort: Sofort, wenn Sie noch auf 4.x sind. Zeitnah, wenn Sie auf 6.x sind. Aber es gibt konkrete Trigger, die eine Migration besonders dringlich machen:

• Ihr Hosting-Provider stellt die PHP-Version ein, die Ihr OXID 4.x oder 6.x benötigt.
• Sie haben eine bekannte Sicherheitslücke im System, für die es keinen offiziellen Patch mehr gibt.
• Sie planen eine ERP-Integration oder neue Zahlungsmethoden, die auf OXID 7 APIs angewiesen sind.
• Ihr Performance-Audit zeigt Ladezeiten über 3 Sekunden — oft ein Symptom veralteter Architektur.
• Ihre Entwickler brauchen immer mehr Zeit für Workarounds, weil das System nicht mehr wartbar ist.
• Sie möchten neue B2B-Features nutzen, die nur in OXID 7 verfügbar sind.

Warten Sie nicht auf den nächsten Sicherheitsvorfall. Planen Sie die Migration proaktiv — dann haben Sie Zeit und Budget, es richtig zu machen.

Die 6 Phasen einer professionellen OXID Migration

Phase 1: Bestands-Audit und Kompatibilitätsanalyse

Der erste Schritt jeder Migration ist ein vollständiger Audit des bestehenden Systems. Dabei prüfen wir:

• Modul-Inventar: Welche Module sind installiert? Welche sind Community-Module, welche Eigenentwicklungen? Gibt es für jeden ein OXID-7-kompatibles Äquivalent?
• Theme-Analyse: Ist das Theme auf Smarty basiert? Wie stark ist es individualisiert? Gibt es einen direkten Migrationspfad?
• Datenbankstruktur: Welche Tabellen wurden durch Module oder Custom-Code erweitert? Gibt es inkonsistente Daten, die vor der Migration bereinigt werden müssen?
• Abhängigkeiten: Welche externen Systeme (ERP, PIM, Payment-Provider) sind angebunden? Sind deren Schnittstellen OXID-7-kompatibel?
• PHP-Version und Server: Welche PHP-Version läuft aktuell? Welche Extensions werden benötigt?

Aus diesem Audit entsteht eine klare Aufwandsschätzung und eine Risikobewertung. Ohne diesen Schritt ist jede Kostenaussage Spekulation.

Phase 2: Projektplanung und Staging-Setup

Auf Basis des Audits entsteht der Projektplan: welche Module werden migriert, welche neu entwickelt, welche gestrichen. Gleichzeitig richten wir eine Staging-Umgebung mit OXID 7 ein — identische Konfiguration wie die spätere Produktion, aber isoliert vom Live-Shop.

Wichtig: Der Live-Shop läuft während der gesamten Migration weiter. Kunden merken nichts, Bestellungen gehen weiter ein. Erst am Go-live-Tag wird umgeschaltet — mit vorher getesteter Datenmigration.

Phase 3: Theme- und Frontend-Migration

Das Theme ist oft der aufwändigste Teil. OXID 4.x-Themes basieren auf Smarty und einer komplett anderen Template-Struktur als OXID 7. Eine 1:1-Übertragung ist nicht möglich — in der Regel empfehlen wir einen Theme-Neuaufbau auf Basis des OXID 7 Apex-Themes, das als saubere Grundlage dient.

Dabei nutzen wir die Gelegenheit, das Frontend zu modernisieren: bessere Mobile-Optimierung, schnellere Ladezeiten (Core Web Vitals), und ein cleanes Design-System. Die Migration wird so zur Investition in die Zukunft — nicht nur ein technischer Pflichtschritt.

Phase 4: Modul-Migration und Neuentwicklung

Jedes Modul wird einzeln bewertet:

• Direkt kompatibel: Viele OXID-6-Module mit Composer-Support laufen nach einem Update in OXID 7.
• Anpassung nötig: Das Modul-Interface hat sich in OXID 7 geändert — bestehende Module müssen refactored werden.
• Neuaufbau: OXID-4-Module ohne Composer-Integration müssen vollständig neu entwickelt werden.
• Community-Ersatz: Für viele Standard-Module gibt es OXID-7-kompatible Alternativen aus dem OXID-Ökosystem.

Custom-Module für individuelle Preislogiken, Freigabeworkflows oder ERP-Anbindungen müssen in der Regel neu entwickelt werden — nach OXID-7-Standards mit Composer-Packaging, PSR-12-konformem Code und automatisierten Tests.

Phase 5: Datenmigration

Die Datenmigration ist technisch anspruchsvoll — und der Schritt, bei dem die meisten selbst durchgeführten Migrationen scheitern. Folgende Datenbereiche müssen übertragen werden:

• Produktkatalog (Artikel, Kategorien, Varianten, Attribute, Bilder)
• Kundendaten und Adressen (DSGVO-konform)
• Bestellhistorie und Bestellpositionen
• Preise, Staffelpreise und Kundengruppen-Konditionen
• Content-Seiten (CMS-Blöcke, statische Seiten)
• SEO-URLs und URL-Weiterleitungen (301-Redirects)
• Newsletter-Abonnenten

Besonderes Augenmerk auf SEO-URLs: Wenn sich die URL-Struktur ändert, müssen alle alten URLs mit 301-Weiterleitungen auf die neuen URLs umgeleitet werden. Andernfalls verlieren Sie hart erkämpfte Google-Rankings über Nacht. Eine vollständige Redirect-Map vor dem Go-live ist Pflicht.

Phase 6: Testing, Go-live und Nachbetreuung

Vor dem Go-live führen wir einen umfassenden Testplan durch:

• Funktionale Tests aller Shop-Prozesse (Suche, Warenkorb, Checkout, Zahlung, Versand)
• B2B-spezifische Tests (Kundengruppen, Staffelpreise, Freigabeworkflows)
• Performance-Tests unter Last
• Mobile Responsiveness auf allen gängigen Geräten
• Payment-Provider-Integration (Test-Transaktionen)
• ERP-Synchronisierung (bidirektionaler Datenabgleich)
• Überprüfung aller 301-Weiterleitungen
• Crawling mit Screaming Frog zur Identifikation defekter Links

Der Go-live selbst wird als Blue-Green-Deployment durchgeführt: Neue Umgebung ist vollständig bereit und getestet, Umschaltung erfolgt über DNS-Änderung — mit der Möglichkeit, innerhalb von Minuten zurückzuschalten, falls etwas nicht stimmt. Nach dem Go-live folgen 2–4 Wochen intensives Monitoring und schnelle Reaktion auf gemeldete Issues.

Häufige Fallstricke bei der OXID Migration — und wie man sie vermeidet

Fallstrick 1: Modul-Kompatibilität unterschätzt

Viele Shopbetreiber denken, ihre Module laufen "einfach so" in OXID 7 weiter. Das ist selten der Fall — besonders bei OXID-4-Modulen. Eine gründliche Kompatibilitätsanalyse vor Projektstart verhindert böse Überraschungen im Budget.

Fallstrick 2: SEO-Auswirkungen ignoriert

URL-Struktur-Änderungen ohne 301-Redirects können organischen Traffic um 30–60 % einbrechen lassen. Dieser Fehler kostet mehr als die gesamte Migration. Erstellen Sie eine vollständige Redirect-Map und validieren Sie diese mit Google Search Console nach dem Go-live.

Fallstrick 3: Datenmigration ohne Validierung

Fehlende Artikel, falsche Preise oder defekte Produktbilder nach der Migration wirken sich direkt auf Umsatz aus. Planen Sie mindestens zwei vollständige Datenmigrations-Testläufe vor dem Go-live ein — mit manueller Stichprobenprüfung in jeder Produktkategorie.

Fallstrick 4: Go-live ohne Rollback-Plan

Jede Migration kann Unvorhergesehenes aufdecken. Ohne eine funktionierende Rollback-Strategie sind Sie im Worst Case stundenlang offline. Halten Sie das alte System noch mindestens 4 Wochen nach Go-live parallel betriebsbereit.

Fallstrick 5: Performance-Tuning vergessen

Ein neues OXID 7 ohne Caching-Konfiguration (Varnish, Redis, OPcache) ist oft langsamer als das alte System — trotz modernerer Codebasis. Performance-Tuning ist kein optionaler Add-on, sondern Bestandteil jeder professionellen Migration.

Was kostet eine OXID Migration?

Die Kosten einer OXID-Migration hängen stark von der Ausgangslage ab. Als Orientierung:

• OXID 6.x → OXID 7 (einfacher Shop, wenige Custom-Module): 8.000 – 20.000 €
• OXID 6.x → OXID 7 (komplexer Shop, ERP-Anbindung, Custom-Theme): 20.000 – 60.000 €
• OXID 4.x → OXID 7 (vollständiger Neuaufbau erforderlich): 30.000 – 100.000 €
• B2B-Portal mit komplexen Preismodellen und ERP-Integration: 60.000 – 150.000 €

Diese Zahlen klingen nach viel — bis man sie gegen die Alternative rechnet: Ein kompromittierter Shop durch eine ungepatchte Sicherheitslücke, Datenverlust, Bußgelder nach DSGVO-Verstoß oder der komplette Vertrauensverlust bei Kunden. Die Migration ist eine Investition, kein Kostenfaktor.

Seriöse Agenturen erstellen nach einem initialen Audit eine belastbare Festpreisschätzung — keine grobe Hausnummer. Verlangen Sie das, bevor Sie einen Auftrag erteilen.

OXID 7 Migration selbst durchführen oder Agentur beauftragen?

Technisch versierte Teams können eine OXID-6-zu-7-Migration mit wenigen Standardmodulen selbst durchführen. Die OXID-Dokumentation ist gut, die Community aktiv. Aber die Risiken steigen erheblich, wenn:

• Viele Custom-Module beteiligt sind, die tiefes OXID-Internals-Wissen erfordern
• Eine ERP-Integration neu aufgebaut werden muss
• Der Shop mehr als 50.000 Artikel hat (Datenmigration wird komplex)
• B2B-spezifische Preislogiken und Kundengruppen-Strukturen migriert werden müssen
• Das bestehende Theme stark individualisiert ist
• Sie von OXID 4.x kommen (kein direkter Migrationspfad)

In diesen Fällen ist eine spezialisierte OXID-Agentur nicht nur empfehlenswert — sie ist der Unterschied zwischen einem erfolgreichen Go-live und einem kostspieligen Fehlschlag. Eine Agentur mit echten OXID-Projekterfahrungen bringt erprobte Tooling, Migrationsskripte, Testframeworks und Fallback-Strategien mit — und spart damit am Ende Zeit und Geld.

OXID Migration und SEO: Was Sie unbedingt beachten müssen

E-Commerce-Projekte leben von organischem Traffic. Eine schlecht geplante Migration kann Google-Rankings, die über Jahre aufgebaut wurden, innerhalb weniger Wochen halbieren. Folgende SEO-Maßnahmen sind Pflicht:

• Vollständige URL-Inventarisierung vor der Migration — alle gecrawlten URLs exportieren und abgleichen.
• 301-Redirect-Map für alle geänderten URLs — Kategorieseiten, Produktseiten, Content-Seiten.
• Canonical Tags korrekt setzen — besonders bei Produktvarianten und gefilterten Kategorie-URLs.
• Structured Data (Schema.org) neu aufbauen — Product, BreadcrumbList, Organization.
• XML-Sitemap nach Go-live neu einreichen in der Google Search Console.
• Pagespeed/Core Web Vitals messen — LCP, CLS, FID vor und nach Migration vergleichen.
• Google Search Console mindestens 60 Tage nach Go-live täglich monitoren — Crawling-Fehler sofort beheben.
• Backlink-Profil prüfen — externe Links auf alte URLs müssen über 301 weiterleiten.

Wer diese Punkte konsequent abarbeitet, kann eine Migration durchführen, ohne signifikante Ranking-Verluste zu erleiden — und oft sogar Verbesserungen erzielen, weil das neue System bessere Performance und sauberere HTML-Struktur bietet.

Nach der Migration: OXID 7 optimal nutzen

Eine erfolgreiche Migration ist der Startschuss — nicht das Ziel. Mit OXID 7 stehen Features zur Verfügung, die vorher nicht möglich waren:

• GraphQL API für Headless-Commerce-Szenarien oder Mobile App-Anbindungen
• Modernere B2B-Features: Erweiterte Freigabeworkflows, Kundengruppen-Management und Nettopreisdarstellung
• Performance-Optimierung durch Redis-Session-Caching, Varnish und OPcache
• CI/CD-Pipeline mit Composer und GitHub Actions für schnelle, sichere Deployments
• Erweiterte Elasticsearch-Integration für schnelle, relevante Produktsuche
• OXID eShop 7 B2B Module für komplexe Einkaufsprozesse im Großhandel

Nutzen Sie die Migration als Anlass, Ihren Shop nicht nur technisch zu modernisieren, sondern auch strategisch weiterzuentwickeln: bessere Conversion-Rate durch schnellere Ladezeiten, neue Umsatzpotenziale durch B2B-Self-Service-Portale, mehr Effizienz durch automatisierte ERP-Synchronisierung.

Fazit: OXID Migration ist Pflicht — aber richtig geplant eine Chance

Wer OXID 4.x oder 6.x noch im Einsatz hat, steht unter Handlungsdruck — technisch, sicherheitstechnisch und wettbewerblich. Die gute Nachricht: Eine professionell durchgeführte Migration auf OXID eShop 7 ist kein Risiko, sondern eine Investition in die nächsten Jahre.

Entscheidend sind drei Dinge: ein gründlicher Audit vor dem Projektstart, ein erfahrenes Team mit echten OXID-Migrationsprojekten im Portfolio, und ein strukturierter Go-live-Prozess mit Rollback-Option und SEO-Monitoring. Dann wird aus der technischen Pflichtübung ein strategischer Sprung nach vorn.

Webect begleitet OXID-Migrationsprojekte von der Erstanalyse bis zum laufenden Betrieb nach Go-live — mit Festpreisangeboten, transparentem Vorgehen und Projekthistorie, die Sie sich ansehen können. Sprechen Sie uns an.