Justin Biddle looks back on years of experience in the digital sector. As an expert, founder, consultant and Shopware evangelist, he makes a statement in this blog post about the risks of re-platforming and explains how to deal with them using the right tools.
If you are looking at Shopware as a new home for your Magento website, then Shopware has created a migration tool that makes getting your data across from the old Magento site to a Shopware site nice and easy – and hence takes away one of the big risks of re-platforming.
Setting the Magento 1 ‘End of Life’ scene
If you are reading this, then it is likely that you are still on the Magento 1 platform, and no doubt you are a little concerned at the flurry of alarming pronouncements from the likes of Adobe, the payments industry and a range of competing platforms out there all vying your business. I am going to level with you here – I would love it if you re-platformed to Shopware – but only if it is the best platform for your business – which for many of you it will be. So, to start with, let’s have a look at what the real issues are at present.
Adobe looks unlikely to extend the end of life date. But why? Because I think the truth is that if you haven’t moved by now then you probably are not an “Enterprise” customer, and as a result they are not that interested in your business. You are likely to go on their open source platform and that makes them little in the way of revenue.
Agencies supporting Magento and competing platforms are keen to generate business, so it is in their interest to keep the “Fear” marketing going. They are well aware that this represents a fantastic opportunity to re-platform approximately 25% of SME/Mid-Market retailers in a short space of time. For competing platforms this represents an opportunity to pry merchants away from Magento.
This is only exacerbated by the payments industry, which is always paranoid by nature. Many providers and bodies are threatening that PCI compliance will not be possible after the ‘End of Life’ date because of the lack of security patches from Magento. They are conveniently overlooking all the platforms and proprietary applications that integrate to their services via SDK/API and which they are quite happy to provide services to. They also overlook the companies that are prepared to offer patches after end of life (such as MageOne) and the community itself, which has always done a great job in keeping Magento safe.
In the absence of the marketing hype that is swirling around, what would my advice be to merchants faced with Magento ‘End of Life’? It would undoubtably be the following:
- Don’t re-platform unless there is a clear business case that requires it (this can be read at ‘Managing Risk’).
- Don’t make Knee-Jerk reactions – ensure your project is properly scoped, and most importantly that the risks of re-platforming are understood and, where possible, mitigated.
- Don’t put flashy ecommerce frontends in front of what is fundamental to your business – operation process. Ensure you start with your core business management systems and work forwards to your ecommerce platform (and any other sales channels that you use).
- Remember that the two biggest areas of risk revolve around migrating data and building robust integrations.
So, if you are set on re-platforming – How do you manage risk?
- Give yourself the time you need – Services like Mage One can ensure necessary, you can change your payment gateway to one that recognises Mage One – that represents a much smaller risk than rushing a re-platforming project.
- Given that data migration is one of the key risk areas you should ensure that your destination platform has good tools for migrating data from Magento 1. Magento themselves have tools for this (though they will only support these tools if the merchant commits to a 42-month contract), as does Shopware.
What are the risk areas?
A big risk area in any re-platforming project: How you get data from one platform to the other? This risk includes the following:
This includes not only the basic data (normally stores in Product Attributes or Properties), but also the ways in which products are combined into bundles and parent/child or configurable products.
There are two main issues with customer imports:
The first is around passwords. These are often hashed, as is best practice. This makes it especially difficult to import them into a new platform, and often means that existing customers need to create new passwords when they log in to the new platform – creating a barrier to conversion.
The second area of issue is around data validation. Different platforms validate information in different ways – and the one thing you want to avoid is saved addresses causing checkout issues for existing customers.
Orders represent a specific challenge as, unlike customers and products, they are a construct of various other entities. Every order has a customer, a number of products, a shipping method, a payment, a shipping note that are all interdependent. This can cause an issue when bringing orders across to a new platform – what happens if one of the underlying entities is missing?
One of the biggest problems for agencies doing data migration on a build is, that they often do not understand the product set nearly as well as the retailer, and as such they need their assistance. If there is one truism that applies in any site build project, it is that merchants ALWAYS underestimate how much work they have to do to deliver a successful project.
The problem of how to synchronize data between systems on an ongoing basis is the second big risk area. Whether it be payment systems, order management platforms or CRM tools, the risk levels are high because of the complexity that is often involved and the knock on effects on operational efficiency should these integrations not function correctly. These risks can be partly mitigated by using pre-built integration or middleware integration platforms, but risk still resides, as these products normally only cover off the major use cases and data structures. The essential problem is, that platforms and businesses often use features and data constructs differently to the way they were conceived.
Magento/Shopware specific migration tool – to reduce migration risk
As a lot of customers coming to Shopware are coming from the Magento platforms, the Shopware team have built a set of tools to ensure that one of the essential risk areas, that of Data Migration, is mitigated. These tools are available for free (and therefore for all open source builds), but if support is necessary for these tools one of the commercial licenses is required. These migration import profiles were created in collaboration with a number of our partners with expertise in both platforms.
Getting to grips with the Migration Tool
There is lots of help available to help customers use these tools easily and efficiently:
- To the Shopware Documentation
- To github (which lists the fields supported in the migration profile)
- There is also a webinar delivered in conjunction with our partners MageOne
What does the tool migrate?
The following data is migrated automatically:
- Products and variants
- Customers (including passwords, so that customers can keep old passwords)
- Product attributes (or properties, as they are known as in Shopware)
- Product reviews
- Shop structure (websites, store views are migrated into Shopware Sales Channels)
- Customer groups
- Categories and category structure
- Newsletter subscribers
- Media (including product images and content images)
- SEO URLs (to minimise 301 mapping errors)
What does it not migrate?
The tool can’t import everything automatically, and for the following items there needs to be a little bit of configuration to get the relevant data across properly:
- Shipping Methods
- Payment Methods
- Tax rates
- Newsletter status
For these items you have a mapping interface, so that you can provide a Shopware entity for each of the rates/methods that you have in Magento, and then these mappings are applied as if part of the migration.
CMS pages and static blocks are not migrated – and these have to be redesigned in the Shopware platform, but the Shopware Shopping Experiences makes this relatively easy – and the images will have already been migrated. Documents (invoices and shipping notes) are not taken over either as these are created on the fly in Magento, but are stored entities in Shopware.
Managing a migration project
Once you have installed the assistant in your Shopware Instance, and the Magento profile, you can open the tool in the Settings area of your Shopware Administration. You will need to add a connection to your Magento database, but there are step by step instructions for this in the Admin interface.
Once you have a connection configured, you go to the Data selection and define what you want to take across. Then you start the migration. This should bring up the mapping interface that allows you to define standard mappings for things like payment methods and shipping methods (as discussed above). From here, the migration process can start.
You can repeat the migration as often as you like. On the first migration all migrated data is assigned a checksum. Based on this checksum, the migration wizard recognises whether data needs to be migrated or not. This prevents data from being migrated twice and possibly overwritten. It also allows you to re-run imports safely if any of the data has been updated (for instance prices, stock levels) and just apply updated data. This is essential for ensuring that the data is up to date just before you go live.
This tool has also been tested at scale – it has been tested with hundreds of thousands of products and millions of customers and orders without issue.
Other platforms & extending the tool
The Migration Assistant is also a flexible tool that can be used to create other import profiles, so that you can connect it to other platforms to perform an import – that might be another ecommerce platform (for instance we have a WooCommerce profile in development at present) or it may be something like a Product Information Management (PIM) platform. Watch this space for new profiles!
Shopware’s data migration tools do not only manage to vastly reduce the difficulties in getting site data across from Magento, but also provide a framework for building migration and integration tools from any other platforms. They are built with flexibility in mind, and Shopware’s vibrant developer community is adept at using these tools to create new and exciting innovation.
Get to know more about this
Whether it's a migration video, case studies or whitepaper – we've summarised a lot of useful information about the migration from Magento to Shopware for you here: