Scroll to top
Get In Touch
80 M St SE, Washington, DC 20003,
Ph: +1.202.596.5360‬
Work Inquiries
Contact Us

Part 2: How To Perform A Successful Migration From Magento 1 To Magento 2


Continuing with the topic of migrating an existing store in the Magento 1 version to the Magento 2 version, if you have not yet been able to review part 1 of this article, I invite you to do it right now from this link: How to make a successful migration from MAGENTO 1 to MAGENTO 2 part 1

In this second part I will focus on the tool that the Magento people have created for the migration of data from a database of a Magento 1 store to a clean Magento 2 database, which in a summary way I will tell you what What this tool achieves is to bring the most relevant information from a platform like Magento, which is the data of the clients as well as the users, their groups as well as the products, product categories, even attributes and even the existing orders , there are some other features like most of the configurations that for those of us who know about the table structure we will correctly remember the configuration table called core_config_data,The tool will try to take the largest number of data records that can be compatible between both structures, and all this with the purpose that the migration process can be less, and some of the characteristics that were not integrated from one version to another. and they are important in Magento 2 we will have to do them manually and in some cases check to see that it corresponds since you would be surprised to see that many of the functionalities that were tedious and rudimentary now in the new version of Magento 2 will not be necessary nor will there be a need to take them in account. You may have to manually add some of the essential features of your site that were not integrated from Magento 1 to Magento 2. Check to see what corresponds since you would be surprised to see that many of the functionalities that were tedious and rudimentary in Magento 1 may not be necessary for Magento 2.



Migration requirements

Having managed to list each of the points defined in the code audit, we concluded that we would already have a list of migration requirements. If we comply with each of the issues specified up to this point, we could say that we can continue with the migration. By way of summary, the final list that we should have fulfilled is the following:

    • Changes to the Magento Core have been resolved with custom modules and extensions.
    • Any business logic found to be embedded in templates has been resolved by sending it to block classes in communication with controller classes.
    • All third-party extensions that were found and that the new version has been obtained from the same provider.
    • All third-party extensions that could not be found or obtained a compatible version for Magento2, where the update to the new version had to be developed by the development team assigned for the migration.
    • All the custom extensions requested by your store or client are accounted for.
    • Having managed to completely uninstall all the extensions that were disabled without causing a malfunction in any component of the store, including the store itself completely.
    • Locate all the custom JavaScript prepared and ready to take it to the new technology of requireJS for Magento 2.
    • And finally, if there are custom plug-ins, find the version for Magento 2. If it was a custom plug-in or a custom feature requested by the client for their store, be sure to document it. Additionally, be sure to have the respective CSS ready. Once the project is migrated, the theme will be generated from the new Magento 2 installation. Remember that, as mentioned in the previous article, it is relatively simple to migrate a theme from the base Magento blank theme.

If each of the previous points is complete and validated, we can proceed to the next step.

Update current version of Magento 1

Perhaps this point seems not very necessary but it is crucial that we guarantee that what we will migrate will be a store out of anomalies and lousy development practices on the part of those who developed the store that is being migrated, with this I do not mean that any project that this fact in version 1 of Magento has to be wrong, I have gone through a good number of projects from small to large magnitudes of development with hundreds even thousands of lines of code and bad practices were always present in almost 99% of the implementations, even myself when I started in the development of Magento 1 and could not apply the standard of the definition of Magento try to use my own development logic of course that over time it makes the performance of a platform drop as it is Magento,Thanks to the renewed and revolutionary Magento 2, all those bad practices will remain in the past, it is clear that this is not exempt from happening but now those of us who are in charge of coordinating and directing the project have more options to detect any lousy practice so we can be on time and better form a quality code.

Once an update of the Magento 1 version is carried out, which will be migrated to the latest version and this leaves it free at the discretion of each developer since if we remember, there were different ways to migrate a Magento 1 store, for example, 1.8 to 1.9, it could normally be done from the backend itself or many like me will do it from the command line by executing the installation command (install path_magento Mage_All_Latest –force) of course, having executed the cache cleaning folder permissions and re-indexing the project will be updated to the latest version available.

If all of the above steps have been completed, we can be all but certain that the migration can also be a success.

Using the Magento data migration tool

