Magento 2 Data Migration FAQs (Part III)

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.

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.

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.

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 1: 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.

Workaround 2: Navigate to the Magento 2’s backend, go to Stores > Inventory > Stocks and edit the stock named ‘Default Stock’. Then, assign it to all websites. Once done, save and reindex again and clear the cache.

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

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.

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.

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

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.

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 =
    'customer_address_entity'
    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 =
    'sales_flat_order_item'
    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 =
    'sales_flat_quote_item'
    AND m2_id NOT IN (Select item_id From quote_item);
    DELETE FROM ub_migrate_map_step_7_quote_address WHERE entity_name =
    'sales_flat_quote_address'
    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)

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

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

There’s a high chance that after the first migration (with the ‘Keep Original IDs’ setting enabled), you added sample/testing data or the migrated data has been changed in M1 since the first migration which led to the issue.

You can run the following CLI commands one by one to resolve the issue (Note: depending on which step you get the error, you need to specify the --step={your_step} respectively):

• php -f bin/ubdatamigration rmdeleted --step=7;
• php -f bin/ubdatamigration clean --step=7;
• php -f bin/ubdatamigration run --step=7;