Magento 2 Data Migration FAQs (Part III)

In 2018, there has been an increase in the number of e-commerce stores that carry out Magento migration. We believe this number would continue to rise in 2019 due to upcoming Magento 1’s end of support. It’s no longer the question of ‘Should you migrate your Magento 1.x to Magento?’. It’s more about how you should do it and which migration tool you should use.

This Magento data migration FAQs Part III takes you through the frequently asked questions specific to our UB Data Migration Pro extension which were not covered in our Magento data migration FAQ Part 1 and Part 2.

This FAQs is aimed at helping you identify which is causing the errors that you might see at some point and the appropriate resolution.

Magento Data Migration FAQs

Q1. Today we are taking a look on rules migration, we cannot edit any migrated rule. It shows this error: Unable to unserialize value. It works properly with new rules, not the migrated one.
This circumstance occurred with a user who attempted to use our old UB Data Migration Pro v3.1.4 with the latest Magento 2.3.0 (Disclaimer: Upgrading to UB Data Migration Pro v3.1.7 is needed for compatibility with Magento 2.3.0).

After completing the first migration, the migrated sales rules were stored in serialized strings in accordance with Magento 2.2.x. Then the user upgraded his migrated instance to the latest Magento 2.3.0. However, due to the incomplete upgrade, those migrated sales rules were not converted to the new JSON format required by Magento 2.3.0. This was the reason of getting the error message above ‘Unable to unseriazlie value’.

Resolving the problem:
Upgrade to the latest UB Data Migration Pro v3.1.7 for compatibility with Magento 2.3.0, then run the delta migration with the CLI mode —update in Step 8 -- Migration Settings > Others.

Q2. I have the theme, home page and some inner pages already set up on the new Magento 2.x, does that affect the migration? We also have products already placed, but I guess I have to remove them before migration.
You can migrate data from your Magento 1 to your existing M2.x instance. However, in this context, you can not enable the Keep Original IDs setting available in UB Data Migration tool.

If you want to keep original IDs of specific data objects, there are two ways though:

  • Remove the sample products in your current M2 instance, then perform migrating as normal.
  • (If possible) Start a new fresh M2 instance to migrate from the ground up.
Q3. I need to be able to migrate 2 separate instances of Magento 1 into Magento 2.
UB Data Migration Pro allows you to migrate multiple Magento 1 databases into one Magento 2 instance. However, this refers to a special migration circumstance that needs a different migration workflow. If you are planning on migrating multiple instances of Magento 1 into Magento 2, you can drop us a line via info (at), we will provide a detailed instruction on how to do this.
Q4. We have moved on to importing customer data set, we have over 600,000 customer records. Currently we are seeing an import speed of around 100 customers every 2.28 minutes. This would mean it is going to take 9.5 days to import our customers.

Please can you tell me how long you expect this size import to take, and if less than our observed time, what we can do to improve the speed of the import. I have also observed that the status page appears to be sending around 20 to 30 requests a second to the server asking for the status. This seems aggressive considering it is managing to only do 100 in 2 minutes.

If you are migrating high volume of data into Magento 2, it is essential that you should start with a good server -- for instance, one with SSD hard disk, CPUs from 4 CPU cores @2.7 GHz, 16 GB RAM. Besides, you should enable PHP Memcached as indicated in the userguide of our migration tool.

In addition, you should perform migration using the CLI mode which is way faster. This also helps to avoid limitations on the maximum number of concurrent requests to server. In the example mentioned above, our user did perform data migration 10 times better by switching to the CLI mode alone.

Q5. I run full migration steps, clean the cache, then reindex. I got the error of Catalog Product Price indexer’s function:
No linked stock found
This situation occurred to only one specific user using the latest Pro v3.1.7. When troubleshooting, we found the root cause of the problem related to the Magento 2’s table inventory_stock_sales_channel as shown in this screenshot:

Magento Data Migration FAQs

It indicated that the database had 4 frontend websites with the website codes: base, base_migrated, dsc_migrated, jt_migrated. But there was only one record for the website code base in the table inventory_stock_sales_channel which was the root cause of the problem. This led to the Magento’s issue with the indexer process. Normally, those records should be automatically added by Magento 2 itself.

Workaround: Navigate to the Magento 2’s store management, simply open each website and click Save respectively, then the missing records should be automatically added by Magento 2.

Q6. We are using data migration tool Pro extension in one of Magento sites. Magento 1 site is setup in another server and magento 2 is in another server. Can I migrate the data in this scenario?
Can I use remote host in migration tool source database? If yes, how can I fill the source details with remote details?
Yes, it’s possible to migrate a Magento 1 database which is on another server. To perform this task, you need to enable a remote connection from your M2 server to M1’s MySQL server. More details about setting up a remote database connection are documented in this Magento DevDocs guideline.

Note: It’s strongly recommended that your Magento web server and database server are located on the same host to improve migration performance.

