Blog

Ein OXID 7 Update scheitert selten am Austausch der Shopdateien. Schwierigkeiten entstehen dort, wo der reale Shop vom Standard abweicht: bei eigenen Modulen, einem angepassten Theme, älteren Composer-Abhängigkeiten oder Schnittstellen, deren Verhalten seit Jahren niemand mehr vollständig dokumentiert hat.

Deshalb sollte vor dem Wechsel auf OXID eShop 7.5 geklärt werden, ob tatsächlich eine überschaubare Aktualisierung ansteht oder ein Migrationsprojekt. Diese Unterscheidung bestimmt den Testaufwand, die Rückfallstrategie und letztlich auch die Kosten.

Normales Update oder echte OXID Migration?

Bei einem Shop, der bereits auf einer Version von OXID eShop 7 läuft, bleiben Architektur und zentrale technische Konzepte weitgehend vertraut. Trotzdem ist ein Sprung auf OXID 7.5 kein automatischer Routinevorgang. Abhängigkeiten in der composer.json, Änderungen am Core, Datenbankmigrationen sowie neue Versionen installierter OXID Module müssen zusammenpassen.

Der Wechsel von OXID 6.5 auf OXID eShop 7.5 ist anders einzuordnen. Hier treffen größere technische Veränderungen auf einen Shop, der häufig noch Smarty-Templates, ältere Modulstrukturen oder inzwischen überholte Bibliotheken verwendet. Aus einem vermeintlichen „OXID 6 auf 7“-Update wird dann eine Migration mit Anpassungs- und Testbedarf.

Die Versionsnummer allein liefert daher keine belastbare Aufwandsschätzung. Ein schlanker Shop auf 6.5 kann leichter zu migrieren sein als ein stark individualisierter Shop auf einer frühen 7er-Version. Entscheidend ist der tatsächlich eingesetzte Code, nicht die Anzahl der im Backend sichtbaren Module.

Bestandsaufnahme: Systembasis, Module und Theme

Die Zielversion bestimmt die Plattform

Vor der Aktualisierung werden PHP-Version und Erweiterungen, Webserver, Datenbankserver, Composer-Version, Dateirechte, Cronjobs und verfügbare Ressourcen geprüft. Eine pauschale Aussage wie „PHP 8 ist vorhanden“ reicht nicht. Maßgeblich sind die konkreten Abhängigkeiten der Zielversion und der eingesetzten Pakete.

Nach dem von uns geprüften Stand vom 16. Juli 2026 sollten die verbindlichen Anforderungen direkt in der offiziellen Entwicklerdokumentation zu OXID 7.5 und in den Composer-Metadaten des jeweiligen Projekts abgeglichen werden. Neben einer passenden PHP- und Composer-2-Umgebung gehören dazu eine unterstützte MySQL- beziehungsweise MariaDB-Version, benötigte PHP-Erweiterungen und ausreichend Arbeitsspeicher für Composer-Prozesse. Das Hosting muss außerdem CLI-Zugriff, kontrollierte Deployments und eine getrennte Staging-Umgebung ermöglichen.

Wer bei dieser Prüfung feststellt, dass das Betriebssystem oder die Datenbank ebenfalls erneuert werden muss, plant besser zwei sauber getrennte Arbeitspakete. Ein gleichzeitiger Wechsel von Shop, PHP, Datenbank und Serverplattform erschwert die Fehlersuche erheblich. Informationen zu solchen Abhängigkeiten gehören bei uns zur Betrachtung von Hosting und IT-Infrastruktur.

Installiert bedeutet noch lange nicht kompatibel

Für jedes Modul muss geklärt werden, ob eine für OXID 7.5 freigegebene Version existiert, welche Composer-Abhängigkeiten sie mitbringt und ob Konfiguration oder Daten migriert werden müssen. Bei Standardmodulen ist die Herstellerfreigabe ein guter Ausgangspunkt. Sie ersetzt aber keinen Funktionstest im konkreten Shop.

Eigenentwicklungen brauchen eine Codeanalyse. Typische Fundstellen sind veraltete Klassen, Core-Erweiterungen, Event-Handling, Datenbankzugriffe, eigene Konsolenbefehle und Templates. Aus unserer Erfahrung fallen gerade kleine Module auf, die jahrelang unauffällig liefen: ein zusätzlicher Bestellstatus, eine spezielle Preislogik oder ein Export, der direkt auf Tabellen zugreift.