As I have commented in the introduction, the data migration tool that Magento has created and has made available to those who need to migrate a store to the new version 2 of Magento will allow us to take the data from a MySQL database from a store that is already in production to a clean store MySQL database where we can transparently reuse all that information, and this is an excellent contribution since it will allow us to avoid using other ways to migrate that data.

The first thing we should know is where this migration tool is located. You should obtain it directly on Github. Use this link: -tool. Be sure to review the in detail as some annotations are being added that will help us, even more, to migrate the information more safely and to guarantee improved performance.

It is important to mention that as of today, the versions that are compatible for migration are the following:

For the Magento Community Edition version:

  • 1.6.x
  • 1.7.x
  • 1.8.x
  • 1.9.x

For Magento Enterprise Edition version:

  • 1.11.x
  • 1.12.x
  • 1.13.x
  • 1.14.x

As we can see, they are almost all the latest versions.

Preparations for migration

I am going to place a point on the migration preparations since I will mention which is the most comfortable way to do it since this will allow us to be able to execute the actions with complete safety without affecting the current project of the public production store.

I am going to list a series of steps to follow to achieve these preparations:

  1. Mount locally a server system like XAMPP, WAMP, WinNMP
  2. Perform a Magento 1 installation with the store to be migrated
  3. Perform a clean Magento 2 installation
    1. Make sure you have the PHP 7 language
  4. Install Data Migration Tool on a clean install of Magento 2

1.- Mount a server system such as XAMPP, WAMP, WinNMP locally

What we need is to work the migration locally so as not to interfere with the project of the store that is in production, this gives greater security and the guideline to be able to repeat the process safely, so I recommend installing either in Window or Linux any of the existing tools, in my case I use WinNMP for Windows since it allows me to maintain different environments with different versions of the PHP programming languages to meet the requirements of each version, both for Magento 1 that runs on 5.x as well as Magento 2 that it is suggested to run it with version 7.x

2.- Carry out a Magento 1 installation with the store to be migrated

Once we have installed our server environment emulation application, we are going to proceed to install the Magento 1 project locally with the necessary requirements to achieve the same replica of what is in production, so for this process, it is essential to accomplish in the first part, access to the repository of the project’s source code to clone it locally or, failing that, a compressed file of the source code of the entire production project to have it locally, and in the second part, a copy of the database of production to install it locally, all this in order to have a replica of a local environment of such a public project.

Magento 1 has the PHP 5.x language version as if we try to do an installation with any of the recommended tools and it contains a more up-to-date version, it may probably have problems to build the environment, that is why I use the WinNMP tool since it is for me It will allow you to choose between different versions of the language both 5 and 7.

This installation will allow us to emulate how our production store would look once the entire list of installation requirements reviewed previously has been applied.

3.- Perform a clean Magento 2 installation

To perform an installation from scratch, it is worth mentioning that the Magento 2 cron system mustn’t be enabled; if you are working in Windows, there would be no problem since, by default, they are disabled; if you are working with Linux, it is easy to remove the cron table using the command line to disable only Magento ones.

This clean installation of Magento 2 is what we need to prepare so that it is ready and represents the new version of Magento 2 already migrated with all the data from version 1 of Magento.

3.1.- Make sure you have the PHP 7 language

This practice could be carried out in many ways. I have even seen that some developers carry out two installations with different versions to work in their local environments. This is left to the consideration of each one, what if the processes are being carried out locally to avoid moving or work directly in an instance in the cloud and even in the same productive store, so with this scheme we can carry out the necessary tests even if at one point it fails due to a problem we can repeat the process without any problem.

I use the WinNMP tool that allows me different containers for different projects with PHP languages in versions 5 and 7. It is straightforward to turn on and off one or another project. I can review the code audit issue of the current store as well as the migration to the new Magento platform.

4.- Install the Data Migration tool in the clean installation of Magento 2

Finally, we have reached the part of the installation of the tool for which it is necessary to have the clean installation-ready and running since this is where the tool that will be in charge of moving the data from the version 1 database will be mounted to the new version 2.

The tool is located at the URL mentioned above at the URL, a project on GitHub. Still, before downloading the project, it is necessary to validate the latest version as this is important later in the data migration part, for which we will go to the URL of the project reads at this URL  when we enter the league, it will show us the corduroy of the tool with the latest version available, it is important that we take into account that number like the one shown below:

