How to migrate to Shopware 6 from other platforms

Care to share?

Migrating your online business to a new eCommerce platform can be easy. You simply need to choose a  solution with the functionalities that will achieve your business goals. Shopware 6 is a future-oriented eCommerce platform, offering you a whole toolset for safe migration. As a result, you can break away from outdated technology and migrate your online business to a powerful, scalable, modern e-commerce solution, whether you are active in B2C or B2B. 

Migration to Shopware set up. How to prepare? 

Shopware migration itself is not difficult, as long as we prepare for it well. In the migration process, the most important thing is strategy and proper planning. 

When to make the Shopware migration?

Theoretically, Shopware migration can be done at any time… though some are better than others. Analyze when traffic and sales on the platform are the lowest so that you don’t migrate during or just before a peak. It’s better to avoid events, such as holidays or sales, during which traffic is multiplied and generates the highest profit in the store. In this way, we minimize the risk of losses in case of possible failure and give users time to familiarize themselves with the new system.

If you are still on Magento 1, you should be aware by now that Magento 1 is no longer supported and you have no more time to make migration decisions.

What is the best strategy?

We have some general scenarios for migrating. The choice of strategy depends on the client’s needs and the situation.

1. Big Bang

In a Big Bang data migration method, you move an entire dataset from the legacy to the target system in one operation.

In this approach, you need a window of time where the business can shut down. The migration is typically done over a single day. On Friday morning we turn off the old system, and in the evening users enter a completely new platform. Due to the simplicity of the solution, it is the fastest way to migrate an online store. 

This method is only suitable for businesses that don’t require their systems to be online 24/7. There is also only a limited time window for making changes, which can be risky for the business if something goes wrong.

2. Trickle / Incremental Cutover

Such a strategy reduces the risk we face with a Big Bang approach. We only migrate discrete parts of the business and associated data. If you hit problems, it is much easier to go back to a smaller subset of data than an entire data store using a Big Bang approach.

In the IT industry, any strategy that can reduce risk is an attractive path to follow. Still, this approach is not without its drawbacks. Many businesses and applications are complex, so it’s not easy to effectively execute, which is why this strategy is rarely used.

3. Parallel Migrations

A Parallel Migration is more expensive than other options; on the other hand, it can significantly reduce the risk of migration. In this strategy, the new system is installed alongside the old one. They both operate during the transition. Data between systems is synchronized using, for example, “data pumps”. Updates are posted to both systems until the migration is complete. 

Parallel Migration has many advantages: the existing production is not disrupted, you can adequately deal with migration issues before the target system takes over, and it is the least risky migration strategy. 

The Parallel Migration strategy is often used in the Strangler Pattern approach when we want to get rid of the legacy system. We clean up the legacy system module-by-module by replacing them with new services or microservices. Combining this solution with a headless frontend approach is a strategy worth exploring.

4. Incidental Migration

Incidental Migration means that we don’t migrate all data at once. The order history is a good example: instead of migrating all the customer’s orders at once, you can just show the customer that you can download this data at their request. The customer’s order history will only be downloaded if he or she wants to see it. The new system asks the old system and downloads it on an occasional basis. Such a solution is particularly beneficial in large systems where we do not want to clog up the new system with old and unnecessary data. 

Functionality records on the current system

Before migration, we need to prepare a detailed list of the functionalities of the current eCommerce system. Go through all the features to determine which of them are required on the new platform. Check which ones require data migration and which ones will not be needed because customers or platform employees do not use them. Mark the functionalities that will probably require an individual approach to data migration. 

“One of our customers deliberately decided not to move their wishlist function from the old system to the new one. The wishlist is just a list of products; in this case, books that everyone wants to buy or read in the future. As it turned out, some customers created such lists of books to read throughout their lives. With time, they would mark those they had already bought and read. After the platform migrated to the new system, the customers were very upset that they lost their lists. We then had to migrate the data and enable this functionality but some customers already felt offended.” 

Bartosz Picho, eCommerce Solution Architect at Divante.

There are similar things which are often forgotten or overlooked and which we have to be aware of during migration:

  1. Marketing and consent agreements
  2. GDPR
  3. Newsletter subscribers
  4. Voucher codes
  5. Shopping carts

As you can see, all areas need to be looked at in detail to make the migration a success. The records should be made to choose the correct version of Shopware.

Verification of available modules for requirements

Verify that the Shopware 6 standard meets your functional requirements. Check whether a module for Shopware 6 is available on the marketplace.

If it is not available, look for a module on Shopware 5 and contact your supplier to ask if they are planning to upgrade to a newer version. If the search shows that there is no such module available, ask the agency to make this functionality for you.

Defining non-functional requirements: scalability, performance, and data volume

When we migrate from one system to another, we must not forget that the old system handled traffic at some performance and data level. The system we are migrating to has to, at least, achieve these numbers. Even if we do not decide to change our hosting during the migration, a change of platform can significantly change the way and intensity of infrastructure utilization. That’s why it is to define these numbers as non-functional requirements, which have to be measured and achieved by the new platform:

– Average number of page views / visits per month and in sales peaks

– Number of orders per day (average and peak)