Beim OXID Theme ist vor allem die Template-Technik relevant. Ein gewachsenes Smarty-Theme aus OXID 6.5 wird nicht durch das Kopieren seines Verzeichnisses zu einem OXID-Twig-Theme. Templates, Blöcke, eigene Funktionen und JavaScript-Anpassungen müssen geprüft und gegebenenfalls für Twig neu umgesetzt werden. Auch bei einem bereits Twig-basierten Theme bleiben Layout, Checkout, Formulare, E-Mails und responsive Darstellung zu testen.

Schnittstellen müssen fachlich getestet werden

ERP-, PIM-, Zahlungs-, Such- und Marketingschnittstellen sind oft der Teil des Projekts, dessen Risiko im Backend kaum sichtbar wird. Ein Import kann technisch ohne Fehlermeldung durchlaufen und trotzdem Staffelpreise falsch zuordnen. Ein Zahlungsmodul kann den Checkout korrekt anzeigen, aber beim asynchronen Zahlungsrücklauf keinen gültigen Bestellstatus mehr setzen.

Deshalb gehören reale Prozessketten in den Testplan: Artikelanlage im PIM, Preis- und Bestandsabgleich, Bestellung mit verschiedenen Kundengruppen, Übergabe an die Warenwirtschaft, Versandmeldung, Zahlung, Storno und Gutschrift. Bei Such- und Filterlösungen sind Indexaufbau, Facetten und Sortierung zu prüfen. Marketingtools benötigen Tests für Consent, Tracking, Produktfeeds und serverseitige Rückmeldungen.

In der Praxis lohnt sich an dieser Stelle ein Blick auf Sonderfälle. Dazu zählen etwa Gastbestellungen, B2B-Kunden mit Nettopreisen, abweichende Lieferadressen, Gutscheine, Fremdwährungen oder Bestellungen mit mehreren Steuersätzen. Genau solche Fälle werden bei einem kurzen Testkauf gern übersehen.

Ein realistischer Projektablauf bis zum Go-live

Das produktive System ist kein geeigneter Ort, um Abhängigkeiten auszuprobieren. Für ein kontrolliertes OXID 7 Update hat sich ein Ablauf bewährt, bei dem Analyse, technische Umsetzung und Abnahme klar voneinander getrennt sind:

1. Ausgangsversion, Edition, Hosting, Composer-Pakete, Module, Theme und Schnittstellen vollständig erfassen.
2. Zielarchitektur festlegen und kompatible Modul- sowie Theme-Versionen beschaffen oder Anpassungen planen.
3. Produktionsnahe Staging-Umgebung mit anonymisierter oder angemessen geschützter Datenkopie aufbauen.
4. Update beziehungsweise Migration reproduzierbar durchführen und alle Datenbankmigrationen protokollieren.
5. Technische Tests, Geschäftsprozesse, Performance, Cronjobs und Schnittstellen gemeinsam prüfen.
6. Go-live-Ablauf, Datensicherung, Wartungsmodus, Verantwortlichkeiten und Rückfallgrenze schriftlich festlegen.
7. Produktiv umstellen, gezielte Smoke-Tests ausführen und Logs sowie Hintergrundprozesse eng überwachen.

Zur Vorbereitung gehört eine aktuelle, nachweislich wiederherstellbare Sicherung von Datenbank, Dateien, Konfiguration und gegebenenfalls extern gespeicherten Assets. Ein Backup ist erst dann eine Rückfallstrategie, wenn der Restore erprobt oder zumindest technisch eindeutig beschrieben wurde. Außerdem müssen Shopdateien und Datenbank immer als zusammengehöriger Stand betrachtet werden.

Die offiziellen OXID-eSales-Releases und Änderungshinweise helfen bei der Vorbereitung. Sie ersetzen jedoch nicht die projektspezifische Prüfung, denn dort ist weder die eigene ERP-Logik noch das individuelle Checkout-Template bekannt.

Ausfallzeit, Aufwand und OXID Update Kosten

