Plugin: Migration von anderen Shopsystemen zu Shopware

Migration von anderen Shopsystemen

Mit dem Migrations-Plugin bietet Shopware diverse Möglichkeiten einen bereits bestehenden Shop eines Fremdherstellers auf Basis von Shopware 4 bzw. 5 zu migrieren.

Das Migrations-Whitepaper mit hilfreichen Tipps & Informationen findest Du übrigens hier: Migration Whitepaper

Unterstützte Shopsysteme

Folgende Shopsysteme werden zurzeit unterstützt:

• Magento bis 1.7.0.2 und 1.8.1.0 bis 1.9.3.4
• Magento2 2.1.5 bis 2.1.8
• OXID eShop bis 4.9.7
• xt:Commerce VEYTON 4.0 bis 4.1
• Gambio bis GX 2.7.2.0
• xtModified & xt:Commerce bis 3.04
• Prestashop 1.4 und 1.5 bis 1.6.1.4
• WooCommerce 2.5.5

Durch unsere flexible Import-Schnittstelle kannst Du jederzeit nicht migrierbare Daten bequem nachpflegen.

Du setzt ein Shopsystem ein, was noch nicht über unser Migration-Tool unterstützt wird, dann findest Du über unsere Shopware-Partner kompetente Unterstützung bei Deiner Shop-Migration zu Shopware.

Übersicht der migrierbaren Felder

Hier ein Übersicht über die migrierbaren Felder:

* wird bei der aktuellen Version des Migration-Plugin nur bedingt unterstützt
** Diese Daten liegen im Quellsystem nicht vor, können daher auch nicht importiert werden *** nach der Migration müssen im Medienmanager im Backend von Shopware die Thumbnails neu generiert werden

Benutze immer die aktuelle Version des Migration-Plugin. Die aktuelle Version des Plugin kannst Du hier downloaden.

Installation

Diese Erweiterung findest Du in unserem Shopware Store, der einfachste Weg, ein bestimmtes Plugin zu finden, ist die Suchleiste.
Nachdem Du den Bestellvorgang abgeschlossen hast, logge Dich in das Backend Deines Shops ein. Jetzt gehst du zu Konfiguration > Plugin-Manager > Meine Einkäufe. Du musst dich einloggen und auf die Schaltfläche Aktualisieren klicken. Die neue Erweiterung ist nun aufgelistet und kann installiert werden. Nach der Installation der Erweiterung gehst Du auf den Menüpunkt Installiert und aktualisierst die Übersicht. Jetzt kannst Du die Erweiterung aktivieren. Abschließend löscht Du unter Einstellungen > Cache/Performance > Shop-Cache löschen den Cache und aktualisierst das Backend.

Vor und nach der Migration zu beachten

Checkliste vor der Migration

• Überprüfe zuerst im Backend von Shopware unter Einstellungen > Systeminfo, ob die Mindestvoraussetzungen vorhanden sind und passe diese vorab an. Andernfalls kann es bei der Migration zu einem Abbruch kommen.
• Zur Migration werden die Datenbank-Zugangsdaten des alten Shopsystems benötigt! Die Datenbank muss entweder lokal auf dem Shopware System vorliegen, oder ein externer Zugriff auf die Datenbank muss freigeschaltet sein.
• Lege einen Standard-Hersteller an
• Genutzte Eigenschafts-Felder aus Deinem alten Shop sollten vorab in Deiner Shopware 5 Installation bereits als Eigenschafts-Gruppe/Set angelegt werden. So vermeidest Du eine unnötige Unterbrechung des Migrations-Vorgangs beim Mapping der einzelnen Eigenschaften.
• Kontrolliere vorab, welche Kundengruppen migriert werden sollen und lege diese vorab in Shopware 5 an
• Kontrolliere vorab, welche Preisgruppen migriert werden sollen und lege diese vorab in Shopware 5 an
• Überprüfe welche Sprachen (Sprachshops) übernommen werden sollen und lege vorab die entsprechenden Sprach-Subshops im Backend von Shopware 5 an
• Setze den zu migrierenden Shops in einen Wartungsmodus
• Damit Sprachsubshops gemappt werden können, müssen diese in den Shopeinstellungen von Shopware vorab aktiviert werden. Nicht aktivierte Subshops werden im Mapping ausgeblendet.

Checkliste nach der Migration

