💡 Before you start - download your free copy of the Ultimate Guide to Optimizing Magento 2 Speed . Benefit from Top 10 proven strategies to improve web store performance, and optimize page loading speeds - selected by our Senior Magento Developers.

It is necessary to carefully look at the database, the modules used, any integration with external systems, or additional scripts using the Magento database. And there can be a lot of them! An interesting example is a script run from CRON, which downloaded discount codes from Magento for suitably expensive orders, and then sent them to the internal system in the customer's office. This started the process of printing a card with a discount code, which was then attached to the package with the order. We have a lot of things to check, so you should devote enough time to this process, not just "have a look" (and get into some serious trouble).

What is essential

First step: make sure the target server meets the requirements of Magento 2 (memory capacity, PHP versions, databases, access to ElasticSearch required from version 2.4.0). We must be 100% sure that Magento 2 will start without a problem. Of course, we can use M2 in a weaker configuration than the one presented in the official requirements, but the Data Migration Tool will not be so lenient when processing gigabytes of data.

When working for a client, we must remember to protect ourselves in the contract in case of any problems caused by Magento 1 modifications made while working on the migration. In other words, it should be clearly stated that any manipulations in the code or database (apart from normal use, of course), such as: installing/removing modules, modifying the database structure, attaching other external scripts or integrations, may result in the necessity to start the process from scratch.

Pros of migration

We know that support for Magento 1 ended a long time ago, and the migration to Magento 2 will allow us to continue to enjoy security patches, new functionalities, bug fixes, new modules and templates. However, the migration process is also a great opportunity for a cleanup, changes and improvements. Regardless of whether you are moving your own store or carrying out a project for a customer, it is worth taking the time to list all the functionalities of the current store and compare it with what Magento 2 offers “out of the box”. Then select the elements that must be on the new platform and those that we can abandon or replace with a newer, optimal solution.

It makes no sense to move modules that make no contribution to the business process ultimately. When cleaning, it is also worth considering the appearance of the store. Transferring a template from Magento 1 to Magento 2 will take the same time as creating a new template. This, in turn, gives great opportunities to refresh and modernize the graphic design, in order to adapt it to the current trends, taking into account, for example, data on user behavior collected by Google Analytics (thanks to which we can adapt the new graphic design to specific recipients, better distinguishing the most frequently used elements of the store, or changing the most popular flow to a more intuitive and easy to use). These are issues that need to be raised with the client while presenting alternatives and new ideas.

Data Migration Tool – ask politely and it will do anything

The basic tool is of course the official Data Migration Tool. It allows you to transfer data from different versions of Magento 1 to Magento 2. Thanks to this, we are not doomed to work with the latest versions only – the oldest version of Magento supported by Data Migration Tool is 1.6.0.0. This gives us a chance to show off and does not force us to take additional steps in the form of an update, which may bring more harm than good.

Data Migration Tool is very flexible and has great configuration options. It is worth reading its documentation carefully to save yourself problems with the table structure, or at least have peace of mind with manual data transfer. Migration Tool will transfer everything, you just need to "explain" how to do it. :)

Some people focus only on the basic mapping in the map.xml file, not using (or even not knowing about) the more advanced features. After all, if something doesn't move, we'll move it manually, right? :) Yes, this method can work, but it is ineffective, really error prone, and leaves us at a dead end when it's time to migrate the delta.

If we look at the config.xml file, we will find a list of all data migration steps, divided into 3 sections: settings, data and delta. As you can easily guess, each section corresponds to a separate migration process. Here, too, we can add our own steps, thanks to which we have much more possibilities in terms of manipulating the database structure and the data itself than when using map.xml alone. With a little practice, it will not be a problem to transfer the table from the old module to Magento 2, where the new module divides the information into several tables, changing the data types at the same time.

There are many ways to move the database, so I recommend to carefully read the Data Migration Tool documentation. These few hours of reading will save hundreds of hours of manual data migration and fixing errors.

Need backup!

As in any other case, also here, before starting work, remember about a backup – or even two of them! One, where all the work related to the configuration of the Data Migration Tool, database tweaks, migration testing etc. is done, and the second – to restore the original state when something goes wrong. With just a few clicks or commands on the command line, we're back to where we started (it's just easier than downloading everything from the server again).

Check the database

One of the first things we should do before proceeding with the migration, is to carefully check the Magento 1 database. Regardless of whether the store has been running flawlessly for years or we have recently corrected all reported errors, this step is necessary for the migration to be successful and its effects did not bring an avalanche of problems over time. We can never be sure if all the data is consistent or if somebody came up with the brilliant idea of fixing ​​"Integrity constraint violation" with "SET foreign_key_checks = 0" in some script, or that we won't come across other surprises.

These types of minor errors (with which Magento 1 works without a problem) can be catastrophic in Magento 2 and cause problems with editing some products, through missing order items (addresses, products), problems with checkout, customer login, and a complete lack of products in the store (broken indexers) or permanent "out of stock". A useful tool can be n98-magerun with EAV Cleaner. This won't fix all your problems, but at least can help clean up your attribute-related tables. All caught bugs should also be corrected on the current (Magento 1) production version – this usually prevents them from spreading further.

Check the core

In addition to cleaning the database, you should also check the core code of Magento 1. As in case of deviations in the database, also here we can not be 100% sure that no one has applied any changes to the code or unofficial patches. They do not always have to be dangerous to the migration process, but we cannot afford to be trusted on this point. Here the usual diff and code from the original Magento 1 installation may help (in the version we are migrating from, of course):