Q7. Does your migration tool supports Nginx server?
UB Data Migration Pro can be run on Apache or Nginx servers. For Nginx, you need additional configuration to make our migration tool ready for use. For more information, see the Readme manual packed with your download package.
Q8. I have a problem with url keys, I have French URLs on Spanish version of the website in frontend but they appear ok on product page.
In Magento 1, there was a URL rewrite index, but in Magento 2, this index is replaced by a new system to generate the URLs.

To resolve the url keys issue, you can utilize Magento 2 function to regenerate category and product URL rewrites as follows:

  • Step 1: Create a new temporary root category (eg. named ‘Temp Root Category’)
  • Step 2: On the Admin sidebar, tab Stores | (Settings) All Stores, edit the default Store of the default website and set Root Category to the newly added root category ‘Temp Root Category’. Then click Save Store.
  • Step 3: Navigate to the Stores | (Settings) All Stores once again, open the default Store of the default website and switch Root Category back to your main root category which you want to publish in the storefront. Then click Save Store. When complete, Magento 2 will automatically re-generate categories and associated products URLs rewrite for you.
    NOTE: Depending on number of the categories and associated products, auto-generating may take some time.
  • Step 4: Re-index the data and refresh the Magento cache.
Q9. Some products won’t save/update after migration. Some products are fine, but others when I try and update ANY kind of data, when I save the product I get DateTime::__construct(): Failed to parse time string (31/03/2014) at position 0 (3): Unexpected character error and the product won’t update.

Create a new product is fine. Some products save and update OK but most don’t.

The issue occurred due to the different datetime format for admin user. When logging in with a testing account ‘ub’, the date & time was in the format MM/DD/YY:

Magento Data Migration FAQs

However, under the ‘admin’ account that user provided, the date & time was in a different format: DD/MM/YY (this format wasn’t allowed by MySQL)

Workaround: Update the locale setting to set the Date & Time format to MM/DD/YY.

Q10. How to edit the source and destination databases in UB Data Migration Pro
After you have installed UB Data Migration Pro extension, the destination M2 database is auto-filled, you just need to set up Magento 1 database configuration (in Step 1 — Migration Settings > Databases).

If you move this M2 instance with our migration tool installed to a new server, make sure you check and update your M1 and M2 site credentials which include MySQL Host Name, Port, Database name, MySQL Username, MySQL Password accordingly. The database configuration details is in a file at: pub/ub-tool/protected/config/db.php

Q11. Can you please tell me if during a delta migration, products, orders, customer that have been changed while developing are updated. Eg : if I modify a, already existing product informations or if orders status change.
The Delta migration functionality of our UB Data Migration Pro allows you to port changes made in Magento 1 since the last time you migrated data. It depends on the delta modes -- Default mode via UI Dashboard or CLI mode via the terminal:

Default mode:
If you just migrate newly added data from M1 to M2, you can perform delta migration using the ‘default mode’ via the UI Dashboard.

CLI mode:
If you migrate both newly added data and modified data in M1, you need to perform the delta migration with the CLI mode (using the --mode=update).

More details about the delta migration functionality can be found in the Readme manual which is packed with UB Data Migration Pro download package.

If you plan to run delta migration, we strongly recommend you not delete any migrated data after the first migration. You simply disable unused data sections, and only delete those after you complete delta migration.

Q12. After the first migration, you continue on development. Then start delta migration with the --update mode, however it returns the error notices like:

  • ‘PHP Error[8]: Trying to get property of non-object’
  • Creating default object from empty value in file ….

and can not continue the delta migration step.

The root cause of the issue is that you delete specific data objects after the first migration, however such data is still marked available in the migration log of UB Data Migration Pro.