Eine feste Ausfallzeit lässt sich ohne Systemanalyse nicht seriös nennen. Bei einem vorbereiteten Deployment beschränkt sie sich häufig auf das Wartungsfenster für letzte Datensicherung, Datenbankmigration, Aktivierung des neuen Stands und Smoke-Tests. Muss währenddessen ein großer Datenbestand konvertiert oder ein Suchindex neu aufgebaut werden, kann das Fenster entsprechend größer ausfallen.

Besondere Aufmerksamkeit braucht die Zeit zwischen dem Erstellen der Staging-Kopie und dem Go-live. Bestellungen, Kundenkonten und Inhaltsänderungen laufen im Produktivshop weiter. Der Umschaltplan muss deshalb festlegen, welche Daten beim Go-live frisch übernommen werden und ab wann der alte Shop keine Änderungen mehr annehmen darf.

Die OXID Update Kosten hängen vor allem von Umfang und Qualität der vorhandenen Individualisierung ab. Relevant sind die Zahl und Herkunft der Module, der Zustand des Themes, technische Schulden im eigenen Code, Umfang der Schnittstellen, Datenmenge, Hostingwechsel, Testtiefe und verfügbare Dokumentation. Auch fehlende Testzugänge zu Zahlungsanbietern oder ERP-Systemen erzeugen Aufwand, obwohl am Shopcode selbst noch nichts geändert wurde.

Ein niedriger Kostenvoranschlag auf Basis der Versionsnummer ist deshalb wenig hilfreich. Belastbarer wird die Planung nach einer technischen Voranalyse, aus der hervorgeht, welche Komponenten unverändert übernommen werden können, welche aktualisiert werden müssen und wo eine Neuentwicklung wirtschaftlicher ist.

Wann professionelle Unterstützung sinnvoll ist

Ein weitgehend standardnaher Shop mit gepflegten Paketen, aktuellem Theme und wenigen Anbindungen lässt sich intern gut vorbereiten, sofern Erfahrung mit Composer, Deployment und Datenbank-Rollbacks vorhanden ist. Unterstützung empfiehlt sich, wenn eigene OXID Module, ein individuelles OXID Theme, Twig-Migrationen, ERP-Prozesse oder geschäftskritische Zahlungs- und Importschnittstellen beteiligt sind.

Unser Rat: Vor dem ersten Umbau eine Bestandsaufnahme erstellen und daraus einen reproduzierbaren Testlauf ableiten. ITholics betrachtet als zertifizierter OXID-eSales-Partner dabei Shopsoftware, Eigenentwicklungen, Schnittstellen und Betrieb gemeinsam. Das vermeidet die typische Situation, dass der Shop im Browser fertig aussieht, während im Hintergrund Bestände, Zahlungen oder Exporte fehlerhaft laufen.

Die Freigabe sollte an geprüften Geschäftsprozessen hängen, nicht an einem fehlerfreien Seitenaufruf. Dann bleibt der Wechsel auf OXID 7.5 bei standardnahen Installationen ein gut planbares Vorhaben. Bei individuellen Systemlandschaften wird er bewusst als Migrationsprojekt geführt – mit Staging, Abnahme und belastbarer Rückfallstrategie.

Drei kurze Fragen zum OXID 7 Update

Sollte zuerst auf die neueste Version von OXID 6.5 aktualisiert werden?

Das hängt vom Ausgangsstand und dem vorgesehenen Migrationspfad ab. Häufig ist ein definierter, aktueller 6.5-Stand sinnvoll, bevor die Migration beginnt. Die zulässige Reihenfolge muss jedoch anhand der Release- und Updatehinweise sowie der installierten Pakete festgelegt werden.

Kann der alte Shop nach dem Go-live einfach wieder aktiviert werden?

Nur solange keine neuen Bestellungen oder Datenänderungen im neuen System entstanden sind. Ein Rückfall benötigt einen konsistenten Stand aus Code, Datenbank und Dateien sowie eine klare zeitliche Abbruchgrenze.

Müssen alle alten Module übernommen werden?

Nein. Vor einer Migration lohnt sich die fachliche Prüfung, ob ein Modul noch verwendet wird, durch eine Standardfunktion ersetzt werden kann oder nur historischen Ballast darstellt. Weniger Abhängigkeiten erleichtern spätere Wartung und Updates.