• Überprüfe nach der Migration die fortlaufenden Nummernkreise (z.B. von Rechnungen, Kunden) und passe diese ggfls. an.
• In Shopware müssen Artikel immer der untersten Kategorie zugewisen werden. Sofern Du in Deinem alten Shop Artikel anstatt der untersten Ebene auch einer Kategroie der mittleren Ebene zugeordnet hast, so werden die Artikel zwar migriert aber nicht einer Kategorie zugewiesen. Du kannst diese Artikel nach der Migration ganz leicht in der Artikelübersicht mit dem Filter Ohne Kategorie anzeigen lassen und entsprechend einer Kategorie der untersten Ebene zuweisen.

Starten der Migration

Bevor Du mit der Migration startest, solltest Du immer ein aktuelles File- und Datenbankbackup Deiner Shopware 5-Installation anlegen.

Während des Migrations-Vorgangs werden Dir die zu verknüpfenden Eigenschaften Deines Shops angezeigt. Hierbei wird zwischen Mapping Erfolgreich (1), Mapping Optional (2) und Mapping zwingend erforderlich (3).

Schritt 1: Verbindungsaufbau zum Shop-System

Im ersten Schritt wähle vorab den zu migrierenden Shop (1) aus.

Stelle nun eine Verbindung zur mySql-Datenbank des zu migrierenden Shop her. Du benötigst hierfür zuerst den Benutzernamen (2) und das Passwort (3) für den mySql-Server.

Hinterlege nun die Adresse (4) und den Standard-Port (5) des mySql-Servers. Wenn sich die Datenbanken des zu migrierenden Servers und der Shopware 5-Installation auf dem gleichen Server befinden, so trage hier "localhost" ein. Andernfalls muss hier die abweichende Server-Adresse hinterlegt werden.

Gebe nun den Prefix der zu importierenden Datenbanktabellen (6). Wenn Du keinen abweichenden Prefix in Deinem alten Shop benutzt, kannst Du diese Einstellung auf "default" stehen lassen.

Im abschließenden Schritt kannst Du nun die zu migrierende Datenbank auswählen (7). Sofern die Zugangsdaten im oberen Teil alle fehlerfrei hinterlegt wurden, werden nun alle Tabellen des Servers ausgelesen und stehen nun zur Auswahl. Falls Dir hier keine Datenbanken zur Auswahl steht, so überprüfe die zuvor hinterlegten Zugangsdaten zum mySql-Server

Am Ende des Formulars findest Du den Button Den aktuellen Shopware-Shop zurücksetzen (8). Diese optionale Funktion ist u.U. erforderlich, da das Migrations-Plugin bestehende Kategorien oder Artikel weder aktualisiert noch ersetzt. Wurden bereits bestehende Kategorien oder Artikel gefunden, wird die Migration mit einer entsprechenden Fehlermeldung abgebrochen.

Artikel, Artikelbilder, Kundendaten, Hersteller, Bestellungen und Kategorien innerhalb von Shopware werden in diesem Schritt sofort und unwiderruflich gelöscht.

Falls Du die Zugangsdaten der Installation Deines alten Shops nicht vorliegen hast, so kannst Du diese im Administrationsbereich Deines Hostingpaketes einsehen. Alternativ besteht die Option sich dort mit dem Hoster in Verbindung zu setzen. Wenn Du lediglich den MySQL Dump Vorliegen hast, importiere die Datenbank in Deine Struktur und spreche diese dann lokal an.

Schritt 2: Shop-Migration

Nachdem abgeschlossenen ersten Schritt, geht es im zweiten Schritt vor allem um die Übernahme wichtiger Shopeinstellungen. Durch einen Doppelklick in das Mapping-Feld öffnest Du das Dropdown-Feld mit den entsprechenden Einstellungen.

Hier hast Du die Möglichkeit, Attribute/Eigenschaften, Sprachen, Bestellstatus, Zahlungsarten oder gar Preisgruppen in Deinem neuen Shop zu importieren.

Das Magic-Mapping unterstützt Dich bei dieser Arbeit und wählt gleichlautende Shopware-Felder automatisch zu den passenden Feldern aus. Diese Vorauswahl funktioniert im gesamten Mapping. Jede Vorauswahl kann natürlich auch manuell verändert werden.

Achte beim Mappen von Preis- und Kundengruppen darauf, dass Du jede Gruppe aus dem Quellshop immer nur einmalig auf die jeweilige Gruppe von Shopware mappst. Beim mehrfachen Mapping kann es sein, dass die Shopware-Gruppen von den Gruppen aus dem Quellshop immer wieder überschrieben werden.