At the time of creating this article, the latest version was 2.3.4. It will probably change over time once noted, and having that key number, we will be able to install the tool project, but first, it is important to verify if we have the composer tool already installed. If not, it is necessary to install it before continuing with the next command. And since it is not part of this article to talk about composer, only to comment that it is very easy to install this application, go to its official page, download the package and install it like any Windows application if it is Linux, only with a command line it would be installed.

In order to download the tool and have it in the clean Magento installation, it is important to execute two commands in the main path of the project, which is the following:

The first command tells the composer is to assign a download repository to its configuration

The second command is the one that is responsible for downloading from the repository already defined the tool package, specifically with the latest version previously described in this case, 2.3.4

Up to this point, it is important that you know that you will need the credentials for downloading packages from the official Magento repositories from the Magento side, for which it is important to already have an access account on the site. I believe that all We have had contact with Magento and we should already know all this about the credentials and even already have a registration on the official page, if you need to know more about how to obtain these credentials, I invite you to review the categories of the site, you will surely find something about it.

Assuming that we already have the download credentials for the Magento repositories, what we will have to do once the second command is executed will not ask for the two authorization credentials such as username and password, so we are going to place them at the end of the process and the tool will have been downloaded in the clean Magento 2 project it would be ready to use.

Setting up the Data Migration tool

At this point, there are few steps we must do, but first, we must validate the issue of versions and more than anything here, we must identify which version we are trying to migrate from, for example, if the Magento 1 store is version 1.9. 4 community edition and we are going to migrate it to Magento 2 in version 2.3 community edition (Open source) take into account that today Magento is calling its new version of CE Open source so here we are going to define a symbolic definition to identify the versions and this is clearer, in the end, it is only to know in which folder of the migration tool to work:

  • Magento 1 Community Edition = ce
  • Magento 1 Enterprise Edition = ee
  • Magento 2 Community Edition = ce
  • Magento 2 Enterprise Edition = ee

Now, if we talk about migrating a ce to ce then there will be a folder called ce-to-ce, and within this folder, there will be all the versions of the store to migrate. For example, in my case of the exercise, I will find a folder, and ¿ What is the use of knowing this? This is very important because this is where we must go to make the migration configurations, and where are these folders physically located? When we downloaded the migration tool, what really happened is that all the necessary folders and files of the tool were downloaded, located in the vendor / magento / data-migration-tool / ce-to-ce path of our clean installation of Magento 2, this is where we have to go to make some modifications and configurations to a couple of files, And if you ask yourself, but what happened to the golden rule that the CORE is not played? Well, here is an exception. When migrating, it will be necessary to move a couple of configuration files but see in this way. This task will only serve you for a migration at the end of which you manage to carry out all the migration. This tool should be removed simply by removing the library by complete there is no need for it to be there, so the Magento CORE will remain as is without any change.

If we look a little at the content of the mentioned folder, we will realize that in the first part, we will find a series of XML files all with the ending .dist and this is because they have been placed there just to be able to use, those that we need to migrate as well as a couple of folders but the one we must focus on is the version folder in my case, which is where the configuration XML file that we need to update will be found.

When entering the folder, we will find XML files such as config, map, and map-tier-price, the file that we need to update to be able to execute the data migration is the one that has the name config, so it is necessary or make a copy of the same or rename the existing config.xml.dist to just config.xml.

Once the file name has been changed, we have to update the new config.xml file, so it will be necessary to open the file with a code editor. The idea is to locate a couple of XML tags and add information.

The first node that we need to find will be the node. This node is in charge of defining the data of the source database. In this case, we would be talking about the Magento 1 store, so we would only have to place the connection data. It is worth mentioning that within the source node, there are the attributes host that refers to the database server, the name that refers to the name of the database, and user that indicates the connection user of the database, but that It happens with the password since as such the attribute is not defined so we have to add one more attribute that would be password and this is where we would place the database password.

Now let’s move on to the next node, and this will be the node; and in order to configure this node, it is important to locate a file from the Magento 1 store located in the path apt / etc / loca.xml , we will have to open this file or locate the node that will be found inside the tag followed by followed by and inside will be the node in which there will be an alphanumeric string composed of numbers and letters like this that this is the one we need to copy and paste in the node of our Magento 2 installation.