– Number of unique sessions (average and peak

– Data volume (products, orders, customers) and static content size (media, downloadable).

Before launching a new platform, we always need to perform performance and overload tests to verify that the new solution is able to operate effectively under the load we have identified ourselves. 

Integration records and verification of dependent systems

Before migration, it is necessary to consider and verify whether our old system is integrated with external systems or whether external systems are integrated with our platform. If we replace the old system with a new one, it turns out that some external system will stop working and we will lose some functionality. This can lead to serious difficulties. What applications do you have and do they rely on each other?

“Temporary solutions often become permanent problems”

Craig Bruce

In systems maintained for many years, there are numerous specialists and countless technical decisions are made, many of which have not been documented properly or at all. There are also temporary quick solutions or workarounds which very often stay with us forever. Therefore, before starting the migration, it is very important to know and systemize the knowledge about our system to not be surprised after the migration that, for example, some external system has lost communication with us. Technical audits can help you discover all areas and document them properly.

Migration of UX and UI

At the beginning, you need to consider and choose whether the visual layer is to be on the native Shopware or you want to use the headless PWA version. When we choose the type of technology, we go on to the second level. 

During migration, a redesign of the site is often planned. This task can be approached in at least two ways. You can plan a great design, without looking at technology, and then try to implement it into an existing platform. Such a solution, though possible, is very time consuming, complicated, and expensive. 

If you want a fast and cost-effective solution, you should make appropriate use of the possibilities and limitations of the system on which you will implement the eCommerce platform. Plan the work on UX and UI on the new platform to take advantage of its strongest points and eliminate its limitations

For example, PWA Storefront in Shopware is based on predefined Storefront UI components. These can be adjusted to your needs and your company CI, giving your platform a new, fresh look. Make sure the creative agency you work with knows the platform. Provide them with reliable support from the platform’s technology partner if needed. 

If there are any unusual solutions which are necessary due to the characteristics of the business, consider how to implement them in accordance with the platform. This solution allows us to achieve excellent results at much lower costs and in a shorter time. 

“We usually recommend the solution. We focus on getting the most out of the platform but also consider what else we can improve on the platform to suit individual needs, rather than doing the design in isolation from the platform. This approach has never let us down”

Bartosz Picho, eCommerce Solution Architect at Divante. 

Before Shopware migration: always have a backup plan

Regardless of which implementation method you follow, there are some best practices to keep in mind. 

Before migration, you have to do tests, tests, and more tests. It is worth making a test lunch e.g., inside the organization, set up accounts for a closed group of company employees who will work on this platform for a few days. Ask them to place sample orders to make sure that everything works well. 

Back up the data before executing your Shopware migration. Prepare a plan to retreat and return to the previous situation. Write down in specific steps what to do in case of a breakdown. You can’t afford to lose data. Make sure there are backup resources and that they’ve been tested before you proceed.

After migration: monitor and analyze

After the migration, it is essential to monitor the new system. Check for errors on the side of the browser, server, and service providers. SEO is also a critical element but this is a topic for a separate article and is usually dealt with by an independent agency that prepares an SEO strategy for the migration. It is essential to check if the new platform does not lose out drastically on organic traffic. A proper migration should be done in such a way that there is no loss of traffic. 

Tools to monitor your eCommerce platform:

  1. NewRelic is used to monitor on different levels (frontend, backend, infrastructure)
  2. AppDynamics
  3. Elastic Stack with APM from Elastic
  4. Zabbix to monitor infrastructure
  5. Google Analytics, HotJar

How to migrate to Shopware

How does Shopware help make the right migration? Is it possible to migrate data from my platform automatically?

Shopware 6 has a very flexible module to migrate from different eCommerce systems, even dedicated to Shopware. Using the ability to create and customize profiles, we can migrate any system.

Migration Assistant capabilities:

  1. Shopware 6 currently has three out-of-the-box profiles for 
    – Shopware 5
    – Magento 1
    – Magento 2
  2. Migration Assistant allows you to select the range of data you want to migrate. We can choose which elements to move, e.g. we do not need to migrate all media. 

3. Progress bar for migration progress.

4. Data check after migration.

5. Possibility to create your own migration profiles and the ability to expand profiles and custom elements for migration.

6. Possibility of making a delta migration, which supports a Big Bang strategy to reduce downtime.

Magento Shopware Migration Assistant, due to its functionality, provides tools to carry out a comprehensive migration in a fast and secure way using the good practices and strategies shown in this document. In this way, the whole process is safe and timely. 

Migration to Shopware from Magento 

Shopware 6 has an out-of-the-box available data migrator for Magento, which supports the migration of the following data:

  • Languages
  • Customer groups
  • Categories
  • Countries
  • Currencies
  • Shop structure (store views, etc.)
  • Customers
  • Orders
  • Media Mechanism allows the migration of assets such as photos, media, and documents
  • Manufacturer / supplier
  • Property groups
  • Products and variants
  • Product reviews
  • Passwords – your customers’ passwords are also automatically migrated to Shopware and they can log on to the new platform using the same login and password
  • URLs are also migrated and can be identical to those in Magento

Migration to Shopware from WooCommerce, PrestaShop, Shopify, and OpenCart 

There isn’t any ready plugin for WooCommerce, PrestaShop, Shopify, or OpenCart to Shopware migrations. You need to create a new migration profile in the Migration Assistant. More ready plugins for other platforms will be available soon. Creating such a profile is not difficult. We recommend asking your IT partner about the possibility and cost of preparing a dedicated profile.

The wrap up

Migrations are not usually pleasant because they are not appropriately planned and there are no tools for proper migration. They are often linked with stress, mistakes, problems, delays, lost traffic, and sometimes even a drop in revenue. Fortunately, the process of migration to Shopware is completely different.

Shopware migration is much simpler, faster, cheaper, and more enjoyable. With proper planning and preparation, and with the help of the tools from Shopware described in this article, the difficult migration process can be done successfully and without a great deal of stress. What’s more, your eCommerce will start to generate more profit instead of making up for the loss of traffic on Google. 

Sounds reasonable? Drop us a message and let us help you.

Published July 3, 2020