At the end of 2015 officially issued Magento version 2. The system at first glance attracts with a fresher and more intuitive administrative interface. However, as everyone knows, the appearance is not everything (especially in the case of software).
The new version, unlike the previous one, has been packed with the latest technologies, thanks to which the system caught up with the competition in terms of architecture and, most importantly, increased the scaling capabilities of the platform. As a result, Magento represents an even more business-like approach to sales. These advantages will be particularly appreciated by owners of medium and large companies who are thinking about the future development of an online sales channel or implementation of the omnichannel strategy.
The wide range of omnichannel solutions offered by Magento, designed on the basis of a cloud, allows retailers to effectively integrate online and offline sales channels, providing customers with consistentand smooth shopping experience at every stage of the product life cycle. One of the key elements of omnichannel in Magento 2 is a developed API that facilitates data exchange and integration with other systems that are part of the omnichannel ecosystem of companies.
How to prepare for migration?
Before starting any migration activities, the first and most important step should be to perform comprehensive tests of the old system and an in-depth analysis of data collected by measuring systems such as Google Analytics. They provide information about the actually supported traffic, its growth tendencies and sales peaks. Functional tests, UX audit and real-user test will allow you to reliably check the status of the system before migration. The results of such tests usually set minimum requirements for the new version of the system. In addition, the advantage of conducting tests is an overview of the functionalities that are provided to the customer and re-verification of their validity. Old systems were often equipped with a lot of unnecessary functions, which many sellers nowadays give up thus providing end-users (clients) with a more transparent and intuitive sales platform. When checking the system status, one of the most important aspects affecting incoming traffic – positioning – can not be forgotten. Documenting the store’s position in search results for specific phrases for the most frequently used search engines will be one of the determinants used to check the “quality” of the migration from the SEO perspective. The audit will be valuable information when choosing the right SEO strategy for the new store.
The next step is to create a definition of requirements, ie a document containing an inventory of key functionalities of the old system and a list of functional and non-functional requirements for the new one. Non-functional requirements are nothing more than specifying guidelines on the method and format of the data presented. In this aspect, the knowledge and experience of companies dealing in professionally designing the appearance of websites is often used in line with the brand it presents. In the process of creating such a document, unified terminology is important. The migration process is not fast, and in the case of complex systems it can take several months or even several months. After such a long time nobody remembers exactly what he meant by describing a given component of the system, and using the same terms in different contexts may further complicate the understanding of the initial assumptions. It is worth spending more time on this stage of preparation and rethinking each of the elements contained in the document, because changes in the application coming out at a later stage of implementation usually involve much more modifications than in its initial implementation. Another important aspect, often overlooked in this type of documents, is to take into account exceptional situations, and it is them that most often determine the fullness of a given functionality.
- domain management panel
- server management panel with access via SSH protocol
- used databases
- panels for system monitoring (NewRelic, Google Analytics, etc.)
- administrator access to the store management panel
If these accesses are not collected in advance, this can significantly delay the start of the migration or its subsequent stages.
Migration process
Migration begins with the verification of server resources. The guidelines for the target machines are both the requirements for the assumed traffic, the amount of data, as well as the system requirements of Magento 2. If the current resources do not meet the requirements, it is necessary at this stage to raise the choice of the hosting company or self-modernization. Postponing this at the end causes many problems on the “last straight” implementation, which is why this process should be carried out from the beginning on the target machines. Then the problems related to the reconfiguration of environments or the lack of access to resources / services that were used during the implementation are no longer required. After configuring the new base environment, which will be a determinant of work progress, you should think about its availability. Access from outside is usually required for such an environment. This is dictated by cyclical checking of application status from external networks, and in the case of larger stores – integration tests or synchronization of data from external systems. You can approach this topic in many ways. However, two things are really worth noting: the use of VPN and the use of a temporary domain with limited access. The first approach involves setting up a private virtual network that will allow you to share internal resources – a web server – using a public network. This solution has one major disadvantage: it requires additional configuration of the connection in external systems, which during integration, eg with the payment gate, usually ends in failure. Nobody will do it specifically to increase the number of stores using their solution by one. The second solution, which is connecting a temporary work domain to a web server that will be exposed to the world, does not require additional work from anyone outside. With this solution, it is only required to filter incoming traffic, which can be implemented using the appropriate web server configuration. In this way, you can block access to the environment by means of the required login and password authentication or, most often, restrict access to the website for a specific pool of IP addresses. By limiting access to the development environment, the website is secured not only against prying competition, but above all against robots indexing websites for search engines. Not all comply with the directive saved in the robots.txt file, and often indexing the same content (as in the old system) may reduce its position in the search engines.
Data Synchronization – what to move to the new store?
Migration is the key element of the migration – that is, moving data between the old and the new store. Depending on the level of expansion of the old system, various data are transferred, but most often the following elements are included: products with attributes and photos (ie product information), inventory, prices, product categories, orders, static content (pages with information about company, contact details, website rules), customer accounts with saved addresses, user groups, mailing lists, administrator accounts, promotions used. Considering the migration of the current Magento 2 store, usually these are not small amounts of data, so it is worth investing in the initial phase a little more time and equip yourself with mechanisms that will be able to transfer data automatically. Such an approach will ensure high quality of data in the new system, eliminating human mistakes that often occur with such repetitive work. During the entire migration process, data is transferred at least twice: before the final system check, and during or a short time after commissioning (to complete the missing data). Automating this process will overcome the repeated execution of the same work. At the same time, it will enable more frequent data synchronization, thanks to which you can track the application status on real data (the old system is still alive and its content changes daily). However, it should be remembered that some systems are powered, among others in products by external systems (ERP, PIM). Then all you need to do is to integrate Magento 2 with such a system. Regardless of the data transfer method chosen, the most important differences in the structure of these data are the most important. In addition, fields that were optional in the old system may be required, so you should check these differences at the earliest possible stage and plan how to deal with them. The most common problems are elements such as address data of clients (eg no requirement of the postal code field) and orders that each system stores differently. When migrating users (clients), the most common problem is the transfer of passwords, which each system should store in a secret form, specific to a given system. Therefore, it is worth making it easier (at the same time forcing) clients to change the password at the first attempt to login.
Design and implementation of integration
More extensive stores are integrated with at least one external system. Regardless of whether it is an ERP system, CRM, PIM or an external payment gateway, the company realizing the delivery of goods or loyalty program, such a list should be properly designed in advance and, after implementation, tested. When designing the integration, the most important issue is not to make the store work dependent on external systems. Sales should not be limited by temporarily unresponsive storage servers or those providing descriptions to products, so if it is not necessary, asynchronous integration without real-time data collection is a better solution. Every problem can be solved, sometimes at the expense of larger amounts of data held on the store’s side, sometimes by using an additional form of payment in the event of a break in the payment gateway, however, adhering to the principle “do not depend on what is independent of you” should be one of the most important arguments making decisions in this aspect.
Audit and selection of the right SEO strategy
Another important issue is choosing an appropriate SEO strategy that will minimize the drop in the store’s position. Thanks to the audit carried out in the preparation phase for migration, this process will be significantly improved. The most important thing is servicing all links to the old system indexed by search engines – it usually consists in preparing 301 redirects (permanent redirection) to pages corresponding to the new system, or generalizing if they do not have equivalents, eg if the product does not exist in the new system, redirection should be made to the product’s category page or, ultimately, to the home page. While optimizing the store for SEO, it is worth having appropriate tools to monitor the flow of users on the site and register their behavior for future improvements. Such tools include min. Google Analytics or Google Tag Manager.
The UX audit carried out earlier will allow to develop an appropriate UX strategy for the new system, taking into account the critical places in the store from the customer’s perspective. Although the store after migration will be new, the clients are largely (at least initially) the same. It is worth taking care and remembering that all changes have an evolutionary character. When designing the interface, try to avoid new products that are more discouraging than they will win the clients’ sympathy. Let us also leave the functionalities that have so far enjoyed a positive opinion and assessment of clients.
Security above everything else
During migration, application security is a very important issue. New store views are often the victims of hacker attacks. An unprotected store may expose the seller to significant financial losses. Apart from using the SSL certificate in particularly vulnerable places such as the client’s panel, the ordering process is worth protecting against other data loss possibilities, such as SQL Injection. It is a very good practice to use audits of external companies that specialize in catching security gaps (a fresh and more critical look at the application is crucial in this aspect).
Performance and load tests
Before starting the system, it is crucial to check its performance and optimize it if required. Performance and load tests to be more reliable and comparable to the previously collected data should be carried out as described earlier. In principle, the new system should be created in the future, so during tests it should be subjected to an attempt to operate with a load approximately 3 times greater than that appearing in the peak of sales of the old store. An important issue when conducting tests is their proper course. Testing immediately on full load will not provide useful information, so it should start with a low load and gradually increase, thus setting the upper limit for which the system is able to sell continuously. If the store migration also assumes changing the target server for the application, it is worth remembering to change the TTL parameter (time-to-live) for the domain’s DNS records for about 300 seconds. Such a change will cause that at the time of the final change of DNS addresses information about it will spread much faster around the world, shortening this time even up to five minutes. Domain DNS records determine which server the domain leads to, so information about changing these addresses stretched in time will cause that some users entering the store will get Magento 2, while those to whom such information has not yet arrived will continue to use the old version. This behavior is also the reason why the “old” servers and the store should function for some time after launching Magento 2 on new machines.
The right moment for starting the production version of the store
The last issue is to choose the right time for the production launch of the new store. For this purpose, it is worth using the tools used to analyze traffic in the old system, which will allow you to find the day and time of the week with the least amount of visits. Thanks to this process will be able to proceed more calmly and accurately. Even if at the chosen time the systems indicate zero traffic on the website, it is important to have a static website prepared with information about the reason for the break in the store’s operation. This blank will prevent potential customers from revealing potential errors, and the information will not discourage them from returning to the store’s website.
