Plugin: Migrating from other shop systems to Shopware

Migrating from other shop systems

With the Migrations plugin, Shopware provides various options to migrate from an existing shop system to Shopware 4 or 5.

The Shopware migration whitepaper with additional tips & tricks you can find here: Migration whitepaper

Supported shop systems

The following shop systems are currently supported:

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

Our flexible Import interface allows you to easily maintain all shop data which cannot be migrated using this tool.

You currently use a shop system, which is currently not supported by our migration tool? Then you can get support by our Shopware partners at migrating to Shopware.

Overview of migratable fields

* only partially supported by the current plugin version
** will be imported as a variant by the current plugin version
*** thumbnails had to be regenerate new via the mediamanager in the backend of shopware

Be sure to always use the most current version of the plugin, which can be downloaded here.

Installation

This extension can be found in our Shopware Store, the easiest way to find a specific plugin is the search-bar. Complete the order process and login to the backend of your store. Navigate to Configuration > Plugin manager > My purchases. You need to login and click the refresh button. Your new extension is now listed and can be installed. After installing the extension go to the menu entry installed and refresh. Activate the extension. Finally delete the cache under Settings > Cache/Performance > Clear Shop Cache and refresh the backend.

Next, go to Content > Shop migration.

What to do before and after the migration

Before the migration

• In the backend, go to Configuration > System info and check to see if the system requirements have been fulfilled. You may encounter errors if these requirements are not met.
• Database access is required in order for the old shop system to migrate to Shopware 4. The database must either be located locally on the Shopware system, or access must be set up externally.
• Create a standard manufacturer.
• Shared property fields from your old system should already be created in your Shopware installation as a property group set. This is to avoid unnecessary interruptions in the migration process due to the mapping of individual properties.
• Check which customer groups need to be migrated and create them in Shopware 4.
• Check which price groups need to be migrated and create in Shopware 4.
• Check which languages need to be migrated and create them in Shopware 4.
• Activate maintenance mode for the shop that you wish to migrate.
• Language subshops must be activated in advance so that they can be mapped later on.

After the migration

• Once the migration is complete, first check to see that the number ranges are continuous and adjust them if necessary.

Starting the migration

Before starting the migration, you should always create a new file and database backup of your Shopware installation. The attributes of your shop will be displayed during the migration process. Each attribute will be return with one of the following messages: Mapping successful (1), Mapping Optional (2) or Mapping urgently required (3).

Step 1: Building links to the shop system

The first step is to select which shop to migrate to (1).

Now create a link to the MySQL database of the new shop. You need to enter a User name (2) and Password (3) for the MySQL server.

Now add the Address (4) and Standard port (5) of the MySQL server. If the databases of the destination server and the Shopware installation are on the same server, enter "localhost". Otherwise, the respective names of the servers should be entered here.

Now enter thePrefix of the database table to be imported (6). If you are using a different prefix in your old shop, you can leave this setting on "default".

Lastly, we can select the Database to migrate to (7). If the access data at the top is properly entered, all of the server tables should now be available and listed here. If no databases are listed, check the previously entered access data for the MySQL server.

At the end of the form, you can find the button labeled Reset current Shopware shop (8). This may be necessary, because the migration plugin does not update or replace exisiting categories or items. If existing categories or items are found, the migration is interrupted with an error message.

Items, item images, customer data, manufacturers, orders and categories will be permanently deleted in this step.

If you do not have the access data of your old shop, you can find it in the administration of your hosting package. Alternatively, there is also the option of contacting your hosting provider directly. If you only have the MySQL dump, import the database into your structure and speak with them locally.

Step 2: Shop migration

After completing the first step, the second now involves importing all important shop settings. By double-clicking in the mapping field, you can open a dropdown field with the settings.

Here you have the possibility of importing attributes/properties, languages, order status, payment types or price groups into your new shop.

The magic mapping supports this step by automatically selecting appropriate Shopware fields for each attribute. This can be used throughout the entire mapping. Each selection can also be changed manually of course.

Keep in mind that when mapping price and customer groups, every group from the source shop can only be mapped once. Mapping multiple times could result in the groups from the source shop being overwritten.

Step 3: Import settings

In the final step of the migration, you are able to choose the desired settings for the migration. When creating a new item, the manufacturer field is required and so a manufacturer must be selected from the list.

In the box "Shop path to item images (e.g., http://domain.de/shop):" specify the path of the old shop.

The "Default manufacturer" field is only relevant for items that have no other manufacturers assigned! You will have the possibility to change the manufacturer once the migration is complete.

If items from the old shop system have been assigned a manufacturer, this information will automatically be carried over to Shopware 4.

Debug mode

The migrations plugin also contains a debug mode. This can be activated in the plugin configuration in the Plugin Manager.

If the debug output is active, all queries will be written to the /files/migration.log in the source database. Here you can find, for example, the recently performed actions and an SQP EXPLAIN for the query that defines how the SQL server processed the query (slow file sorts or fast index access) as well as the duration of the query.

This data is useful for identifying non-optimized queries. You may also refer to the following list of indexes in order to speed speed up queries.

Activating the debug output will negatively affect the performance of the migration script!

Tips for migration

Optimizing the MySQL server

A correct configuration of the MySQL server is required for a decent performance. 

For the purpose of consistency, the data being imported at different locations must be sorted. For instance, doing so will prevent child entities from being imported before parent entities. This is generally the case for all items and prices. If problems are encountered here, additional indexes can be used or the buffer soft of the SQL server can be increased.

