Magento Migration -
a journey from M1 to M2
A comprehensive walkthrough
It seems like it was yesterday when in 2015 Magento launched the very first release of the platform's 2.0 version.
Everybody was slowly adjusting to the idea of migration, waiting for the platform to become more mature and stable and the community to grow.
All of a sudden we landed in 2020 which means that Magento 1.X won't be supported in a couple of months.
In other words, it's high time to make some decisions.
In the last few months, we've recorded a peak in inquiries from clients all over the world, asking us about the Magento 1 - Magento 2 migration.
This is why we decided to summarize and share our experiences.
We believe that sharing them will help you to go through the migration process successfully... and painlessly.
Let's start with the right approach.
You shouldn't think about the M1/M2 migration as an actual migration. You should think about it as a completely new platform you're about to build from scratch.
Don't think that hiring a reliable development team will solve the whole problem.
A solid plan is what you should start with.
Think about your business goals and how would you like to develop your business in the future. Keep the bigger picture in mind and remember that your ideas will be turned into functionalities.
It's not the part you want to save time on!
Below we summarized all the crucial 'dos and don'ts' and divided them into steps. We hope to answer some of your questions or clarify your doubts.
The UX Process
- Avoid Mistakes
- Maintanance & Development
An agency that appeared on the market a year ago is not a partner you're looking for.The ideal team has been working with Magento for years, starting from early versions. They have a proven record of successful M1 and M2 implementations and migrations to M2. Having long-term clients in the portfolio is also a good sign. It means the implementation phase ended with success and led to ongoing cooperation.
The migration of an advanced Magento 1 platform that's been developed for years is a demanding project and it should be conducted by a cross-functional team. It should include Frontend developers, Back-End developers, QAs and DevOps, preferably in-house. A team that has worked together successfully on one or more projects is able to do tasks in a fast and efficient way and avoids communication noise.
There's no better way to validate the developer's expertise than a certification. It also confirms your developers keep improving their skills and stay up-to-date with Magento technology.
Now, what is the most desirable situation?
When your software development team is not only experienced and certified in both M1 and M2 but also business-conscious.
If you've had a chance to cooperate on your M1 shop and they're going to migrate your shop to M2 -it's a perfect situation.
Those most popular are of good quality and solve a lot of problems merchants face. Unfortunately, hardly ever all the functionalities are being used. As a result, there’re long lines of code that are not being used but still eating your space and slowing down your webshop.
That’s why we recommend you to start with auditing your current shop. Together with your development team analyze what solutions should be migrated (and by migrated we mean replaced by those for M2), which can be replaced by Magento 2 out-of-the-box options and which should be custom-written.
Investing time into a proper audit will help you to avoid cluttering your brand new Magento 2 platform with unnecessary code.
We also recommend conducting UX analyses of your current M1 shop. You’ll learn what’s to improve in your existing shop and use that knowledge to enhance the design of your new platform.
Migration to M2 is a perfect time to redesign your shop as you’re basically building your shop from scratch. However, it carries a risk that your project becomes too complex, and the emphasis would be put on redesigning instead of crucial tasks such as building the platform or shop migration.To ensure no such issues occur include developers responsible for the migration in the designing process. Auditing the design while is being created is way cheaper than applying changes to the existing code. Developers should also keep the size of the project under control to make sure that attention is centred on architecture and functionalities.
You should also consider turning your shop into the PWA.
Such an approach will help you to divide the project into manageable steps to avoid too much complexity.
In such a construct, you keep you Magento 1 shop, build the PWA (with a new design) and connect these two solutions. Then you develop Magento 2, and once it’s ready, you connect it with the PWA.
You can read more about PWA in the section 6.
Another key step is shopping process evaluation.
Test different scenarios, search for weak points that would lead to cart abandonment. Make sure those issues are analyzed with your development team, which should propose solutions to eliminate them in Magento 2 platform.
Now it's time for requirements definition. Sorry to scare you but hey, it's the crucial part of the project. If the prepared documentation is inaccurate or incorrect, it results in higher development costs due to waste of resources or delays in the development schedule. We often hear that clients don't understand why this step is important and suggest that a project can be based on their working M1 shop. On the other side, we have a team of developers that don't know or don't understand what the business objective is or how something should work.
Well-prepared documentation answers most of the questions and describes the functionalities. It helps to avoid costly changes to the written code. If for some reason, the client chooses not to invest time in requirements definition, we still need to divide the project into stages and describe them in a written manner.
At Hatimeria, we involve our QA team in the requirements definition process. They gather the requirements from the client and turn them into tasks for the development team. Once the functionality is built, our testers assess if it's working according to the requirements.
If you decided to redesign your shop completely and change it according to the UX designer's indications, it's a good idea to define an MVP (Minimum Viable Product). Even though an MVP is a very early, basic version of the product, it still enables us to verify if the business need is fulfilled.
Check two or three times if your development team has all the necessary accesses and all the logins and passwords actually work :) A group of frustrated developers at the very beginning of the project is something you want to avoid.
Share the accesses:
It seems a bit early for making such a decision when your e-commerce platform is still in the planning phase. Well, it's not. If you choose a hosting provider, from day one of the development, the hosting requirements will be met. It means once your M2 is ready, it won't need adjustments to the hosting environment. As most of the providers offer scalable hosting, the cost won't be high, as, at the time of the migration, you're going to use minimal resources.
Your shop needs to be fast and stable to get and keep a high conversion rate:
Make sure your current and your future shop are appropriately secured. When a lot is going on, it's easy to make a simple mistake that might lead to a security breach. If you work with professionals, the risk is low but not non-existent.
Yes, we know you might find this surprising. We were, too, when we compared how much time it took us to migrate the data. Long story short - it went faster without it. Why? Data Migration Tool works best if your shop is simple and barely customized. We haven't seen a Magento shop like this in years. In all other cases, you'll need to start with adjusting the tool to your client's M1 platform, then migrate the data and then adapt the data anyway. M1 and M2 are simply too different to use any automated migration tool.
IF your team will write a customized Product Database migrator, tailored to your shop’s needs, you should be able to migrate those data rather painlessly.
If your catalog isn't large, it might be faster to move it manually than to write a migrator/importer. As usual, take costs into consideration.
Developing your M1 when your M2 is in progress.
Changing the code of your old platform when your developers are building the new one is not a good idea. You're investing a lot of time and money into your new webshop so stick to the development plan to avoid chaos.
Moving unnecessary data
The biggest challenge is not to clutter your brand-new Magento 2 shop with unnecessary data.
Decide if it's necessary to keep it all?
Here're some questions to help you make the decision:
Does keeping the whole database fulfill any business need? (for example: Do you need for reporting purposes only? If yes, you can simply compare reports from Magento 1 and 2, use Google Analytics, or if you decide to use an ERP system - you can generate reports directly from that software).
Are you obliged by law to keep that database?
Do you need to move all clients' accounts or only of those who made a purchase?
Maybe it's time to consider moving your database to some ERP system?
Do you want to move the whole product catalog as is, or perhaps it's time to update it as well? (fresh pictures, new descriptions, etc.)
Maybe you should consider moving your catalog to a PIM (Product Information Management)?
- 1Once you move the Client Database to Magento 2 all your clients will have to create new passwords with the first log-in.
- 2It’s worth to email them and warn that your shop was updated and it’s a standard procedure.
- 3Mailing lists: remember to copy that lists from m1 to M2 or if you use some external solution, remember to connect your new Magento 2 shop with it.
- 4If you can install a solution from the marketplace, which is based on the same data structure, it’s great. If you can’t, the best solution is to write a migrator to move it from Magento 1 to Magento 2.
- 5Custom functionalities also store data that needs to be migrated.
Customers Orders DataBase migration
Here are some example solutions you should consider:
MOVING ONLY THE CLIENTS DATABASE:
You keep the key data and transfer it to your Magento 2
No orders history.
KEEPING ORDER HISTORY IN MAGENTO 1 AND USING IT AS A DATABASE.
You don't keep old data in your Magento 2 shop.
Way cheaper migration.
Your clients won't be able to check their order history without the additional work of the development team.
KEEPING ALL DATA IN THE EXTERNAL ERP SYSTEM.
If you decide to update your Magento or even change the platform, you won't need to move the database anymore.
You need to integrate your Magento 2 with the chosen ERP software and move the data. Additional time and cost (but just once!).
BUYING AN EXTENSION AND ADJUSTING IT.
Extensions from the marketplace are rather cheap (or often free).
Their code is often of poor quality, and adjusting it might take as much time as writing it from scratch.
Cluttering your M2
Think twice every time you want to install any new extension. You don't want to turn your fresh M2 into a garbage dump! Any extra line of code is unnoticeably slowing down your store. It seems cheaper than going for a tailor-made solution, but in the long run, might come pricey.
Regardless of the option you choose, make sure your designer is UX-conscious. You do it all because your business goal is to sell more so the whole shopping process flow should be as easy and convenient for the client as possible.
And while we're on the subject, it's good to UX audit your shop from time to time. Here's a link to a study case describing how implementing changes led to significant conversion rate improvement.
The PWA is an ideal solution if:
you have a shop with a highly-customized user interface,
you want to have the best interface on the market, BUT
you accept it's not the best quality/money ratio (i.e., it's not a cheap solution)
you’ve got a long-term plan and strategy for your business
you’re aware you’ll utilize its full potential in the future
you want to gain a technological and competitive advantage
you want to acquire new users and dominate the market (the best solution wins)
you have content coming from various sources such as PIM, Wordpress, Instagram, etc.
THESE ARE THREE MAJOR FACTORS FOR THE PROJECT TO SUCCEED:
If more than two points don't reflect your situation, stick to a standard Magento 2 front-end.
- 1Your designs need to be refined and prepared with/by a UX designer who knows the PWA technology.
- 2No or minimal changes to the designs during the development process. Any changes at this stage are costly.
- 3You’re willing to spend 2-3 times more money on the PWA (than on a standard front-end), and you accept this risk.
INTEGRATION WITH EXTERNAL SYSTEMS
Earlier in the test, we recommended starting from Magento 1 shop audit. If you did that, you learned which apps were useful, and it’s worth to keep them in your Magento 2 store. You also know how you want your business to grow and what solutions you require you to achieve it.
Integration with the ERP system is the most crucial one (if you decided to have it). Payment and shipping solutions are also essential. Don’t forget about the marketing side, starting from Google Analytics (or other tracking software), New Relic, to mailings.
Check if the apps you decided to keep have Magento 2 versions (and as it’s already 2020, the most popular ones have).
You can get most of the apps online after you set up an account (and most often - pay). But be aware that to purchase some solutions (such as some ERP systems), you need to sign a paper contract. You need to take care of it in advance. Otherwise, it can impact the development schedule.
For such complex integrations such us with ERP systems, ensure there’s a technical representative of the solution provider that can answer your questions. Otherwise, you’ll have to find them yourself.
If you decide there’s no out-of-the-box solution that would fulfill your business need, your team can help you with that by writing it from scratch. Remember, it increases the final cost, so double-check if no other application solves the problem.
Make sure it’s properly tested and keep in mind that sandbox options don’t fully reflect the actual shopping process. Proper testing takes time and usually indicates areas for improvement. The development team also needs time to apply those changes.Be careful, though, with payment gateways. In this case, it’s better to stick to ready solutions that are well-tested in various scenarios.
We do realize that at this point, you can't wait to launch the platform and don't want to postpone it.
If the performance tests indicate necessary adjustments, apply them.
Make test orders, test payments (using real credit cards/ Paypal, etc.), and check if the shipping options work (shipping orders are being sent to shipping & delivery companies and email notifications to your test clients).
It's good to notify your clients that you're going to launch a new version and prepare a downtime page which will inform your clients what is going on and when they can expect it back online.
Please remember that it will take some time until Google will re-index your site!.
Some solutions turn out well, some don't and need further adjustments - and that's ok.
Investing in development will keep your platform is crucial to maintain a competitive advantage.
As it was said at the beginning, migration from Magento 1 to Magento 2 means we build an entirely new platform from scratch. The person responsible for decision-making needs to be engaged in every aspect of the project, especially with the PWA, and have clearly defined goals.
The key one for an e-commerce platform is to sell more.
The whole development strategy should be focused on increasing the conversion rate. We can learn about clients’ shopping preferences from multiple reports analyzing every click they make on our website. Make sure you make use of that knowledge and implement improvements, those suggested by your clients in the first place.
Keep researching for new solutions and ways to upgrade your platform. And if you haven’t switched to the PWA yet, it might be an excellent way to achieve that.