The following article is based on the presentation delivered by Stephen Leyton, Managing Director, and Duncan Ball, Senior Project Manager at The Pixel, at November’s event Magento Lunch & Learn, and offers a step-by-step breakdown on how the company approaches a Magento 2 migration.
What does Magento 2 offer?
There are significant changes around the front-end of Magento 2, with major refactoring using modern technologies and methods for a better user experience and performance, allowing for improved upgradability, compatibility, and scalability.
The platform has been designed from the ground up, adopting a mobile first approach, allowing easier development for multiple devices, more focus on performance and accessibility. Even the admin panel is fully responsive.
One of the biggest complaints we hear from our clients is the time, effort and cost spent on upgrading Magento 1. This is one of the areas that Magento addressed with M2 – the upgrade process is now more efficient than ever. Magento are aiming to launch quarterly feature releases.
The entire architecture has been re-written to enhance the product, improve the integration compatibility, which ensures extensions do not cause conflicts and impede performance further down the line. As long as developers adhere to best practice, you will be able to maintain a clean path for future upgrades.
M2 vs. M1: Scalability
Magento 1 is a single application on a single database. This is where M2 differs, with M2 you have the ability to segment the application into four stand-alone components consisting of three master databases which in turn can be balanced across multiple slave databases.
Take the admin component where most merchandising is performed. This will push data into your catalog component which can sit on a separate infrastructure, consuming its own resources, and can be scaled to suit your users’ needs. Merchants can then use the checkout component, which again, can be on its own dedicated infrastructure designed for quick through-put, high concurrency, and transactional safety.
What does this mean in real terms? Let’s say a merchant has restricted stock of a very popular product which is in high demand. There’s huge amounts of traffic going to that single product page because this merchant is one of the very few stores that holds that product in the UK. This scenario would almost certainly diminish the website’s performance, and would therefore likely hit conversion rates. But M2 allows greater control over specific needs. So in this example, the option to scale the catalog component of the application more appropriately, allowing the checkout to be unaffected would be available, providing optimal performance of the website despite the heavy traffic.
M2 vs. M1: Performance
This architectural change enables a heavy increase in the throughput capability of M2.
Using a standard out-of-the-box installation:
This brings us onto the new two-step checkout. With M1 there has been countless one page checkout extensions over the years, and many have made the checkout process worse and more complicated to integrate.
So instead, M2 re-imagines the process making it user-friendly and efficient. The checkout process has been streamlined and reduced from five steps down to two, to help increase conversions.
In the development of M2, Magento split tested 50 variants, and this new checkout performed with the highest conversion rate. As we know developing a new checkout is a costly exercise to get right. Thankfully M2 does this for you.
Do I need to migrate?
Technically there is no reason why you can’t continue to use M1 indefinitely, but as time goes on it will become increasingly difficult to support the platform, and with Magento themselves declaring a cut-off date for the end of 2018 you will see a lot of agencies and extension vendors following suit.
Points to consider:
This trend will likely keep growing, and as with all software and technology there is only a finite lifespan to any version. That’s why it is important to seize the opportunity that M2 brings, with the latest technology and features available, conforming to more demanding standards.
Can I reuse any of my existing website?
All the knowledge and learning that you have built up over the many years on M1 is still valuable and better than any specification you could possibly write.
If you have a modern responsive design, this can be refactored into a new M2 theme, rather than having to initiate the entire design process again. If however your design is looking tired, now would be a perfect opportunity to review it.
The vendors have a vested interest in delivering compatible extensions for their current customers – it would be a costly missed opportunity if they didn’t, and we have already seen a big push from the main developers to deliver this (including Dotmailer and Nosto).
The amount of time and effort required will likely depend on the number of customisations to the frontend and backend. This will dictate the level of functionality that needs to be refactored.
As will the number of third party extensions. These will need to be reviewed to see if the provider has a M2 version, and if not, an alternative will need to be found, or the functionality will need to be rewritten.
The complexity and size of the data will likely cause the biggest headaches, so it’s essential this is looked into at the very early stages. There are ways to minimise the time it will take to migrate to M2, and we would encourage a full review of the current M1 system to see what features will bring the best ROI.
The migration to M2 is not just an upgrade – it’s a real opportunity to look at cleansing the data, re-evaluating functionality, remove redundancy, code, or any other aspects of the website that are not critical to the business.
What is involved in a Magento 2 migration?
The migration path consists of 4 processes:
1. Data Migration
For the data migration, Magento have created a flexible data migration tool to assist with migrating these key data sets from M1 to M2. At its core, the tool is a command line tool that connects to a database that’s configured to hold M1 data. This performs what is called an ETL process over to M2 – Extract, Transform, and Load.
It performs 3 main functions:
Settings Migration – these are the settings within Admin>System>Configuration.
Data Migration – This is the heavy lifting part, and comprises all the data that’s needed to take from M1 to M2.
Delta Migration – A most beneficial tool – once the initial data migration is complete, waiting for all that data to transfer over while you’re offline is unnecessary. The delta migration bridges the gap between the last data import and any new information that has come across. This allows merchants to take M1 data and perform the initial import ahead of time. When you’re ready to migrate over to M2, the delta migration will take any new orders, or customers, or product updates since the tool was last run. (This avoids hours of offline time – sites will only be down for the duration of the last delta portion instead of a full data import.)
Steps for the initial import
Before running the initial data migration tool, what data to migrate needs to be decided upon. Should we bring all of the data or just parts of the data? If just parts, which parts? Will this be based on creation date? Based on status of the product, customer or order? Should we clean the data at source or at destination? These are just some of the questions that need to be agreed before triggering the initial migration steps.
What happens next?
The next step in the process is the simplest – the running of the data migration tool for the first time. This will, as expected, provide a plethora of errors on the screen, which in turn will be our starting point.
To give you a clearer picture of what’s happening, the migration tool runs and compares the whole database from source and destination, and if there are any discrepancies it will be flagged and the import aborted.
Every single table and column needs to be mapped in order for the initial data migration tool to run successfully, so it will have to be decided whether to ignore it, transform it, or rename it.
Typical failures are:
The whole process is a case of fixing these failures, and running the process again, and again and again, until fully successful.
Now if this all sounds like a lot of hard work and hassle, the good news is the data migration tool is very quick to run.
It’s also worth mentioning that the same tool can be used to migrate custom data. Many merchants have specific customisations with additional data (not just orders and customers etc) which can also be migrated using the tool.
Magento has launched a brand new marketplace specifically for M2. Many of the most popular M1 extensions that merchants are using today are likely to have already been redeveloped for the M2 platform.
Magento are actively reaching out to vendors to ensure they update their extensions to the M2 format. This process will naturally take some time, and unfortunately it is likely that some of the less popular extensions may not be carried over. This does however present the opportunity to move over to extensions that are better supported in the future.
Magento themselves are taking ownership of the quality of extensions by vetting the codebase before it reaches the market.
Themes and Customisations
Like extensions, current M1 themes will not work in M2. All the code will need to be refactored and rewritten from scratch.
ERP integrations will also need to be re-evaluated for M2 (this is a process The Pixel have already begun with our ERP connector).
Delivering a Magento 2 Site: Phases
Broken down into five steps:
1. The mapping out of an existing inventory of extensions, web services, and integrations.
2. Checking for upgraded M2 extensions in Magento Marketplace – if they don’t exist, alternatives need to be found, or functionality will need to be built bespoke.
3. Evaluate the order management process to make sure it’s compatible with M2.
4. Determine if the migration tool covers all data migration needs.
5. As an optional step, a UX session can be conducted to understand what is working and what is not on the current site, based on user testing.
1. Everything learnt in the discovery step is used to identify the risk areas, the bottlenecks, and a timeline is determined.
2. A ‘Go Live’ strategy is determined.
The design, the themes, the back-end integration, the data migration, the end-to-end testing – once all complete, we’re in position to launch.
The whole process is a bit like moving house; you have to do your research, you have to carefully consider your options, you have to make decisions on what you’re keeping and what you’re taking to the tip. You have to make sure all systems are in-line and ready for the day of completion. It will be a mixed bag of emotions, but it will be worth the effort. At the end you’ll have a bigger home in a safer area, and you’ll have somewhere to call home for the foreseeable future.