Some time ago I wrote about migrating from PHP 5.6 to PHP 7.0. But what about migrating to Magento 2? Is it something easy to do? How long will it take? Where should we start and what should we think of before performing a migration? Eventually, what tools should we use? I will try to answer these questions.
Migration or Upgrade?
Why are we talking about a migration? Why isn’t it an upgrade? On the one hand, Magento 2 is some kind of ported Magento 1. But on the other hand, authors make a lot of changes in the code – both in the database and files structure. We have new coding standards and the syntax of XML layout files is also different. In this situation, we cannot talk about an upgrade. It is necessary to build a new store and then migrate the database.
How long will it take? / How much will it cost?
E-commerce is always about custom. We can divide the whole process into a few steps:
- Build new frontend
- Look into third party modules
- Rewrite custom functionalities
- Migrate data from the database (continuous migration)
- Launch / switch to a new store
As for frontend, you can rewrite the old one or implement new designs. All custom functionalities could be copied, but needs to be refactored. Migrating the database is actually the simplest task in the process (there are some useful tools for that).
When it comes to estimating time and costs, it depends on the actual store. In most cases it takes from two to six months, but you should contact a developer with more details on your Magento installation, so that he can advise accordingly. Migration is a complex process and should be taken care off with caution and attention to detail.
Should I upgrade business logic or storefront while migrating?
Rewriting the store sounds like a good occasion to upgrade/refresh business logic, to create brand new frontend, or refresh the design. It might be, but it needs to be done with wisdom and you need to be aware of the risk. Migration itself is a huge task with a lot of traps and unknowns. If we add new logic which is behind the store, it means there will be one more variable in the equation. Be careful with that. If it’s about simplifying code or fixing frontend issues, I would definitely respond ‘yes’ to that. In other scenarios you need a good analysis.
As we agreed, the process is complex and could take a fair amount of time. It will be good to simplify it as much as we can. Perform only absolutely necessary changes. Maybe there are some services you can extract from Magento 1 before actual migration? Maybe you can migrate only a part of the store and postpone migrating the rest? These are very important questions you need to answer before starting the migration in order to simplify the process.
How to prepare for migration?
First of all: plan the whole process precisely. Specify deadlines for each step and carefully mark potential problems. Second, think about the destination environment. Consider a better dedicated server and specify which PHP and database versions you will use. Next, plan the theme and module structure.
How to start and perform the migration?
Start with a fresh Magento 2 installation. Then create a new theme (you can inherit from Luma Theme, but most probably you want to inherit from a blank theme with only basic styles and scripts). If the design remains the same, then you can use a lot of files, styles and scripts from your old store. You can copy them, refactor and use in new templates and views.
Custom functionalities and third party modules
This could be the hardest part. When it comes to custom functionalities, you need to rewrite them for new Magento. It is possible to copy the old code and port it to Magento 2, but in most cases it will be problematic. Remember not to edit the core code and keep your custom functionalities in the module structure (try to separate them from the theme).
There is another option for migrating custom code. You can use a tool developed by Magento (it can be found on Github: https://github.com/magento/code-migration). There is no guarantee this tool will work properly, but it could be a good starting point. We will write a separate blog post about that tool and migrating custom code, so stay tuned.
It is obvious that custom code has to be rewritten. But what can we do with third party modules? It’s been a while since Magento 2 release. Therefore, the first step could be to look if the same vendor offers a similar module for Magento 2. Maybe it will fit the requirements and work with your store. It could be a good solution, but please be careful here. The same vendor and name of the module don’t mean the module will work the same way.
What can we do if there is no equivalent module for Magento 2? There are three possibilities. The first option is easy for developers and hard for business: you can skip that module for now and make shop work without it. Maybe you don’t need that functionality at all or it is possible to postpone the development after the shop is working. The second solution is to look for similar module from another vendor (here goes the same warning about vendors). And finally, the third option which is hard for developers and good for business: implement it on your own. It can take a lot of time and resources, but if it’s crucial for your business, there is no other option.
Migrate data from the database
We will write another blog post about migration database and give you some tips and examples. Basically, it’s all about using data-migration-tool delivered by Magento itself.
To be continued.