Moving from Shopware 5 to Shopware 6 may pose a challenge, but with proper planning and execution, it can be accomplished seamlessly. Here are some helpful tips to simplify the process:
Important tables for error analysis
Apart from the extensive log files, there are additional database tables that contain records of errors and error notes during the migration process. For example, the table named “swag_migration_logging” enables you to apply filters to the errors, either based on their levels or the particular entity encountering problems.
Other tables in the database:
- swag_migration_mapping
- swag_migration_media_file
- swag_migration_data
Suggestion: Migrating extensive volumes of data using the console
If you have a lot of data in your source storage or if you want to migrate it without interrupting your work, we suggest using the console (CLI) to do the migration. Once you’ve completed the “Data check” step, you can start the migration using the CLI.
To follow the necessary steps, begin by initiating the migration through the administration interface as usual. However, after reaching the “Data check” stage, you should cancel the migration. Next, access the console and locate the main directory of the destination storage. At this point, ensure that you are positioned above the public folder.
Please execute the following command:
php bin/console migration:migrate [Argument]
The Argument variable can take on the following values:
- basicSettings: Includes basic settings and categories (SalesChannel attachment, etc.). It will be automatically executed when importing other DataSelections.
- cms: Involves layouts.
- customersOrders: Includes all customers, orders, and documents.
- media: Covers all media and folders.
- newsletterRecipient: Deals with newsletter recipients.
- products: Involves all product data and associated entities. It also includes associated entities from “media”.
- productReviews: Includes product reviews.
- promotions: Covers discounts and promotions.
- seoUrls: Involves SEO URLs.
- customerWishlists: Includes watch lists for customers.
Accelerate migration for huge data volumes using a local database.
When dealing with extensive data volumes, it can be beneficial to migrate directly through a locally situated database. This approach helps distribute the load across multiple systems, resulting in improved efficiency. However, when dealing with a large number of records, especially variants, the migration process may require a significant amount of time.
During the migration, not only is the information read out, but it is also prepared for the subsequent writing process. While the migration wizard aims to facilitate a seamless migration experience, handling such vast amounts of data is challenging and not the primary focus of the extension. Therefore, in such exceptional cases, some additional adjustments may be necessary.
Whether the migration should be done locally or via the API/store domain can be determined within the migration wizard by editing the connection settings.
Error Message: “Unable to establish a connection”
If, for instance, there was an error in inputting the store domain or API key, you might encounter the following error message. In case you have verified the domain and API key’s accuracy, the issue may have stemmed from using an outdated version of the migration extension. Therefore, it is recommended to examine the extension’s version and proceed with the available update.
- Complete error message:
- No connection was established.
- No connection could be established to the specified server. Please check the specified store domain.
Indexing
An index that is not fully constructed can result in migration to get “stuck.” Indications of incomplete indexing may manifest through the following notifications, all of which suggest that the indexing process is still ongoing:
Circa 1395350 products remaining …
Approximately 1400 categories remaining …
[…]
To achieve complete indexing, it is necessary to ensure the following:
- Sufficient server resources are available, including a sufficiently high memory limit (of at least 2GB).
- The server should terminate no long-running processes.
- The message queue needs to be reset:
The message queue can be reset by following these steps:
- dead_message
- CREATE TABLE backup_dead_message LIKE dead_message;
- INSERT INTO backup_dead_message SELECT * FROM dead_message;
- DELETE FROM dead_message;
- enqueue
- CREATE TABLE backup_enqueue LIKE enqueue;
- INSERT INTO backup_enqueue SELECT * FROM enqueue;
- DELETE FROM enqueue;
- messsage_queue_stats
- CREATE TABLE backup_message_queue_stats LIKE message_queue_stats;
- INSERT INTO backup_message_queue_stats SELECT * FROM message_queue_stats;
- DELETE FROM message_queue_stats;
- messsage_queue_stats
- CREATE TABLE backup_increment LIKE increment;
- INSERT INTO backup_increment SELECT * FROM increment;
- DELETE FROM increment;
Afterward, it is important to ensure that the message queue is processed using the Command-Line Interface (CLI):
To initiate reindexing via the message queue, you can trigger it using the following CLI command:
bin/console dal:refresh:index –use-queue
The indexing process is carried out through the message queue, and it may take several hours to complete. Once the indexing is finished, it is recommended to clear the cache via FTP by deleting all subfolders from the “/var/cache/*” directory. This step ensures that the cache is refreshed and any outdated or irrelevant data is removed.
Moving previously migrated articles once more.
If the migration has been previously executed, for instance, for testing purposes, the Shopware installation retains the information about the articles that have already been transferred. Each read data is assigned a checksum, which is utilized to verify if the data has already been migrated during subsequent migrations. This mechanism prevents data from being migrated twice, potentially leading to overwriting conflicts.
To generate the mentioned checksum, Shopware establishes a new table called “swag_migration_mapping” Resetting the checksum and performing additional migrations without resetting it can be repeated as necessary. This process is facilitated through the migration extension, and further instructions can be found in the following article:
Within the “swag_migration_mapping” table, it is also possible to manually delete specific data entries. This allows for the selective re-transfer of certain entities. For instance, to migrate the newsletter recipients again, you can execute the following SQL command. Please note that the entity can be adjusted accordingly:
UPDATE swag_migration_mapping
SET checksum = null
WHERE entity = “newsletter_recipient”
Please contact us at manish@bay20.com or call us at +91-8800519180 for any support related to shopware. You can also visit the Shopware 6 development page to check the services we offer.