Schritt 3: Import-Einstellungen

Im letzten Schritt der Migration kannst Du anhand der Selektierung die gewünschten Einstellungen im Rahmen der Migration auswählen.

Da beim Anlegen eines Artikels der Hersteller ein Pflichtfeld ist, musst Du hier einen Standard-Hersteller aus der Liste hinterlegen.

Im Feld "Shop-Path zu den Artikel-Bildern (z.B. http://domain.de/shop):" gib den Pfad des alten Shops an.

Das Feld "Default-Hersteller" ist nur relevant für Artikel, die aus dem anderen Shopsystem keine Zuordnung eines Herstellers besitzen! Nach Abschluss der Migration hast Du ebenso die Möglichkeit, den Hersteller für die jeweiligen Artikel zu modifizieren.

Falls die Artikel aus dem anderen Shopsystem bereits mit einem Hersteller geführt werden, so wird dieser automatisch in der Herstellerverwaltung hinzugefügt.

Debug-Modus

Das Migrations-Plugin bietet einen kleinen Debug-Modus. Dieser lässt sich in der Plugin-Konfiguration (zu finden im Plugin-Manager) des Migrations-Skriptes aktivieren (1):

Ist die Debug-Ausgabe aktiv, werden die Queries zum Auslesen der Quell-Datenbank in die Datei /files/migration.log geschrieben. Hier werden u.a. die zuletzt ausgeführten Methoden festgehalten, der ausgeführte Query und ein SQL EXPLAIN für den Query, das angibt, wie der SQL-Server den Query abgearbeitet hat (langsame filesorts oder schnelle Index-Zugriffe). Zudem wird gemessen, wie lange der Query gedauert hat.

Die Angaben sind hilfreich, um nicht optimierte Queries zu identifizieren. Beachte hierzu auch die nachfolgende Liste mit Indizes welche gesetzt werden können um die Queries zu beschleunigen.

Durch das Aktivieren der Debug-Ausgabe wird die Performance des Migrations-Skriptes negativ beeinflusst!

Hinweise zur Migration

Optimierung des mysql-Servers

Für eine anständige Performance ist eine korrekte Konfiguration des Mysql-Servers erforderlich. 

Aus Konsistenz-Gründen müssen die zu importierenden Daten an verschiedenen Stellen sortiert werden. Beispielsweise um zu verhindern, dass Kind-Entities vor Vater-Entities importiert werden. Das ist in aller Regel bei Kategorien der Fall, ggf. auch bei Artikeln und Preisen. Wenn es hier zu Problemen kommt, können bei Bedarf zusätzliche Indizes (s.u.) gesetzt oder die Sortiert-Buffer des SQL-Servers erhöht werden.

Die MySQL-Doku empfiehlt hier:

• Erhöhen von sort_buffer_size
• Erhöhen von read_rnd_buffer_size

Optimierung der zu migrierenden Datenbank

Für den vollständigen Daten-Import sind teilweise Joins erforderlich, für die in der Quell-Datenbank keine Indizes existieren. Diese werden nicht automatisch durch das Skript gesetzt.

Lege vorab ein Backup an, bevor Du Indizes in Deiner Quelldatenbank setzt.

Nachfolgend eine Auflistung möglicher zusätzlicher Indizes:

Oxid

Produkt-Import:

ALTER TABLE `oxarticles` ADD INDEX `oxid_oxparentid` (`OXID`, `OXPARENTID`)

Kunden-Import:

ALTER TABLE `oxobject2group` ADD INDEX `oxobjectid_oxgroupsid` (`OXOBJECTID`, `OXGROUPSID`)

Veyton

Bild-Import:

ALTER TABLE `xt_media_link` ADD INDEX  (  `m_id` );
ALTER TABLE  `xt_products` ADD INDEX  (  `products_image` ); 

Produkt-Import:

ALTER TABLE `xt_products` ADD INDEX ( `products_model`) 

XTC, Gambio

Import der Bestell-Details:

ALTER TABLE  `orders_products_attributes` ADD INDEX (  `orders_products_id` )

Allgemeine Hinweise

Nach dem Import kann es zu abweichenden Datenbeständen kommen. Das hängt damit zusammen, dass die verschiedenen Shopsysteme unterschiedliche Mindestanforderungen an die jeweiligen Datensätze stellen. Hier einige Beispiele:

