Eine 8-minütige Lesung

Plattform-Migrationen für stark frequentierte Handelsgeschäfte können in ihrer Komplexität extrem unterschätzt werden. Im Idealfall verwenden Sie einfach das Migrations-Plugin und alles sollte funktionieren. In Wirklichkeit geschieht dies jedoch nicht so. In diesem Blog-Beitrag möchte ich Ihnen unsere Erfahrungen mit der Migration eines OXID-Shops auf Shopware 5.4 mitteilen.

Unser Kunde, ein großer Hersteller von Büromöbeln und -einrichtungen, hatte Probleme mit der Verwaltung des schnellen Wachstums seines E-Commerce-Geschäfts (hauptsächlich für B2B-Kunden) und war ständig auf der Suche nach einer robusteren Lösung. Sie wollten eine Plattform, die große Datenmengen mit einer besseren Cache-Verwaltung verwalten kann. Daneben erforderte ihr Geschäft die Integration vieler interner Systeme mit ihrem Handelsspeicher. Nach sorgfältiger Bewertung wurde Shopware als Plattform für die Migration des E-Commerce-Shops ausgewählt.

Ihr Team erwähnte während der Forschungs- und Entwicklungsphase, dass sie ein vorhandenes, von der SW erstelltes Plugin gefunden haben, das die Plattformmigration mit Daten mit nur wenigen Klicks unterstützt und ein nahtloser Prozess ist. Ihr hausinternes Team arbeitete daran und war schockiert, als es feststellte, dass nach Abschluss des Migrationsprozesses mit Hilfe des Plugins die Gesamtzahl der Artikel im Vergleich zu den Artikeln im ursprünglichen Geschäft stieg, was eine große Wirkung hatte; daher wandte sich sein Team an uns mit der Bitte, diesen Fehler zu beheben. Wir hatten bereits einige Erfahrungen mit dem Standard-Plugin, deshalb haben wir sie darüber informiert, dass das Plugin die Produkte mit Varianten im älteren (OXID) Shop nach der Migration als eigenständiges Produkt betrachtet hat (statt als Variante eines Kernproduktes gezählt zu werden). Wir analysierten die Daten des Shops und machten deutlich, dass das Plugin für solche Shops mit komplexen Produktdaten mit Varianten nicht geeignet ist.

Obwohl sie in der ursprünglichen Aufgabenstellung nur wollten, dass wir ihre Shop-Daten von der früheren Plattform auf die letztere migrieren und dabei alle Datenbankfelder intakt lassen; da die Dinge an ihrem Ende neu überdacht wurden, fügte sie immer wieder viele Ideen und Anpassungen zu den ursprünglichen Anforderungen hinzu, und so wurde die ursprüngliche Anfrage vollständig umgewandelt und die überarbeitete Anfrage um umfangreiche Funktionalitäten erweitert.

Um die gesamte Migration und Anpassung der Produktseiten schnell und präzise durchzuführen, schlugen wir als letzten Ausweg ein individuelles Skript vor. Unser Kunde war damit einverstanden, da wir bereits regelmäßige Treffen, Anrufe und den Austausch aktueller Nachrichten über unsere Projektmanagement-Kanäle hatten. Wir haben ihnen gesagt, dass das SW-Standard-Plugin für die Migration anderer Module verwendet werden kann; um die Anpassung der Produktseite zu integrieren, war das Schreiben des Skripts jedoch unerlässlich, was viel mehr Zeit in Anspruch nimmt als die direkte Migration des Shops über das Standard-Plugin.

Die Daten des bestehenden Shops waren OXID-basiert, was sich von jeder anderen Plattform unterscheidet. Obwohl beide Plattformen in PHP geschrieben sind und MySQL verwenden, ist die Normalisierung der Entitäten immer noch unterschiedlich. Die genaue Methode, die wir für den Prozess ausgearbeitet haben, wird im Folgenden erläutert:

➢ In erster Linie haben wir die Daten aus der OXID-Datenbank geholt, sie in eine Shopware-freundliche Struktur gebracht und alle Datenfelder in die neue Datenbank eingefügt.

➢ In der ersten Phase wurde der Bild- und Produkt-Import mit Hilfe des benutzerdefinierten Plugins durchgeführt, das wir entwickelt hatten und das wir seit einiger Zeit für andere Oxid zu Shopware-Migrationsanfragen verwenden.

➢ Der nächste Schritt war der Import von Eigenschaften von Artikeln, wie z.B. einem Filter, der bei der Suche nach Artikeln auf der Frontend-Liste hilft, unter Verwendung unseres eigenen benutzerdefinierten Skripts, das ebenfalls bereits von unseren Entwicklern verwendet und bereits von unserem internen SQA-Team getestet wurde.

➢ Interessanterweise hatten sie die Freiheit, die den Käufern zur Verfügung stand, und boten die Option für Sonderanfertigungen an, wie z.B. die Anpassung der vorhandenen Möbel online, indem sie live Änderungen gemäß den Designanforderungen des Käufers anforderten, oder wenn jemand eine andere Änderung benötigt, um die Themen der Innendekoration zu verfolgen, die auch in seinem Geschäft durchgeführt werden konnte, importierten wir die Daten der Sonderanfertigungen mit dem Shopware-Plugin.

Wir haben dieses Projekt in der versprochenen Zeitlinie geliefert, einschließlich aller Fehlerbehebungen, SQA und Tests. Wir feierten ein weiteres erfolgreich abgeschlossenes Projekt mit einer kleinen Party, die uns von unserem glücklichen Kunden verliehen wurde. Damit haben wir einen weiteren Kunden in unser Portfolio aufgenommen, der unsere Shopware-Beratungskompetenz und unseren Kommunikationsfluss bewundert und sich als einer unserer langfristigen Partner erwiesen hat. Sie nehmen weiterhin unsere Unterstützung in Anspruch, und wir haben vor kurzem ihren Shop auf Shopware 6 aktualisiert. 🙂

Eine Lektion, die man aus der Handhabung vieler Migrationen gelernt hat, ist, dass vor der Planung und Gestaltung der Lösung eine sorgfältige Analyse der vorhandenen Daten durchgeführt werden muss. Dadurch wird eine gut durchdachte Ausführung während der Projektphase gewährleistet. Wir bei ZEPCOM sind auf komplexe Migrationen zwischen Shopsystemen spezialisiert. Wir würden uns freuen, Ihr Projekt zu besprechen und Ihnen unsere Erkenntnisse mitzuteilen, damit Sie die Migration besser planen können.

Write a comment:
*

Your email address will not be published.