In this article we describe the real case – the migration of data from the Magento 1 platform to Magento 2 which we conducted as part of the development of a new project on Magento 2 for our client. We tried to talk about all the situations that we had to deal with and as Google search shows the same problems happen to most developers who migrated from Magento 1 to Magento 2.
I Already Have A Working Store on Magento 1, Why Should I Upgrade to Magento 2?
Ben Marks – Magento evangelist, certified trainer, and expert in eCommerce, said in his Twitter account that in November 2018 Magento 1 will cease to be supported and you need to upgrade to the second version of this wonderful eCommerce platform as early as possible.
What Does It Mean?
Stop development and support for the first version of the platform, release new releases, develop functions and modules. Documentation support. Termination of security patches. Most likely, at some point in time, you will be left alone with the vulnerabilities that will be on your site. Perhaps you will say that not everyone will or will want to go to the second version of Magento and a community will be formed that will support the first version of the platform, but you are right, but so far it has not happened, and it is not known how long it will take for this community to form.
We will not consider the strengths or weaknesses of any of the platforms and also list some statistical data. In this article, only the real experience that we got as a result of yet another migration, as well as problems and their solutions. Most likely, in the same situation, you can solve these problems, somehow differently, or they will not arise at all.
Before we start, I would like to write that the migration utility itself, which we will use, works well with the correct data that should be in the source – Magento 1. Developers when designing the utility took the test data into account, which you can find and download from the official website of Magento. Therefore, all you need to do when an error occurs is to adjust the data in the tables of your Magento 1 and thereby restore its correctness and create the same conditions in which the migration utility works fine.
What You Need To Prepare for
If you have modules (for example – a blog) that add tables to the store database – you need to add them to the exception list.
If you have modules that modify the structure of system tables, it can be: changing the field type or adding a new field – you need to add them to the exclusion or modification list.
There are errors that are difficult to diagnose and you probably do not know about, since these errors are associated with incorrect data that could appear as a result of the work of a module that was written badly enough, interference with the structure of the tables from the support service or the developer, who is poorly versed in how the platform works.
The Most Important
If an error occurs and fixes it, you will need to restore the Magento 2 database from the backup and then the migration process will be faster.
Why is it necessary to restore the database every time?
At the time of the error, the script-utility stops its execution in a certain place – where the error occurred, the data in the tables is saved. Therefore, you have a high probability of getting the same error or associated with it and then spending a lot of time on research and not achieving the desired result. The correct and fast solution is to restore the database.
At what point do I need to make an archive copy of the database?
Immediately after installation and first setup of Magento 2.
Install The Migration Tool
Information and
step-by-step guide v2.2 is available on the official site where you can get acquainted with all the opportunities and prepare for migration.
During the process, you will have to deal with some nuances that are not described in the documentation. But most solutions can be found on the Internet.
If you have installed many modules that have made changes to the structure of the tables, then with a probability of 99% there will be certain difficulties that you will have to solve already in the process. Basically, this exception / addition of the columns of certain tables to the migration script configuration files, as well as fixing errors related mainly to the core_url_rewrite (more often) and customer_entity (less often) tables, most likely there are other errors, but in our case, with whom they dealt.
Installation from the console
$ composer config repositories.data-migration-tool git https://github.com/magento/data-migration-tool
$ composer require magento/data-migration-tool:2.2.0
After Executing The Command, You Probably Get Such A Message
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.2.0): Downloading (100%)
Package sjparkinson/static-review is abandoned, you should avoid using it. Use phpro/grumphp instead.
Writing lock file
Generating autoload files
Solution
- Remove the package composer remove sjparkinson / static-review
- Install composer require phpro / grumphp (At the time of installation, the required version of PHP 7.1 If you use version 7.0 you will need to update PHP and all modules with this can be conflicts and installing / adapting this package may take a lot of time). I did not install this package, so you can skip installing it too. This package is another tool for those who monitor the quality of the code. If you just need to migrate data, you can ignore it.
Preparing The Configuration
We need to choose from which version of Magento we will migrate, in our case this is Magento 1.8.0.0 CE -> Magento 2.2.3 CE
$ cd vendor/magento/data-migration-tool/etc/opensource-to-opensource
Available options: Commerce to Commerce (Enterprise Edition), Community Edition to Enterprise Edition and Commerce to Commerce (Community Edition).
How to check or know the current version of Magento?
You can view the version of CMS Magento at the very bottom of the page - the admin panel, the version of CMS with which we will migrate the data – 1.8.0.0
Next, we need to go to the directory where the files will be: config.xml.dist, map.xml.dist
$ cd vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.8.0.0/
The config.xml file is the renamed config.xml.dist, it is the main one in the migration configuration, it contains information about the source and receiver database, and also in other
configuration files, this basically refers to the names of the tables and fields, what to do with the values in the migration process.
Configuration files tell the migration tool which tables and fields to exclude or to invoke, or to convert during the migration process. If you are not familiar with this project, then most likely you do not know the contents of all the tables and data that you need to include or exclude from the migration. Therefore, in my opinion, the right decision will be to study all the links in the migration process, first we need to make an archival copy of the existing database on both projects.
As a tool for working with archiving and restoring data, as well as creating users and other necessary trivia, I use the tool
n98-magerun2.phar.
Migration of Configuration
Includes settings, information about the store, languages, currencies. To start the process, you need to run a command.
$ php bin/magento migrate:settings [-r|--reset] {}
Note that the execution of the command takes place in the working folder of the project on Magento 2.
Migrating of Data
From the data migration, I eliminated the Log Step step, since we do not use these statistics and as a rule, these tables can be one of the largest and occupy gigabytes of information, therefore the import process can drag on for a very, very long time. You can import this data after how the migration process is completed successfully and you will have the time.
Problems with Tables And Attributes
The migration script compares the tables in the source and destination (Source & Destination) if they differ, then you will see a message about it. Do not worry about this, just add these tables, columns and attributes to the stop list
/vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.8.0.0/map.xml
The source is in the source section, the receiver in the destination section.
If there are many tables whose names start alike and that you do not add a large number of almost identical rules, you can create generic rules of type
then the migration utility will skip all tables that start on magefan_ and on magestore_
Error in Attribute Classpath
[ERROR]: Class eav/entity_attribute_source_boolean does not exist but mentioned in: eav_attribute.source_model for attribute_id=135
A fairly common mistake, and it is solved by deleting existing values in the eav_attribute_set table in Magento 2.
But, in fact, the deletion of records is made by the migration script, when you restart it with the -r option from the console and the next error is approximately Undefined offset 1.
There is a great chance to spend a very long time looking for a solution to this problem, to do everything quickly, you need after the error to restore the database for Magento 2 from the backup and start the migration process again.
Address migration error (URL core_url_rewrite) Duplicate entry "requires path"
The reason for the error is the same as with the import of clients (see below) is solved by removing duplicate records from the core_url_rewrite table.
Error Migrating / Importing of Clients
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'test@test.com-3' for key 'CUSTOMER_ENTITY_EMAIL_WEBSITE_ID'
If you open the customer_entity table in the project database on Magento 1 and filter the mail address that you have in error, you can see the backed up accounts. Most likely, this data was created as a result of some kind of error, since there can not be two identical e-mail addresses for one website. If you find two identical email addresses for one website, one of them needs to be deleted, this is definitely an error.
Another Error Integrity Constraint Violation: 1062 Duplicate Entry '0' for Key 'PRIMARY'
In the process of importing user groups, you get a duplicate record error. It helps increase the limit for adding records, find the bulk_size parameter in the vendor / magento / data-migration-tool / etc / opensource-to-opensource / 1.8.0.0 / config.xml file, which you want to increase to 100 in principle, and more, all depends on how powerful your computer / server is.
I tried to set to 500, but still got an error, the value of 100 is in my opinion the most optimal.
If You Have A Version of PHP 7.1.0 And Newer
Most likely you will see an error
A non well formed numeric value encountered.
Fixing the error file /vendor/magento/data-migration-tool/src/Migration/ResourceModel/AbstractResource.php line 224
Error While Opening The Goods in The Admin Panel
When you open the products in the admin panel instead of the information about the attributes we see the message Unable to unserialize value
It is connected with the fact that the values are already serialized. The network has a solution, but in my case, it had to be recycled.
In the vendor / magento / framework / Serialize / Serializer / Json.php file, this is probably 50 lines, there is a function below its changed form. In my opinion, it is the most optimal and 100% working.
A Short Description of This Code
Before decoding the data, I check to see if the data was previously serialized and if so, I check whether the result is an array. If this is an array, then we convert it to a JSON array.
Conclusion
The migration process for each project can be both simple and complex, it all depends on the state of the data in the project database, whether there are errors in them, and also how much information needs to be transferred. Basically, all the actions are to adjust the tables for correct import, so be ready and keep a backup at your fingertips.