The MySQL documentation recommends:

• Increasing sort_buffer_size
• Increasing read_rnd_buffer_size

Optimizing the migrated database

Partial Joins are required for a complete data import. However, in the source database there are no indexes, as these are not automatically imported by the script.

Partial Joins are required for a complete data import, which is possible when the source database contains indexes. Since these are not automatically set by the script, they must be added to the source database.

Create a backup before adding indexes to your source database.

The following is a list of possible additional indexes:

Oxid

Item import:

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

Customer import:

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

Veyton

Item import:

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

Customer import:

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

XTC, Gambio

Importing order details:

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

General tips

After the import, there may be different databases. This is because different shops have different minimum requirements for their respective data.

Here are a few examples:

• Customer evaluations: In Shopware, every item can be evaluated once per customer (tracked by email). If the customer made more than one evaluation in the source shop, the extra evaluations will be lost.
• Customers: In Shopware it is not possible to register multiple times with the same email address (if valid account are used). Duplicate account will not be imported.

OXID eShop bis 4.7.1

• Properties: Prior to migration, create a group into which all item properties will be migrated from Oxid. If no properties are assigned to an item, then properties from the created group will be automatically assigned.
• Properties: In mapping, all existing property options will be displayed. These will only be imported later if at least one item uses the option.
• Delivery addresses: Alternative delivery addresses are not imported. This is valid after migration: billing address = billing address.

Prestashop

• Configurators: For technical reasons the items will be transferred directly into configurators.
• Configurators: Since there are no weight surcharge configurators in Shopware, this data will be lost.
• Configurators: There are no price discount configurators in Shopware. Overcharge < 0 will be ignored.
• Passwords: Passwords can only be migrated, if the salt is entered. For the salt, the variable _COOKIE_KEY_ in der Datei /config/settings.inc.php (1) is used. Copy the salt and enter it into the Passwort Salt (2) field.

If the customers should be able to login with their old passwords after the migration, then the migration tool should not be deinstalled, because the password encoder must remain. After a customer has logged in once, the password is imported and this restriction no longer applies to that customer.

xtModified & xt:Commerce bis 3.04

• Delivery times: Delivery times cannot be imported - they are mapped to the fallback delivery time of Shopware (Configuration > Shopping cart > Item details).
• Configurators: For technical reasons the items will be transferred directly into configurators.
• Configurators: Since there are no weight surcharge configurators in Shopware, this data will be lost.
• Configurators: There are no price discount configurators in Shopware. Overcharge < 0 will be ignored.
• Delivery addresses: Alternative delivery addresses are not imported. This is valid after migration: billing address = billing address.
   

Gambio bis GX 2.0.10

• Delivery times: Delivery times cannot be imported - they are mapped to the fallback delivery time of Shopware (Configuration > Shopping cart > Item details).
• Configurators: For technical reasons the items will be transferred directly into configurators.
• Configurators: Since there are no weight surcharge configurators in Shopware, this data will be lost.
• Configurators: There are no price discount configurators in Shopware. Overcharge < 0 will be ignored.
• Delivery addresses: Alternative delivery addresses are not imported. This is valid after migration: billing address = billing address.

Magento

• Properties: Prior to migration, create a group into which all item properties of Magento will be migrated.
• User-defined properties: These are imported and appear in the attribute mapping. If this should be migrated, appropriate attribute fields must be created in Shopware beforehand.

Veyton

• Properties: Item properties are not imported.
• Delivery addresses: Alternative delivery addresses are not imported. This is valid after migration: billing address = billing address.

WooCommerce

• Paymentmeans: Can not be imported, because the data structure is not compatible. Here the default value "prepayment" is used.
• Manufacturer: Because WooCommerse does not use suppliers the default supplier is used.
• Customer numbers: Because WooCommerce does not use customer numbers Shopware will create individual ones.
• Customer group prices: Because WooCommerce does not provide customer groups you can not import customer group prices.
• Graduated prices: WooCommerse does not support graduated prices so only the first price is imported.

FAQ / common issues

General: items are assigned to the wrong categories

If this is the case, the category tree must be rebuilt in the Shopware performance module.

Per request only 1 data element is migrated

If the migration is only processing 1 element per step you probably have a performance issue on the server. Raise the max_execution_time in the php-settings of your server sigificantly. The read of the elements is very slow and it could occur that the migration plugin has no time left while prepearing the data. In this case the migration plugin imports one order and then calls for a new request.

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

This happens, when too many magento attribute tables will be joined, doe to technical limitations of MySQL the server will crash.

Possible solution: Changing \Shopware_Components_Migration_Profile_Magento::getProductSelect:# With the method getAttributes() the selected attributes will be joined and later be attached to the item query in createTableSelect(). The return value in getAttributes() can be individualized, that only the neede attributes will be loaded.

Alternatively the attributes will be identified by the following criteria:

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') 

If youm, say, set the field "frontend_input" for not needed attributes to "", no attributes should be selected.

XTC/Gambio: Items will be migrated without description

If your items will be migrated without name and description, this is mostly connected with language shops. If your, say, german language shop your main shop, the Migration will think, that Showpare is configured the same. If this was not happened, Migration cannot assign the description to the items and puts them as translation.

Here you have 2 possible solutions:

• Change the main shop to "german", you have to change the main category and the language to german for this.
• Change in your source shops table languages the field sort_order, that the english language has a lower value than the german. Here we recommend to work in a copy of the database or that you made a backup before!

After this adjustment the items should assign correctly.