In order to clear up this issue and continue the delta migration with the --mode=update, you follow 3 steps below:

  • Step 1: Depending on the data objects you might remove, run the following SQL on your M2 database respectively:
    • If you delete websites/stores in Step 2:
      DELETE FROM ub_migrate_map_step_2 WHERE entity_name = 'core_website' AND 
      m2_id NOT IN (SELECT website_id FROM store_website);
      DELETE FROM ub_migrate_map_step_2 WHERE entity_name = 'core_store_group' 
      AND m2_id NOT IN (SELECT group_id FROM store_group);
      DELETE FROM ub_migrate_map_step_2 WHERE entity_name = 'core_store' AND 
      m2_id NOT IN (SELECT store_id FROM store);
    • If you delete attribute sets/product attributes in Step 3:
      DELETE FROM ub_migrate_map_step_3_attribute WHERE entity_name = 'eav_attribute'
      AND m2_id NOT IN (SELECT attribute_id FROM eav_attribute);
      DELETE FROM ub_migrate_map_step_3_attribute_option WHERE
      entity_name = 'eav_attribute_option' AND m2_id
      NOT IN (SELECT option_id FROM eav_attribute_option);
    • If you delete categories in Step 4:
      DELETE FROM ub_migrate_map_step_4 WHERE entity_name = 'catalog_category_entity' 
      AND m2_id NOT IN (Select entity_id From catalog_category_entity);
    • If you delete products in Step 5:
      DELETE FROM ub_migrate_map_step_5 WHERE entity_name = 'catalog_product_entity'
      AND m2_id NOT IN (Select entity_id From catalog_product_entity);
      DELETE FROM ub_migrate_map_step_5_product_option WHERE entity_name =
      'catalog_product_option' AND m2_id NOT IN
      (Select option_id From catalog_product_option);
      DELETE FROM ub_migrate_map_step_5_product_option WHERE entity_name =
      'catalog_product_option_type_value' AND
      m2_id NOT IN (Select option_type_id From catalog_product_option_type_value);
      DELETE FROM ub_migrate_map_step_5_product_option WHERE entity_name =
      'catalog_product_option_type_price' AND
      m2_id NOT IN 
      (Select option_type_price_id From catalog_product_option_type_price);
    • If you delete customers / customer groups in Step 6:
      DELETE FROM ub_migrate_map_step_6 WHERE entity_name = 'customer_group'
      AND m2_id NOT IN (Select customer_group_id From customer_group);
      DELETE FROM ub_migrate_map_step_6 WHERE entity_name = 'customer_entity'
      AND m2_id NOT IN (Select entity_id From customer_entity);
      DELETE FROM ub_migrate_map_step_6_customer_address WHERE entity_name =
      AND m2_id NOT IN (Select entity_id From customer_address_entity);
    • If you delete Sales data in Step 7:
      DELETE FROM ub_migrate_map_step_7 WHERE entity_name = 'salesrule' AND
      m2_id NOT IN (Select rule_id From salesrule);
      DELETE FROM ub_migrate_map_step_7 WHERE entity_name = 'salesrule_coupon' AND
      m2_id NOT IN (Select coupon_id From salesrule_coupon);
      DELETE FROM ub_migrate_map_step_7_order_item WHERE entity_name =
      AND m2_id NOT IN (Select item_id From sales_order_item);
      DELETE FROM ub_migrate_map_step_7_quote WHERE entity_name =
      'sales_flat_quote' AND
      m2_id NOT IN (Select entity_id From quote);
      DELETE FROM ub_migrate_map_step_7_quote_item WHERE entity_name =
      AND m2_id NOT IN (Select item_id From quote_item);
      DELETE FROM ub_migrate_map_step_7_quote_address WHERE entity_name =
      AND m2_id NOT IN (Select address_id From quote_address);
    • If you delete other data (eg. reviews…) in Step 8:
      DELETE FROM ub_migrate_map_step_8_review WHERE entity_name = 'review'
      AND m2_id NOT IN (Select review_id From review);
  • Step 2: Clear the cache of our migration tool by running the command:
    rm -rf pub/ub-tool/protected/runtime/cache/
  • Step 3: Continue with the delta migration by running the CLI command:
    php -f bin/ubdatamigration run --step=5;
    (Replace the --step=5; with the specific delta migration step that you’re working on respectively)
Q13. We are migrating from Magento 1.9 to 2.2.5. After migration we have:

1 exception(s): Exception #0 (Magento\Framework\Exception\LocalizedException): No options found.
#0 /var/www/vhosts/www/public_html/vendor/magento/module-customer/Model/Customer/DataProvider.php(359): Magento\Eav\Model\Entity\Attribute\Source\Config->getAllOptions()

It looks like we are missing options or something like that.

This case occurred when a user had a 3rd party extension with 5 customer attributes: allowed_payment_methods, fax, newsletter, telephone, url. All those attributes have the value select in the frontend_input field. Simply change the select to text value, the exception issue should be resolved.
Q14. I am receiving this error migrating sales data, step 7.
CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘13487’ for key ‘PRIMARY’. The SQL statement executed was: INSERT INTO `sales_order` (`total_item_count`, `paypal_ipn_customer_notified`, `entity_id`,
The issue occurred when you had sample sales data in your M2 instance, however you checked the ‘KEEP ORIGINAL IDs’ setting in Step #7 of our migration tool. Please note that, in order to keep original IDs for migrated sales data, your Magento 2 must be a fresh instance.

In this context, you need to remove the record of sample data to continue.

Q15. I have a problem with our categories. They are imported correctly and are shown in the backend. Other plugins are working with this. But when I click in the frontend on a category, it says that there is no page:
The page you requested was not found, and we have a fine guess why.
If you typed the URL directly, please make sure the spelling is correct.
If you clicked on a link to get here, the link is outdated.
This issue occurred when the user did not set the migrated root category as the root category of the default store of the current default website in his M2 instance.
Q16. I have migrated a Magento 1 store to a Magento 2 version and everything seems to be working correctly apart from the customers. I cannot log in as a customer and get the message:

An unspecified error occurred. Please contact us for assistance.

Also, customers cannot be saved in the customer grid in the admin area and I cannot view customers. When I try to go to a customer view I get the error:

1 exception(s):
Exception #0 (InvalidArgumentException): Unable to unserialize value.

The root cause of the issue was that there was at least one value with ‘serialized string’ in the field ‘validate_rules of the table customer_eav_attribute, while Magento 2 has changed from serialized string to JSON format.

This issue need to be checked directly on case by case basis to define exactly the record which has that issue.

Written By

Head of UberTheme Team