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.
|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:
|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:
|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) ubertheme.com, 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:
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:
|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:
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:
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:
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:
|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.
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: 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:
WHOOPS, OUR BAD…
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:
|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.