It has been more than 5 years since the Magento 2 release which generated a huge stir within the developer community. And although the company has ended support for Magento 1 in June 2020, many entrepreneurs are still not in a hurry to migrate.
Magento 1 to 2 Migration is a painstaking task fraught with various issues. Due to the challenges the process involves, some business owners are still in doubt whether it’s worth migrating to Magento 2. Well, in point of fact, in some cases, it makes sense to stay on the first version for a while. But you’ll have to do it sooner or later.
Having over 40 successful migration projects behind our back, we’ve compiled the most definitive Magento 2 migration guide on the Web. In this article, we describe the process of regular Magento 1 to 2 migration. Those of you who wish to migrate to Magento 2 with a progressive web application may find handy these articles on Magento PWA pricing, creating PWAs with the PWA Studio, and how to build a PWA with plain React.
Use the navigation below to reach the chapter of the article that you are interested in:
When we talk with our potential customers about their need to migrate, they all agree that it’s a good idea and they should be doing it. And yet they don’t. Why?
Well, we’ve found 3 main reasons why store owners don’t rush to migrate their stores right away:
- merchants fear the cost of Magento migration;
- they don’t fully understand why they need to move right now;
- they want things to “just work” and fear change.
All these points are legitimate, and unlike most of our competitors, we don’t push clients to upgrade if they aren’t ready yet. At Onilab, we prefer to make value-based considerations of every project. We take the level of customization and current site performance into account.
The fact is that the migration itself will bring you neither better performance than your M1 store already has nor better sales. Besides, with some adjustments, your M1 store can work as seamlessly as M2 websites.
As such, some large and middle-sized business owners have already customized their Magento 1 websites. This way, their stores are profitable and have a high conversion rate. So, why do these merchants need this move?
In practice, highly-customized Magento 1 stores have only three reasons to carry out such a painstaking and expensive process as Magento 2 migration:
Reason 1. No More Security Patches
E-commerce platform statistics can be all over the place. But there are at least 250,000 Magento stores on the Internet as of 2021. It’s the second most popular eCommerce platform in the world. Would you like to take a wild guess of how many of them are running on Magento 1.x instead of Magento 2.x?
More than a half.
Now imagine all of these stores lose the ability to get new security updates in one go. Overnight they become one of the most profitable targets for hackers and scammers from all over the world.
This is because when hackers find any new vulnerability from now on, there won’t be official patches for them. It will stay with the store forever, making it vulnerable to the same exploit again and again.
E-commerce is already one of the most profitable targets for online criminals. And there are just one too many Magento 1 stores that hackers can specifically target.
Hackers are not always going for the money. Among other attacks are:
- store defacing;
- injecting your site with malware to infect customer computers;
- making your store a part of their DDoS or mail spam botnet;
- establishing a backdoor for future use;
- hosting illegal content;
- among others.
Reason 2. Crippling Data Leak Fines and Inability to Work With Major Payment Systems
Lack of PCI compliance leads to data leaks that take place on Magento 1 websites. And e-commerce stores have a lot of data that hackers are interested in. Do you have to switch your Magento 1.9 store in this case? Yes! Stolen CC data and personal customer info are among the most frequent attack targets. Let’s take a closer look at the possible consequences.
- The leak of CC information will lead to large, potentially crippling fines from Visa, MasterCard, and other payment processors. Depending on the damage done, fines can be as high as $100,000+ or more. There is no upper limit to how much money it can actually cost you.
In addition, there are peculiarities with payment processors, such as Stripe. They’ll freeze your merchant account during the investigation period. This will cause further damage.
- Customers’ personal data is another major attack target. It can lead to loss of business reputation and potential lawsuits. Being on the receiving end of the litigation process is not a fun experience. GDPR laws (that protect customers’ personal data use) are strict and lead to significant fines. We’re talking up to €20 million or 4% of the total company turnover.
- Lack of PCI compliance puts payment security at risk. The Payment Card Industry Data Security Standard is a set of security standards. It helps businesses to stay protected from breaches, reduce the risk of fraud, and increase control of cardholders’ data. Being PCI compliant not only gives peace of mind. It also paves the way for working with various payment systems, such as PayPal. In the immediate future, the absence of compliance will deprive the stores of major opportunities. For example, to perform transactions via PayPal or other PCI-compliant systems.
Reason 3: Serious Roadblocks or Complete Inability to Build a PWA on Top of a Magento 1 Website
The e-commerce industry is constantly changing. One technology replaces the others, and websites become more convenient for users. Thus, it is essential to keep up with the industry development. Staying behind in online retail can hurt your sales.
The Magento 2 platform provides great opportunities for e-commerce websites. You can stay tuned to the latest trends and ensure they deliver the best UX possible.
The second version of Magento has the feature that M1 is lacking, PWA Studio. Progressive Web Applications are considered to be the future of e-commerce. They are extremely fast, responsive, and available without an Internet connection. Plus, they provide an app-like UX and function inside a web browser.
The PWA Studio is one of Magento 2’s unique features, it uses modern tools and libraries. Building progressive web apps with the PWA Studio enables developers and merchants to create a fast and engaging user experience.
It’s very difficult to build a PWA on Magento 1 due to the absence of GraphQL compliance. Yes, in theory, it’s possible to implement GraphQL compliance so it’ll work on Magento 1. Yet making such a custom GraphQL solution for M1 is a tricky and time-consuming process that just might not be worth it. In any case, using GraphQL is very handy when building a progressive app. It’s a perfect alternative to REST which has proven itself to be quite ineffective for multiple reasons. So, if you want a PWA for your site, making a switch to Magento 2 makes a lot of sense.
Let’s assume a Magento 1 store is poorly-customized and cedes ground to competitors. Do you have to change Magento 1.9 to 2? Such a store can boast neither good performance nor high conversions. Well, then it has a lot more reasons to migrate to Magento 2 apart from those mentioned above.
Again, highly-customized Magento 1 stores need M2 migration mainly for security reasons. Unlike them, stores with a low level of customization simply can’t ignore this process. We strongly recommend switching to the latest Magento version because it offers a plethora of features out-of-the-box. As such, the necessity for development services is less. This means that you won’t have to pay for the developers’ extra hours and save your money. Besides, dealing with the second version is much easier as everything within the platform is tooled for smooth work.
Let’s have a look at other reasons to move to Magento 2. This is in addition to the reasons stated above.
Reason 4: Lack of New Functionality
Magento 1.9.x is the final version of Magento 1. So in addition to security patches, Magento 1 stopped receiving new feature updates as well. The lack of new functionality in a changing and highly competitive e-commerce environment is a huge setback.
Yes, you can easily supplement most features with third-party extensions. It will get harder and harder for you to find new stuff in the future. Independent developers are not going to stick around for long. And you don’t want to get stuck on a stagnating platform.
Besides, there are over 5,720 third-party extensions on the Magento Marketplace, and this number is constantly growing. New extensions and themes get released or updated on a daily basis. But what about Magento 1 extensions? There are still 2,050 M1 extensions and themes on the Marketplace. Do they get the same amount of attention? Nope.
Got bugs or long-promised features for your favorite extension? Not a chance it will ever get updated again. You are basically stuck with what you have. On the other hand, Magento 2 has a 30% wider selection of themes and extensions.
New extensions will get released only for Magento 2, making M1 a desolate and lonely place. Today Magento 2 default functionality gets updated with PWA capabilities and complex warehouse management tools. Not to mention other awesome features that will never come to Magento 1. Ever.
Reason 5. Subsequent Technological Lapse
The development and server environment are moving forward too. Right now your hosting provider has to support dozens of configurations. This is done to ensure that every website and store runs on its recommended software.
This includes certain modules and solutions that are out of date or no longer supported by the development team. The same regards outdated PHP and MySQL versions. This might not seem like a huge deal to you right now. But after some time, your hosting provider will also urge you to move to a more recent server environment.
Reason 6. Raise of Development and Support Costs
The effort to maintain an aging environment and platform is something to keep in mind at all times. As new technologies substitute old ones, it will get harder and harder to find skilled developers. Mind that not all developers want to work on an outdated project with an outdated technology stack.
Right now Magento 1 might seem pretty recent. But further down the road, Magento 1 will feel older every day. Especially after June 2020 when the official support ended.
Take a look at our Magento 2 pricing guide. It shows how much it will cost you to run the new store on a daily basis.
Reason 7. New Admin Features and Better Checkouts
Magento 2 backend not only looks better, but it also works better. Consider this:
- new data safeguards to help multiple users work on the same content simultaneously;
- native video embedding capabilities;
- reworked Admin Panel UX and menu logic;
- step-by-step New Product menu;
- improvements to grid view for products.
Throughout its lifetime, Magento 1 had to deal with a sluggish and complicated Checkout process. The Magento 2 team managed to rethink how the Checkout should work. They made it faster and simpler. Of course, you could customize your Magento 1 website to make the checkout better. However, this process requires much time and effort.
Reason 8. SEO Improvements
Magento 1 gets a bad rap for how it handles SEO. Especially what regards duplicate content and meta tags. The Magento dev team learned their lesson and made many such improvements in Magento 2. It has become more consistent, Google-friendly, and just easier to cope with. Take a look at how to improve it even further in our Magento Google PageSpeed Insights guide.
Magento 2 learned how to improve meta tags too. They are now present on all product pages natively (no need to use SEO extensions). By all means, an SEO specialist’s work is much easier on Magento 2.
Reason 9. Mobile Friendliness
No need to say mobile is on the rise. The number of mobile users in 2020 reached 6.95 billion as per Statista. They estimate the growth to 7.41 by 2024.
It is, therefore, crucial that your online store runs perfectly both on desktop and mobile devices. Magento is tailored to run equally well on all phones and tablets. It offers an easy experience and properly sized landing pages for all mobile users.
All those Magento 2 benefits are available out-of-the-box. So, for poorly-customized websites, it makes sense to get ahold of them by migrating to the second version. This is better than paying for extra hours when trying to customize their old Magento 1 store.
Migration to Magento 2 is considered to be a complicated process. It involves the collaboration of different people: a project manager, designer, developer, QA engineer. In the last several years, we’ve successfully finished over 40 major migration projects. In the process, we discovered quite a few patterns.
We’ve decided to create a detailed migration checklist. This checklist on how to migrate Magento 1 to Magento 2 explains how we organize migration processes at Onilab. It describes what stages it includes and how to handle every milestone.
Not sure how long does it take to migrate Magento 1 to Magento 2? The duration of your migration will heavily depend on:
- the number of extensions;
- design and theme requirements;
- additional features;
- third-party extensions;
- the number of store views.
Let’s take a look at the main migration stages and why they can take so long to complete.
The Stages of the Migration Process: How Long Do They Take?
There are 3 major milestones you need to reach in order to migrate from Magento 1 to Magento 2. Each of them will be further broken down:
- The planning stage
- UX and UI (mobile/tablet/desktop design)
- Frontend and backend work, data migration, and post-release work
Below we’ll introduce you to the steps that imply the aforementioned milestones of the migration project. We’ll give details about every stage and their estimated time frames.
1. Assess the Current Environment and Migration Scope
First, we must make sure that both the client and our team understand the complexity of the task ahead. For a clear picture of the amount of work, we analyze the migration scope by estimating the following factors:
- the current technical functionality of the website (third-party extensions, integrations with different ERPs and CRMs, custom themes, Magento core customizations, etc);
- the size of the store, as well as the number of storefronts and domains in use;
- the functional changes that have to be made during migration to Magento 2.
Besides, we provide an explicit evaluation of the migration cost to our client. We analyze the effort and time the engaged specialists would spend migrating the M1 store to Magento 2. For these purposes, we estimate how much time it takes to:
- develop code of the new Magento 2 website;
- develop a new design of the store;
- build up custom functionality from the ground up (or find proper replacements for the existing third-party modules).
All those factors enable us to provide a rough estimate of the migration cost to our client.
Estimate hours for the planning step:
2. Put Together a Customer Journey Map
A customer journey map is a visualization of every experience a customer has with a store. This includes the time from initial engagement to forming a long-term relationship. The major purpose of customer journey mapping is to understand what stages customers go through. Then you can improve the quality of their shopping experience. You ensure both smoothness and consistency at all touchpoints and across all channels.
Customer mapping is one of the most important stages of the migration process. The collected information helps designers and developers to minimize negative customer experience and deliver a better product.
Basically, the map includes the following information:
- the definition of a potential (target customer) of a Magento website;
- a typical customer lifecycle;
- touchpoints a customer uses to interact with the company;
- pain points (points of friction);
- methods of resolving the friction.
Some companies ignore this stage claiming this method is old-fashioned. However, at Onilab, we consider mapping to be one of the most important milestones of Magento website development.
When potential clients turn to us with migration issues, this means they already have a website on Magento 1. Their store already has the customer experience off and running. As such, we can map this experience to correct mistakes and deliver better UX on the new Magento 2 store. Contact us to get a customer journey map template for e-commerce.
Estimate hours for the CJM step:
So, we’ve collected information during the customer journey mapping. Our designers will use it to create UX and UI for the new website.
You are going to migrate to a new store. This is a great time to experiment and improve. You can:
- work on your store’s user experience;
- get more visibility for your bestsellers and most searched for items;
- rework product categories;
- move the UI elements;
- and switch things around in general.
Look through the analytics to see where you need to make changes. Perhaps you can:
- rework your layout in order to improve usability;
- improve the search to allow users faster access to key pages;
- boost conversions in underperforming categories;
- direct customers towards certain products or categories.
Magento to Magento migrations from one platform to the other take a lot of time and effort. Specifically, because UX analytics and changes are time-consuming and hard to predict. Finding and fixing UI issues and discovering flaws in the sales funnel is time-consuming. Plus you’ll need time to approve and implement all the changes.
Our clients are free to use an out-of-the-box design template provided by Magento 2 if it meets their requirements. By choosing this way, you can drastically reduce front-end UX/UI design efforts and costs. Furthermore, the designers can customize the existing theme or develop a new one using a mixed-method. They may opt for a combination of custom templates, layouts, styles, or images.
Customizable themes offer just the right balance between the available options and your actual needs. Just bear in mind that because of the sheer amount of customized code, they can slow you down.
But we recommend that you create a brand-new design. Why? The amount of effort to simply move the design and to create a new one is comparable here.
You will, of course, save some time if you only want to migrate without changing anything. But it’s not the best option since so much has changed in eCommerce design recently.
Depending on the friction points and other data, our designers decide what changes to make in UX and UI. This can be improving search to provide the users with fast access to target pages. Or reworking the entire layout for better usability, there are many options.
Significantly, during the process of creating design patterns for a Magento 2 store, our designers consult with the developers. They obtain approval and make sure that the new design is convenient to deploy and beneficial for the client.
Creating a proper mobile/tablet user experience requires a lot of effort too. Why? Because different users interact with your store differently on various platforms.
What are the steps? Designing a new look takes time and a lot of iterations to get it right. Usually, we offer at least 2 versions of your new store. Since even with minimal changes we still need to:
- create separate wireframes for mobile, tablet, and desktop layouts;
- review the store structure and make changes to UI elements;
- rework navigation logic and the main menu for all 3 platforms.
Even though that’s not a lot, preparing even two separate themes is time-consuming. Note that you also need to create the design for your mobile and tablet views. Expect this stage to last 80-250 hours depending on the workload. The difference between the two values comes from the number of changes you want to make.
Can you make it shorter? Yes, if you do your homework before you contact the development team. You can easily cut the time from 250 to 120 hours or less. The key here is to know exactly what you need. This includes which changes you want to make and what they’ll look like in the final version. Plus, you can take a ready-to-use theme from the Magento Marketplace or Theme Forest. These themes are highly customizable and can work with a ton of different store layouts. Because of this, they tend to have a lot more code which makes your store slower. So you basically get a better deal but lose performance speed in the process.
Estimate hours for the UX\UI step:
120 – 250 hours
Milestone 3: Magento 1 to Magento 2 Migration Process in 10 Steps (from the Development Perspective)
The frontend and backend work milestone of the upgrade to Magento 2 will take the bulk of your migration budget. This is where you spend 336-672 hours (2-4 months worth of development time).
Frontend and backend work is all about applying the design that we developed. Then you iron out the compatibility bugs, optimize old extensions, or develop new ones.
Even though it’s the longest milestone of all, it’s hard to measure its length precisely. The time you’ll need to implement all frontend and backend changes is individual for every case. The longest migrations can last 8-9 months, sometimes more.
What are the steps? The time it’ll take to create strong frontend and backend functionality depends on what you need from the store. In essence:
- Extensions take a lot of time to develop, install, and test for compatibility.
- Complicated design layouts require skilled and dedicated frontend experts to apply it correctly on all versions of the store.
- Magento backend tasks depend on how many changes you need.
- You also have to figure out how to build in all the necessary integrations.
- Then you optimize the store for speed and security.
Can you make it shorter? Yes. The less customized your store is, the less time you’ll need to upgrade Magento 1 to Magento 2. It’s completely possible to complete the backend and the frontend parts of the store in 2-3 months. Expect to spend around 100 hours dealing with extensions. The rest of the time is for working on frontend layout, backend functionality, and various bug fixes.
Now let’s go over the 10 main stages making up the process of the migration to Magento 2 from the development perspective.
1. Preparation works
Before starting the migration, the development team must make sure to have all the required software and setups. Depending on the used version of Magento, there’ll be different requirements for the software.
For Magento 2.3.x:
- The PHP version must be 7.3.x.
- The MySQL database version of 5.7, or the MariaDB database version of 10.2.
- As well as these PHP extensions: bc-math, ctype, curl, dom, gd, hash, iconv, intl, json, libxml, mbstring, openssl, PDO/MySQL, SimpleXML, soap, spl, xsl, zip.
For Magento 2.4.x:
- The PHP version must be 7.4.x.
- The MySQL database version of 5.7.9 or 8.0, or the MariaDB database version of 10.2 or 10.4.
- As well as these PHP extensions: bc-math, ctype, curl, dom, gd, hash, iconv, intl, json, libxml, mbstring, openssl, PDO/MySQL, SimpleXML, soap, spl, xsl, zip.
- The Elasticsearch advanced search solution version 7.9.x.
What’s for hardware, it is advised to have at least 2G of RAM, otherwise, there won’t be enough resources to compile the code. Furthermore, a combo of the SSD technology with 24GB+ will allow the store to work quicker.
Furthermore, the migration won’t be possible if you don’t install the freshest version of Magento, currently, it is 2.4.2. The Open Source edition can be downloaded from the official site.
2. Get an optimal Magento 2 data migration tool
When thinking about how to migrate Magento 1.9.x to 2.x loss-free, you should plan your data migration. Products, users, order history, and custom product types all have to get imported from the old store.
We recommend the standard Magento 2 data migration tool to move your store from Magento 1 to Magento 2. This tool is also useful if you’ll migrate from other platforms to Magento 2. Mind that you’ll have to write custom logic to correctly move and merge data from the source platform.
The tool is capable enough to deal with most migration scenarios. Although you’ll have to make changes to the code in order to move any custom data. These are tables or columns that are not a part of the Magento 2 standard dataset.
Third-party extensions often create lots of custom data to store new product parameters or other data entries. It’s your decision whether to move that data to the new platform or leave it behind. If you decide to move it, though, take a look at this handy M1 to M2 code migration tool. Feel free to visit the official Magento website to learn how to migrate data to Magento 2 without breaking anything.
To install the data migration tool, you can use the code from the example below:
root# composer require magento/data-migration-tool:2.4.2
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing magento/data-migration-tool (2.4.2): Downloading (100%)
Writing lock file
Generating autoload files
3. Configuring the data migration tool
- Now we make changes to the data migration tool in the corresponding directory in the Magento 2 root folder. Copy the configuration file for your version of Magento 1.
- Make sure to replace the “1.9.x” with the Magento 1 version that your store is running on. Plus, if you’re changing the edition of the store as you migrate (f.e. from Community to Enterprise/Commerce), you’ll have to make changes in the following line:
opensource-to-opensource → opensource-to-commerce
- In the config.xml file indicate from where and to where the data should be migrated like in the following example:
123456<source><database host="localhost" name="m1" user="m1" password="m1"/></source><destination><database host="localhost" name="m2" user="m2" password="m2"/></destination>
- Then indicate the crypt_key field within the options tag:
- The crypt_key that you have on your Magento 1 site is placed inside the app/etc/local.xml file in the store’s root folder:
12345678910<config><global><install><date><![CDATA[Wed, 17 Feb 2021 21:29:35 +0000]]></date></install><crypt><key><[CDATA[<strong>85ba8337149597a561bee04ec6c9a347</strong>]]></key></crypt><disable_local_modules>false</disable_local_modules><resources>
4. Settings configuration & migration
- The next step deals with migrating the settings and other data. In the root folder of Magento 2 do the following:
1php bin/magento migrate:settings vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.x/config.xml
This is what we got as a result:
123456789101112131415161718192021[2021-02-17 18:22:22][INFO][mode: settings][stage: integrity check][step: Settings Step]: started100% [============================] Remaining Time: < 1 sec[2021-02-17 18:22:22][INFO][mode: settings][stage: integrity check][step: Stores Step]: started100% [============================] Remaining Time: < 1 sec[2021-02-17 18:22:22][INFO][mode: settings][stage: data migration][step: Settings Step]: started100% [============================] Remaining Time: < 1 sec[2021-02-17 18:22:24][INFO][mode: settings][stage: data migration][step: Stores Step]: started100% [============================] Remaining Time: < 1 sec[2021-02-17 18:22:24][INFO][mode: settings][stage: volume check][step: Stores Step]: started100% [============================] Remaining Time: < 1 sec[2021-02-17 18:22:24][INFO][mode: settings][stage: volume check][step: Stores Step]: Migration completed
- The example above was rather basic. Thus, if you’re case needs a more in-depth configuration than just installing the stock, you should make changes to the settings in the configuration file: (vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.x/config.xml) as shown below. Note that prior to making edits, you should copy this to settings.xml.
- Furthermore, make sure to check the naming of the config.xml file.
- In case some settings in the settings.xml should be ignored, run this command:
- In case some settings in the settings.xml should be named differently:
5. Develop Custom Functionality for a Magento 2 Store
Developing custom functionality for a new Magento 2 store is a good share of the work. At this stage, hiring experienced Magento developers is a “must”. You can minimize the risk of wasting time fixing bugs that appeared due to the work of ham-handed “specialists”.
A major part of the code has to be created manually from scratch. Yet you can migrate some custom code can from Magento 1.x to Magento 2.x. To make the process easier, you may use The Magneto Code Migration Toolkit. It provides scripts for converting custom M1 code to M2 by handling some of the most time-consuming tasks. The tool thus reduces the work involved with code migration.
For instance, the toolkit covers the migration of the following aspects of code:
- Layout XML files
- Config XML files
- PHP files
- Module directory structure
The toolkit converts these aspects to the structure and format recognized in Magento 2. Yes, it significantly reduces the amount of work involved in the code migration. Yet one still needs to manually edit some of the generated files.
6. Find Replacements for the Existing Modules or Create New Ones
When you migrate from a completely different platform, it’s hard to find identical functionality readily available for your store. Be prepared to make a few compromises.
Looking at your existing custom functionality, you have 3 main options in terms of alternatives.
- Extensions that have both M1 and M2 versions in the Magento Marketplace. Most Magento 1 extensions have M2 alternatives although the functionality itself can be different.
- Extensions that are exclusive to the previous platform but have third-party alternatives.
- Completely unique customizations that you’ll need to rebuild for the Magento 2 platform from the ground up.
We encourage you to do a full inspection of all the extensions you have beforehand. Make a list of all the customizations and rank them in the order of priority. Put all extensions into 3 columns ranging from “Essential” to “Nice-to-Have” to “Unimportant”.
Moving from one platform to another is a great opportunity to declutter and clean your store. Try to drop as many unnecessary extensions as you can. This may help to both cut migration costs and improve future performance.
7. Conduct Magento 2 Plugins Testing
Let’s assume we’ve found the proper replacement for the existing functionality (or developed new modules). Now it is time to verify if they work as expected, without compromising Magento 2 performance and functionality. Magento 2 modules testing is a complex process. It involves the engagement of QA engineers and uses specifications or other inner documents.
At Onilab, this process includes the following stages:
- testing the functionality of every extension;
- testing Magento 2 features that can be affected by the modules;
- load testing (some plugins will potentially deal with a huge amount of visitors and data; as such, it is important to check the response time of the pages with high traffic on the frontend and how these plugins handle big amounts of data on the backend);
- cross-browser and mobile checking;
- checking extensions compatibility with other third-party extensions;
- standard security testing;
- testing in production mode.
8. Configure the Servers
Server configuration is one of the most important parts of the development phase during the Magento 2 migrating process. Because Magento’s second version is considered slower than the first one, some caching tools are essential for good performance.
As such, we recommend Varnish, a tool that creates an extra layer between the web server and the user. It can cache frequently requested files into RAM, prioritizing those files that are requested more often than others. As RAM is faster than an SSD, it is able to return cached files in a second. Put simply, Varnish accelerates HTTP traffic, helping the user to see the page almost instantly, instead of long awaiting. Varnish can increase your site speed a thousand times.
Plus, when combined with a CDN, Varnish can contribute even more to Magento 2 performance improvement thanks to cached images.
While Varnish is used to cache HTTP requests in RAM, Redis is another caching tool. It does the same for database objects to speed up dynamic database-driven websites. In layman’s terms, Redis is a caching tool for the backend of a Magento store. The tool makes your Magento 2 store faster and more reliable since it optimizes Magento session storage. If you don’t like Redis for some reason, use Memcached as an alternative, these tools are interchangeable.
9. Data Migration
The data migration milestone consists of five data categories that you should move in order to complete the process. These are:
- customer data;
- product data;
- orders data;
- store settings;
- third-party extensions data.
Each of these 5 entities takes about 8 hours to migrate. It all depends on the number of custom fields that you have in them. The lower the number, the faster you can move them.
Each new custom attribute adds to the complexity of the migration. You have to manually migrate them in order to correctly move them from one store to the other. The biggest challenge is how you handle your custom data. Migrating a standard account information table takes one hour tops. Moving the same amount of heavily customized data with the ability to use that customized data in the future will amount to 8 hours of work. Which brings us to 20-40 hours of moving data from Magento 1 to Magento 2.
You can cut down the time frames if you decide to leave something behind. Or if you don’t import anything during Magento migration from 1 to 2 and just get an empty store. Maybe you are fine with losing some data from 10 years ago, who knows. After all, it’s up to you. Do you need 5-year-old Magento 1 logs? Maybe it’s cheaper to fill the store by hand. You have options here.
Now let’s take a look at how data migration is handled from the development perspective.
a) Migrating initial data
During this step, migrate the data of your Magento store. This includes information on your clients, users, orders, etc. Use the example of the following command:
# php bin/magento migrate:data vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.x/config.xml
Keep in mind that there may be errors at this point. Yet they can be fixed using the settings of the data migration tool.
b) Media files migration
As a rule, media files are migrated to Magento 2 manually.
- Nevertheless, numerous Magento 1 stores keep their media files in a database. If this is your case, the media files will automatically move to Magento 2, yet they need to be synced prior to migrating the data. This is done like this:Backend menu of Magento 1 → System → Configuration → Advanced → System → “Synchronize”
- If you store your store’s media in file format, copy the media folder in Magento 1 to pub/media in Magento 2 like this:
1cp -r /path/to/m1/media /path/to/m2/pub
- Next, use these two commands to reindex and then recompile the Magento 2 store:
1php bin/magento indexer:reindex
1php bin/magento deploy:mode:set production
As a result, the Magento 2 store should now be fitted with all the products from Magento 1.
10. Make Tweaks
The store launch is not the end of development. Often you’ll need to make time for various tweaks, bug fixes, and feature requests from the stakeholders. Also, remember to put aside some resources for feedback and technical emergencies.
Estimate hours for the development & data migration stage:
Migration from Magento 1 to Magento 2: Duration Estimates (Total)
|The Planning Stage||40-60 hours|
|Putting together a CJM||30-40 hours|
|UX and UI (mobile/tablet/desktop design)||120-250 hours|
|Frontend and backend work, data migration, and post-release work||640-800 hours (which is 4-5 months)|
|Grand Total:||Approximately 830- hours (which is 4-7 months)|
3. What Can Go Sideways: Common Migration Challenges & Post-Migration Issues
Still wondering how easy is upgrading from Magento 1 to Magento 2? Well, not easy at all! First, let’s see which 3 challenges can slow you down and even become roadblocks during the migration progress.
All steps of the migration can be challenging but most of the time we have to deal with 3.
1. Architectural Challenges
The release of Magento 1 was in March 2008. That’s over 10 years ago. In software terms, that’s ages. Since then, PHP alone went through 2 major releases. New libraries and technologies have appeared and replaced what Magento 1 uses.
Magento 2 is a completely different platform. The team who released it in 2015 reworked a lot of the Magento 1 codebase. They created a weird mix of old and new pieces that are extremely different from what Magento 1 is.
2. Compatibility Challenges
Magento 2 extensions are not compatible with Magento 1 and vice versa. There are so many differences, that you basically need to build a brand new extension from the ground up. As you might imagine, building a new piece of software is both time-consuming and expensive. And unless you can find the same extension at the Magento Marketplace, you are out of options. You have to create a new extension.
And it gets even more complicated since the more extensions you have, the more compatibility conflicts you get. Sorting them out is a long and expensive process. It involves testing, debugging, and more testing.
3. Migration Team Challenges
Let’s face it, Magento 1 and Magento 2 are so different they might as well be two separate products. An experienced Magento 1 developer will have to learn how to code for Magento 2 almost from 0.
This also means that it’s hard to find a competent Magento migration team. These developers need to know both Magento 1 and Magento 2 extremely well. They must understand how both platforms work and where their differences are.
As you see, moving from Magento 1 to Magento 2 can be a tough project. However, after you’ve migrated your M1 store data, modules, and custom functionality, you still have a lot of work. It’s easy to underestimate the challenges you are up against after you’ve moved from Magento 1 to Magento 2. Let’s go over the main ones.
1. Magento Performance Issues
Performance issues are common if an inexperienced team moves the store from M1 to M2. The latest version of the platform has its own share of quirks and unclear mechanics. They can turn into a stumbling block if you have no idea what you are doing.
Some of the most popular challenges our clients face include:
- insufficient speed in Magento 2 Admin areas;
- unacceptable search speed;
- unoptimized cache configuration;
- inefficient database setups;
- poor cron schedules;
- low store reliability, etc.
Solution: just looking at this list can be intimidating. But it absolutely doesn’t have to be. The Onilab team created a comprehensive Magento 2 Performance Guide. It’ll walk you through all the rough patches of Magento 2 optimization. It’s a helpful read that’s complete with code examples and actionable instructions that you can use right away.
Setup Redis and Varnish cache, optimize and tweak your JS code, work on your media delivery. Other tips include the use of smart scripts to improve perceived performance, and more. We’ve compiled the most efficient Magento speed optimization techniques to boost your store’s speed.
2. Magento 2 Security Issues
The Magento 2 default setup offers the best level of security. This is the main reason why stores with different customization levels should move from Magento 1 to Magento 2.
In fact, you don’t need to configure your new Magento 2 store to secure it more. The default functionality of the platform already has all the features for advanced security. For example, enhanced password management or defense from XSS-attacks. Nevertheless, we’ve included security issues in our list of Magento migration challenges. Why?
The main security threat for Magento 2 websites is third-party modules. Some custom modules can be real roadblocks for both website performance and security. This is due to the pivotal issues that have occurred because of unoptimized code.
Solution: to prevent the loopholes in Magento 2 modules, we recommend purchasing them from trustworthy third-party vendors. Alternatively, you can address Magento experts to develop custom modules for your store. From this perspective, you will be able to eliminate the risks of installing unoptimized extensions.
Besides, you can fix the critical issues overlooked by developers. You can perform debugging throughout every extension using a debug tool of your choice.
For more information on your store security read our comprehensive Magento 2 security guide. These 20 easy-to-follow security tips will make your Magento 2 store a real fortress of data. Optionally, you can get a complete security audit from our security devs.
3. Magento 2 UI/UX Issues
Out of the box, Magento 2 offers a feeble user experience. The default M2 theme, “Luma”, is far from being personable and attractive. Even though the skin was designed to be mobile-friendly, it was primarily made for demonstration purposes. Besides, default Magento 2 is still lacking some crucial shipping and other features.
If you want your store to look stunning, be user-friendly, and conversive, your site will need unique customization. This includes buying a new Magento 2 layout and some modules to make navigation perfect and improve user experience. However, buying an expensive theme, or installing all third-party functional modules, won’t guarantee you great UX/UI.
Solution: the only solution here is to think through your Magento 2 store’s UX/UI before the execution phase. Do not ignore customer journey mapping and consult with professional designers. This way, you’ll make sure that a function or theme that you’ll apply corresponds with your target audience requirements.
4. Magento 2 SEO Issues
Upgrading Magento 1 to 2 is a challenge that requires a lot of hard work in the SEO department. The biggest questions here are:
- loss of PageRank due to the redesign and changing URLs;
- lack of redirects that point from old to new pages;
- duplicate content due to bad robots.txt screening (filters, sorting, categories, etc.);
- localization and multi-store SEO issues.
Solution: don’t underestimate the importance of SEO in your store migration. Be prepared that you will lose positions in Google results. It’s inevitable with a large-scale store. Your goal is to mitigate the damage and rebuild as fast as possible.
Read our Magento duplicate content guide on how to deal with the issue. It includes tips on creating a robots.txt file that actually makes sense and on improving user behavior.
5. Other Issues That Can Occur After You Migrate to Magento 2
Topping that, you can come across a bunch of other issues post your M2 migration. Here are a couple of examples. For instance, you may come to find numerous category pages or landing pages empty. This sometimes occurs if your CMS syntax isn’t right.
On top of that, there are cases when products are missing on category pages. Re-indexing can fix this.
Similarly, your media files, including images, can vanish partially after the migration. You may make things right by caching your pictures.
As you can see, there may be many unexpected turns after you’ve moved from Magento 1. As long as you have an experienced team to fix things up, you’re good to go.
There you have it, the most definitive Magento Migration Guide on the Web. The goal of this article is to inform you about the scope of a Magento 2 migration process and to direct you to a thorough guide where you can learn more about a specific issue.
And if you need help with a certain migration issue or would like to ask us a question about our Magento 2 migration experience, we’d be glad to help!