diff -urbB folder_z_oryginalnym_kodem folder_z_kodem_do_migracji | lsdiff 

This simple command will compare all files and list the ones that have been changed (ignoring comparing spaces or blank lines). Simple, effective and fast. If we get a list of files instead of no answer, unfortunately we have to check what the changes are and make sure that they do not affect the Magento data structure.

Cleanups and improvements

Let's expand on the issue of cleanups and improvements, raised at the beginning. It is not just about removing modules or finding new versions written for Magento 2.

First of all, we should look at each module in terms of business processes – does a given module have a positive effect on these processes or maybe negatively or completely neutral? For a few times I met a client who wanted a lot of advanced charts in the administration panel. Why? Well, not because he needed them, but because they looked "nice" and "professional" (interestingly, the administration panel was hardly ever used – products and orders data was synchronized with external applications). In other words, just because a module is installed and potentially used in some way (like displaying graphs) doesn't mean it actually has any practical use.

Sometimes it can only be an ornament or someone else's whim, and, thanks to migration, we have the opportunity to simply throw it away. Let us not only ask if a given module is used, but also for what purpose, which is applicable in this particular case – after a while it will turn out that the part is installed without much need (possibly in order to get acquainted with the module that wasn’t really used, but no one uninstalled it afterwards.)

Secondly, even if the modules have their versions for Magento 2, a whole bunch of better replacements could have appeared on the market already. It is worth taking a look at them, as a correctly configured Data Migration Tool will convert the data to a new format without any major problems, and the profit (stability, efficiency, additional functionalities) can be huge.

We should approach all external scripts that somehow modify or use data from Magento, in a similar way. Some of them are probably useful, but you can always find one that is not – it still runs in the background, consumes resources, maybe wreaks havoc on the database that we just fixed for smooth migration. It is worth trying to convert external scripts into modules for Magento 2, maintaining the rules and good practices related to creating add-ons for our platform. This way, the script will behave as M2 expects it, and we will gain the possibility of better integration, a number of built-in security and functionalities (such as a nice configuration page, instead of patting it directly in the code), we will not have to worry about changing passwords to databases in several places and we will configure the ACL.

Nothing prevents you from closing many smaller scripts in one module – we can configure several cron jobs as needed after all. Scripts triggered by HTTP requests can be replaced with new API endpoints, gaining additional security and the ability to configure access (including its quick blocking if necessary). Virtually everything we come across should be converted into additional modules, if the situation allows it, of course.

One more backup

I mentioned it already, but in this case "too much" does not mean "not healthy". Never forget about the backup – any migration attempt should be made on the backup first to make sure everything is working properly. It is not only about the "green light" from the migrator, but also about checking carefully whether each element in Magento 2 looks and functions as it should. There will be a lot of testing – from data structure, through cron and configuration, to all functionalities available to users and administrators.

Dry run

Once everything is working as it should, we can finally dry run using the production database. One may ask: if everything works, who needs the dry run? Let me tell you! When we were working on the migration on our copies, in the meantime a lot could have changed in the production base. Despite the removal of garbage from the database and repairing the relations between objects, a module could break something again, the data of some products and categories could change, and the customer himself could change something in the configuration or add some additions quickly without consulting us. Let's assume, however, that we have easily dealt with potential problems, or that errors have not appeared at all – then we can finally migrate the production database.

Media, links, ACL

Remember that not everything will be transferred automatically. Some data must be added to Magento 2 manually:

• media folder,
• administrator accounts,
• ACL settings.

Just copy the media to pub/media and everything should work out perfectly. Administrators can be added via the admin panel in Magento 2 or using the command line. We have to move the ACL settings manually, but it shouldn't take too long.

If all went well, we can start delta migration. This one should be run frequently, so that there is no need to transfer too much data at once. If any errors occur, it is much easier and faster to track them. We can set Delta Migration as a cronjob, preferably with sending notifications after the run is over.

Before finalizing the migration, we make sure that the link structure in Magento 2 is compatible with the structure of Magento 1. The easiest way to do this is by exporting sitemaps from both platforms and comparing them with each other. If necessary, we add the required redirects in Magento 2.

Finaly – the migration!

The migration should be finalized preferably during the hours of the lowest activity on the server – the fewer users will experience any inconvenience, the better. We should start by switching Magento 1 to "maintenance mode". Thanks to this, we will be sure that during the migration, no one will place a new order that could not be transferred. Then turn off all Magento 1 cronjobs – not only the typically ones, but also all external scripts that interact with Magento in some way. Wait a while for the already running cronjobs to finish their tasks (just check if the scripts are still on the list of processes). When all the scripts have finished their work, the final Delta Migration is launched to have a fully synchronized database in Magento 2. From here the path is very simple: add Magento 2 cronjobs to the crontab, clean the cache and run full reindexing. Change the settings, among others DNS and load balancers to point to the Magento 2 server.

At this point, our migration should be ready to use. Just in case, it is worth checking the basic functionalities to make sure that customers will be able to safely walk through the full path from entering the main page to the thank you page for placing the order. Also make sure all integrations are working properly, including all sorts of trackers like Google Analytics, FB Pixel etc.

As you can see, migration is not always a simple process and can cause many problems. We should spend the right amount of time analysing a given case – the more we know, the more we can do and protect ourselves from potential problems. Talks with the client about what should be on the new platform are necessary. We have to present alternative solutions, new ideas and properly explain everything (remember that the client is probably a "non-technical" person, so it is your responsibility to explain everything to him and clear up any doubts). Take this opportunity to improve the target product (Magento 2 store) to the limit. It's our job, after all… :)