MAPEO XML files of data

Once we have the configuration ready with the updated data in config.xml, it is time to verify what mapping files we have. These mapping XML files are the ones that are available for possible migration from the Magento 1 project tables to tables of the Magento 2 project. This refers to the fact that through these configuration XML files, the information of the existing data of the previous version of Magento 1 can be structured, indicating, for example, how the tables of the Magento 1 catalog are structured.roducts what are their attributes and what are their probable entities relationship once with that information the tool can know how to move and where the data to the new Magento 2 data model.

So you can review each of the XML files and validate which you can migrate to the new platform. In these XML files we could say that they are grouped in:

  • GENERAL: what will be all the class mapping between Magento 1 and Magento 2, all the configuration files, the definition of routine configuration tables, and one of the important tables the core_config_data here is where it is in the XML settings.xml
  • EAV: eav data model entity attribute value this is where the attribute list and table list will be defined
  • LOG: the log configuration mapping and table log list
  • MAP: mapping files
  • CUSTOMER ATTRIBUTES: attribute tables and list of tables
  • OTHERS: here, you will find the definition of the tables of the OrderGrids, SalesOrder everything related to the orders.

Here I am going to mention how you should work with this process and it is probably tedious, but it is important that you try to bring the largest if not the total data to the new version of Magento data, so it will be necessary to rename each one little by little. The groups changing the names of the XML files removing the ending .dist, but this is not the whole story since even changing the name, the migration tool will not know the name of the XML name that it must take into account in its migration process like this Besides changing the name, it is important that within the config.xml file in the node the name of the file to be mapped is indicated. XML must match exactly so that the tool can locate it and take it into account.

Getting started with data migration

Once we have everything ready and configured, the first thing we must do is execute a series of commands from the main path of the Magento 2 project, so the first command to execute is the following:

php bin / magento migrate: settings 

In my case, the file that I configure for version would be located in the path:  vendor / magento / data-migration-tool / etc / ce-to-ce / / config.xml so the previous command is would run as follows:

php bin / magento migrate: settings vendor / magento / data-migration-tool / etc / ce-to-ce / / config.xml

When executing this command, the configuration file is upgraded to support Magento 2.

Now let’s move on to what is truly expected of this entire article, and it is to the last command for migration of the rest of the data to the new Magento 2 database, which of course, if we had not done all of the above we could not execute this last migration command to which we need to run:

php bin / magento migrate: data 

As we can see, it is exactly the same as the previous one, unlike in this one we would be changing the settings command to data so it would be as follows:

php bin / magento migrate: data vendor / magento / data-migration-tool / etc / ce-to-ce / / config.xml

Once this command is executed here, we should wait a little longer since this process will take time with respect to different factors such as the amount of data to migrate as well as the speed of our local environment.

Well, so far, we could say that we have already finished a successful migration if, at the end of the execution of the command, it indicates that it was successful, we could see that the result is not as expected but this is where we can go trying to configure the largest number of Mapping files for importing data tables and settings.

There is one more point that I want to comment on and that is that it has happened to me in the project that their production flows continue, so in these cases, the database was not frozen since the migration teams began to work on performing all the actions to achieve the data migration and during that period the productive database was updated, suppose that we already have a successful migration in the local environment and it is ready to represent the new productive version of the project, but up to this point there is already new data in the previous Magento 1 store, in this case, we would not have to re-execute the configuration migration command (settings) nor the data one (data) for this case, only a command that only It will update the new data that is not in the latest version already migrated for which there is the delta command:

php bin / magento migrate: delta vendor / magento / data-migration-tool / etc / ce-to-ce / / config.xml

As the previous commands indicating the path of the configuration XML file, this delta command will only help us to migrate the difference of data to the newly migrated version ready for production in Magento 2.

Once each of those steps is done, your Magento 1 instance should be fully migrated.  This is where your Quality Assurance team should inspect the functionality and User Experience (UX) of the site.  After resolving each of the issues they found, it’s time to begin optimizing your Magento site for speed and SEO.  We’ll be creating a post on server optimizations.  Until then, happy coding…

Author avatar

Post a comment