Magento 2 Data Migration FAQs (Part II)

In case you missed, check out:

  • Magento 2 Data Migration FAQs -- Part I
  • Magento 2 Data Migration FAQs -- Part III

A couple of months ago, we shared our first Magento 2 Data Migration FAQs. It highlights 10 key questions about Magento data migration, information about migration tool and best practices for using it to migrate your data.

Today, I’m sharing 15 of the specific problems our users faced in their actual Magento migration projects, and how to deal with them. These typical issues might occur because some behaviour and logic of Magento 1 has been implemented differently in Magento 2.

I hope they’re as valuable for you as they’ve been for us. And you will have a solid preparation and make a smooth transition to Magento 2.

Magento Data Migration FAQs

Q. Couldn’t connect to Magento 1 database
If your Magento 1’s database is on a separate MySQL server from your Magento 2 instance, it is required to set up remote connection from your Magento 2’s server to your Magento 1’s MySQL. Learn how to set up remote connection from your Magento web note here.

In the meantime, you need to make sure your database credentials (host, port, username, password) are correct.

Q. Can this tool pull the CMS blocks and pages from the Magento 1 installation or do these have to be manually copied and pasted into the new Magento 2 installation?
No. UB Data Migration Pro migrates core Magento catalog-related data only:

  • Websites, Stores, Store Views
  • Product Attribute Sets, Product Attribute Groups, Product Attributes
  • Categories
  • Products
  • Customers
  • Sales data
  • Other Data (review, rating …)

You can view detailed list of data that our migration tool covers here.

Q. I am using UB Data Migration Pro version. I have migrated stores, attributes, categories, products and customers using that to my store. I can see products on admin section. I can even edit that too. But no products or categories available on front end.
Below are two common scenarios that cause the issue:

After running 9 standard steps in UB Data Migration Pro wizard, the data migration is not complete yet. You are still required to perform a few extra steps, including reindexing data. This is a step that you have to do manually via (CLI) Command Line Interface (The detailed instruction that comes with the UB Data Migration Pro package will guide you through all these required steps to complete the migration).

Also, Magento 1 data will be transferred to a separate root category in Magento 2. Make sure you set the new migrated category as the root category of default store of default website of your Magento 2 instance.

Q. Tier prices and group prices are not migrated
The core attribute ‘group_price’ was removed in Magento 2 in favor of Tier price. So, our migration tool automatically converts the Group Price to Tier Prices during migration.
Q. After successful migration, customers can not log in with their M1 credentials
UB Data Migration Pro automatically ports your customer credentials to Magento 2, so there’s no need to change or create new credentials at all. See how we did help Winetasting successfully migrate 324,000 customers to Magento 2.

If you have issues logging in with Magento 1 credentials after migration is complete, first of all, you need to make sure that such customer credentials are correct and can be logged in Magento 1 normally.

Besides, make sure that the migrated website was set to become the default website of your Magento 2 instance. Then all customers associated with such migrated website should be able to login normally.

Those are the most common reasons you might have trouble logging into with the Magento 1 credentials.

Q. Is it possible to merge the Customer data from our Magento 1.8 to Magento 2.x CE? The original developer did not migrate the data when he built the Magento 2 instance. We now have customer data on the Magento 2 site and need to merge our data from our Magento 1 site to our new site.
Yes, our migration tool allows to migrate Magento 1 customers into Magento 2 instance with existing customers.
Q. There are total 16,000 products. How much time it will take through command line any idea?
The duration depends on a number of factors, such as: the performance of your server, the product data itself (the number of configurable products being migrated vs. simple product), network bandwidth (if you proceed migration on a live staging server).

Generally speaking, it might take about 1.5 to 2 hours to complete, provided that you implement migration on a VPS / Cloud server with high performance SSD hard drives and RAM from 16 GB+, quad-core CPU.

Q. Twice .html in product urls: we are getting product url like that ”product-personalized-purple-668.html.html” after data migration. How can we resolve it?
This is due to the difference in algorithm developed in Magento 1 which is not compatible with Magento 2.

Our migration tool will automatically take care of this and check for a valid URL when migrating.

Q. In frontend, you can view product overall rating, but the problem becomes with each user review, there are no ratings in frontend.
Don’t worry, our migration tool fully ports all reviews and ratings to Magento 2.
Q. Mage2Salesrule: Discount Qty is too long (maximum is 12 characters)
How to find which item is causing this error?
The error displays because your source (Magento 1) database has some records of the ‘salesrule’ table with the value of the discount_qty field that are incompatible with the new rule of Magento 2 database.

To detect which item causes this error, you could run the SQL query in Magento 1’s database as follows:
SELECT * FROM `salesrule` WHERE LENGTH(`discount_qty`) > 12;

The same goes for other data objects, if you encounter similar types of error, for example:

  • Mage2StoreGroup: Code is too long (maximum is 32 characters)
  • Mage2SalesOrder: Customer Prefix is too long (maximum is 32 characters).
  • Mage2Website: Code is too long (maximum is 32 characters)
  • Mage2SalesOrderStatusHistory: Status is too long (maximum is 32 characters)
  • Mage2SalesOrderPayment: Cc Trans Id is too long (maximum is 32 characters)

Please note our UB Data Migration Pro automatically fixes all of these incompatible data when migrating.

Q. After migration, some fields from customer_address_entity table are showing as ‘unknown’
That was due to missing values of those attributes in the customer table which are required in Magento 2. As a result, our migration tool automatically fills with ‘N/A’ string as default value, to make sure that tables and fields are consistent between source (Magento 1) and destination (Magento 2) databases.
Q. I see the Unable to Unserialize value error that is probably related to Magento 2.2:  [2017-11-02 03:05:44] main.CRITICAL: Unable to unserialize value: a:1:{s:15:”authorize_cards”;a:1:{s:32:”91ebbdd5385d934250d3d4c084b0cb1e”;a:14: 
Since Magento 2.2.0, it includes security enhancements that requires some data to be converted from serialized data format to JSON encoded format.

Our migration tool automatically handles this data conversion, so you can rest assured that all your Magento 1 data stored in serialized format in some data sections will be converted to JSON format.

Q. When I try to save the category, it shows this error: URL key for specified store already exists.
We noticed that this is a common issue that occurs in Magento 1.7.x. Actually, it is an issue of Magento’s core with your migrated data which relates to some values of the url_key, url_path fields in specific migrated categories.

To fix this issue, we will review on case by case basis and suggest a workaround accordingly.

Q. All fields are previously checked by default, but if we hit the “next step” button, we have always this error which pop up “You have not selected data to migrate yet.”.
This issue might occur in step 3 (Migration Settings > Attributes) or 4 (Migration Settings > Categories) of our migration tool (If you’re new to our migration tool, learn more about 8 standard migration steps here). It relates to the PHP setting max_input_vars.

When your database has pretty large amount of attribute sets, attribute groups and attributes, it is required to increase the values of max_input_vars param.

You should set the max_input_vars value bigger than the total of attribute sets, attribute groups and attributes. Once done, restart your web server and you can continue the migration process normally then.

Q. Is there any case study about Magento data migration projects that I can check out further?
Yes, here are a few case studies of successful Magento data migration projects using our migration tool:

Written By

Comments