• Bewertungen: In Shopware kann jedes Produkt nur einmal je Benutzer (Mail) bewertet werden. Hat im Quell-Shop ein Benutzer öfter bewertet, gehen die übrigen Bewertungen verloren
• Kunden: In Shopware ist es nicht möglich, sich mit derselben Mail-Adresse mehrmals zu registrieren (sofern gültige Kundenkonten benutzt werden). "Doppelte" Benutzerkonten werden nicht importiert.

OXID eShop

• Eigenschaften: Lege vor der Migration eine Gruppe an, in welche alle Artikel-Eigenschaften von Oxid migriert werden. Werden keine Eigenschaften zugeordnet, werden diese der automatisch erstellten Gruppe "Properties" zugeordnet.
• Eigenschaften: Im Mapping werden alle in Oxid vorhandenen Eigenschaften-Optionen angezeigt. Diese werden später aber nur importiert, wenn mindestens ein Artikel auch tatsächlich die entsprechenden Optionen benutzt. "Verwaiste" Optionen werden daher nicht importiert.
• Lieferadressen: Abweichende Lieferadressen werden nicht importiert. Hier gilt nach der Migration: Rechnungsadresse = Rechnungsadresse

Prestashop

• Konfiguratoren: Aus technischen Gründen werden die Artikel direkt in Konfiguratoren überführt.
• Konfiguratoren: Da es in SW keine Gewichts-Aufschlags-Konfiguratoren gibt, gehen diese Informationen verloren.
• Konfiguratoren: In SW gibt es keine Preis-Abschlag-Konfiguratoren. Preis-Aufschläge < 0 werden daher ignoriert.
• Passwörter: Passwörter können nur dann migriert werden, wenn das Salt eingegeben wird. Prestashop benutzt als Salt die Variable _COOKIE_KEY_ in der Datei /config/settings.inc.php (1). Kopiere dort das hinterlegte Salt und füge diesen in das Feld Passwort Salt (2) ein.

Wenn die Kunden sich nach der Migration mit ihrem alten Password einloggen können sollen, darf das Migrationstool nicht deinstalliert werden, da es den Passwort-Encoder für die migrierten Kunden bereitstellt. Nachdem sich ein Kunde einmal eingeloggt hat, wird sein Passwort auf Shopware-Basis portiert und ist nicht mehr von dieser Einschränkung betroffen.

xtModified & xt:Commerce

• Lieferzeiten: Lieferzeiten können nicht übernommen werden - es wird auf die Fallback-Lieferzeit von SW4 gemappt (Grundeinstellungen > Warenkorb / Artikeldetails).
• Konfiguratoren: Aus technischen Gründen werden die Artikel direkt in Konfiguratoren überführt
• Konfiguratoren: Da es in SW keine Gewichts-Aufschlags-Konfiguratoren gibt, gehen diese Informationen verloren.
• Konfiguratoren: In SW gibt es keine Preis-Abschlag-Konfiguratoren. Preis-Aufschläge < 0 werden daher ignoriert
• Lieferadressen: Abweichende Lieferadressen werden nicht importiert. Hier gilt nach der Migration: Rechnungsadresse = Rechnungsadresse

Gambio bis GX

• Lieferzeiten: Lieferzeiten können nicht übernommen werden - es wird auf die Fallback-Lieferzeit von SW4 gemappt (Grundeinstellungen > Warenkorb / Artikeldetails).
• Konfiguratoren: Aus technischen Gründen werden die Artikel direkt in Konfiguratoren überführt.
• Konfiguratoren: Da es in SW keine Gewichts-Aufschlags-Konfiguratoren gibt, gehen diese Informationen verloren
• Konfiguratoren: In SW gibt es keine Preis-Abschlag-Konfiguratoren. Preis-Aufschläge < 0 werden daher ignoriert
• Lieferadressen: Abweichende Lieferadressen werden nicht importiert. Hier gilt nach der Migration: Rechnungsadresse = Rechnungsadresse

Magento

• Eigenschaften: Lege vor der Migration eine Gruppe an, in welche alle Artikel-Eigenschaften von Magento migriert werden.
• Benutzerdefinierte Eigenschaften: Es werden die benutzerdefinierten Eigenschaften importiert. Diese tauchen beim Attribut-Mapping auf. Wenn diese migriert werden sollen, müssen in SW vorab entsprechende Attributsfelder angelegt werden.

Veyton

• Eigenschaften: Produkteigenschaften werden zur Zeit noch nicht übernommen
• Lieferadressen: Abweichende Lieferadressen werden nicht importiert. Hier gilt nach der Migration:Rechnungsadresse = Rechnungsadresse

WooCommerce

• Zahlungsarten: können nicht importiert werden, da die Datenstruktur in WooCommerce nicht einheitlich ist. Hier wird standardmäßig auf "Vorkasse" importiert.
• Hersteller: Da in WooCommerce keine Hersteller gepflegt werden, wird der Standardhersteller gesetzt.
• Kundennummern: Da in WooCommerce im Standard keine Kundennummern existieren, vergibt Shopware eigene Kundennummern.
• Kundengruppen-Preise: Da WooCommerce keine Kundengruppen bereitstellt, können keine Kundengruppen-Preise importiert werden.
• Staffelpreise: WooCommerce lässt im Standard keine Staffelpreise zu, daher wird immer nur der erste Preis importiert.

FAQ / Häufige Probleme

Artikel werden den falschen Kategorien zugeordnet

Falls nach der Migration die Artikel nicht den richtigen Kategorien zugeordnet werden, muss der Kategoriebaum im Performance-Modul von Shopware neu aufgebaut werden.

Pro request wird immer nur 1 Datensatz migriert

Falls pro request immer nur ein Datensatz (z.B. 1 Bestellung pro Import-Schritt) importiert wird, so liegt wahrscheinlich ein Performance-Problem seitens des Servers vor. Erhöhe die max_execution_time in den PHP-Einstellungen Deines Servers um ein vielfaches. Das Auslesen der Datensätze ist sehr langsam - und es kann sein, dass das Migrations-Plugin beim Vorbereiten der Daten schon keine Zeit mehr "übrig" hat. In diesem Fall importiert das Migrations-Plugin noch eine Bestellung und fordert dann einen neuen Request an.

Magento: SQLSTATE(HY000): General error: 1116 Too many tables; MySQL can only use 61 tables in a join

Das Problem tritt auf, wenn zu viele Magento-Attribut-Tabellen gejoint werden. Auf Grund technischer Limitierungen von MySQL steigt in disem Fall irgendwann der Server aus.

Möglicher Lösunsgansatz: 

Anpassung von \Shopware_Components_Migration_Profile_Magento::getProductSelect:#

Dort werden am Anfang mit der Methode getAttributes() die zu selektierenden Attribute gejoint und dann später mit der Methode createTableSelect() an den Produkt-Query gejoint.

Den Rückgabewert der Methode getAttributes() könnte der Kunde so anpassen, dass nur benötigte Attribute geladen werden.

Alternativ werden die zu ladenden Attribute anhand folgender Kriterien identifiziert:

AND et.entity_type_code='catalog_product'
AND ea.frontend_input!=''
AND (ea.is_user_defined=1 OR ea.attribute_code IN ('visibility', 'meta_description', 'meta_title', 'url_key'))
AND ea.attribute_code NOT IN ('cost', 'manufacturer')

Würde beispielsweise Feld "frontend_input" für nicht-benötigte Attribute auf "" gesetzt, so sollten diese ebenfalls nicht selektiert werden.

XTC/Gambio: Artikel werden ohne Beschreibung migriert

Werden die Artikel ohne Beschreibung und Name migriert, hängt dies in aller Regel mit Sprachshops zusammen. Ist in Gambio/XTC der englische Sprachshop der Hauptshop, geht die Migration davon aus, dass dies auch in Shopware so konfiguriert wurde. Ist dies nicht der Fall, werden die Beschreibungstexte der Artikel nicht korrekt zugeordnet und als "Übersetzung" angelegt.

Hier gibt es im Wesentlichen zwei mögliche Lösungen:

• In Shopware den Hauptshop auf "Englisch" umstellen - sowohl die Hauptkategorie als auch die Sprache müssen dafür auf "Englisch" gesetzt werden.

oder:

• Im Quellshop in der Tabelle languages das Feld sort_order so ändern, dass die deutsche Sprache einen kleineren Wert als die englische Sprache hat. Hier empfiehlt es sich, auf einer Kopie zu arbeiten oder vorher zumindest ein Backup anzulegen.

Nach dieser Anpassung werden die Artikel korrekt zugeordnet.