Migration of products hiding base images

Hi there,

Alternatively, could I set somewhere in the table to allow all images to display after the migration?

You can run the following SQL query in your M2 database:

Update catalog_product_entity_media_gallery Set disabled = 0;
Update catalog_product_entity_media_gallery_value Set disabled = 0;

Second question is the module is only migrating 70% of the sales orders over.  Is this because there is some issue with the orders data?  I’m not getting an error message but just a stalled ‘migrating..’ message. 

Please continue with the data migration in step #7 by running the CLI command:
php -f bin/ubdatamigration run --step=7

and let me know how it goes.
 
Regards,
Mall.

Hi there,

Status: Fail
Message: 

Can you provide me more information about that issue? Alternatively, please provide me information about your instance:

• Admin credentials of your M2 instance
• SSH credentials of your M2 instance
• Let me know the path to your M2 folder

I will help to check further and get back to you then.
 
PS. Please mark your reply private or simply switch this ticket to the private mode, then it’s safe to share your site info here, only you and our technical team can access. 
 
Regards,
Mall.

Hi there,
I checked your instance: https://prnt.sc/rf2g00 and saw the following message when trying to run the data migration in step #7:

[joomjiretail@ip-172-31-25-52 public_html]$ php -f bin/ubdatamigration run --step=7
[Processing][run] in step #7:
Status: fail
Message: Reminder! Before migrating data in the step #7, you have to complete migration in the step #5

That was because you had not run the data migration in steps #5, #6 of our migration tool yet.
So, please run the data in step #5,#6 first. And then, you can run data migration in step #7.
php -f bin/ubdatamigration run --step=5
php -f bin/ubdatamigration run --step=6
php -f bin/ubdatamigration run --step=7

Regards,
Mall.

Hi there,

Status: fail
Message: CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integr ity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’. The S QL statement executed was: INSERT INTO `sales_order_item` (`order_id`, `weight`, `no_discount`,

That occurred because you checked the ‘KEEP ORIGINAL IDs’ option in step #7 of our migration tool while you had sample/testing data in the sales data section in M2 before you do data migration.

To continue with the data migration in step #7 with the current settings, you have to delete all sample/testing sales data in M2 first.

You can run the following SQL queries in your M2 database to delete all sample/testing sales data:

Delete From sales_order Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_order where entity_name = 'sales_flat_order');
Delete From sales_order_item Where item_id NOT IN (Select m2_id From ub_migrate_map_step_7_order_item where entity_name = 'sales_flat_order_item');
Delete From sales_order_address Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_order_address where entity_name = 'sales_flat_order_address');
Delete From quote Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote where entity_name = 'sales_flat_quote' OR entity_name = 'sales_flat_quote_active');
Delete From quote_item Where item_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote_item where entity_name = 'sales_flat_quote_item');
Delete From quote_address Where address_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote_address where entity_name = 'sales_flat_quote_address');

Once done, you can continue with the data migration in step #7 by running the CLI command:
php -f bin/ubdatamigration run --step=7

Regards,
Mall.

Hi there,

I’ve done the following steps outlined in your previous post (received an error when I tried to delete ‘sales_flat_quote’ table because it didn’t exist in the database)

Please let me know which post you referred to? Please note that there is no SQL query to delete data in the table named ‘sales_flat_quote’ in my reply #15. Please check this again.

Message: CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘66674’ for key ‘PRIMARY’. The SQL statement executed was: INSERT INTO `quote_payment` (`quote_id`, `cc_exp_year`, `cc_ss_start_month`,

To solve that issue, you need to delete sample/testing data in the quote_payment table in M2. You can run the following SQL query in your M2 database:

Delete From quote_payment Where payment_id = 66674;

+ Once done, you can continue with the data migration in step #7.

Regards,
Mall.
 

Hi there,

CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’

Please provide me more details about that error message, I will check and get back to you then.

Regards,
Mall.

Hi there,

That was all it showed.  I reset and then remigrated.  It seemed to be migrated (although at a very slow pace) and about 30 min later it stopped migrating.

I checked again in your M2 instance and I saw the issue you mentioned happened in step #7 of our modue:
https://prnt.sc/rhkaem, https://prnt.sc/rhkahz

CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’

I have checked further via SSH and I saw the fully of that error message as following:

[Processing][run] in step #7: ..
Status: fail
Message: CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’. The SQL statement executed was: INSERT INTO `sales_order_item` (`….

To solve that issue you can do steps as following:

+ Run following SQL in your M2 database:

Delete From sales_order_item Where item_id = 138181;

+ Once done, you can continue with data migration in step #7:
php -f bin/ubdatamigration run --step=7;
And tell me know how it goes.
Regards,
Mall.
 

Hi there,
 
We’d like to clarify a little bit further below:
 
Through this ticket, you did submit the following issues:

#1: could I set somewhere in the table to allow all images to display after the migration?

We did provide instruction in our reply #1.

#2: Second question is the module is only migrating 70% of the sales orders over. Is this because there is some issue with the orders data? I’m not getting an error message but just a stalled ‘migrating..’ message.
[joomjiretail@ip-172-31-25-52 public_html]$ php -f bin/ubdatamigration run --step=7
[Processing][run] in step #7:
Status: fail

This related to your migration process at your end only. You proceeded with Step 7 while not running the data migration in steps #5, #6 of our migration tool yet.

#3: Status: fail
Message: CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integr ity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’. The S QL statement executed was: INSERT INTO `sales_order_item` (`order_id`, `weight`, `no_discount`,
#4. [Processing][run] in step #7: ..
Status: fail
Message: CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘138181’ for key ‘PRIMARY’. The SQL statement executed was: INSERT INTO `sales_order_item` (`….

Both issues #3 & 4 occurred because you checked the ‘KEEP ORIGINAL IDs’ option in step #7 of our migration tool while you had sample/testing data in the sales data section in M2 before/ after you run data migration in step 7.
 
Regarding the Keep Original IDs setting, we did specify a detailed note right within the configuration Dashboard (like this screenshot). It notified you that it’s mandatory that your Magento 2 must be a fresh installation when selecting this option.
 
Data migration is a complex process that associates with various factors, including your database itself, so please work closely with us on each single issue.
 
Sincerely,
Ubertheme team

Hi there,

 I reset the order migration but still getting those constraint errors.

That still came from the fact that you checked the ‘KEEP ORIGINAL IDs’ setting in step #7 and after you reset step #7, the testing data in the sales data section still remains (The Reset function of our module only covers only the migrated items). 

To continue with the data migration in step #7 with the ‘KEEP ORIGINAL IDs’ setting, deleting all testing data in the sales data section is still needed first.

Regards,
Mall.

Hi there,

I have done this already.

I helped to check your M2 database further and I saw that there are still existing sales data (sample or testing data) added in M2 which were not migrated by our migration tool:
You can learn more about that in this screenshot: http://prntscr.com/rjgfdw

As explained, you have to delete all that data before you can do data migration in step #7 with the ‘KEEP ORIGINAL IDs’ enabled.

So, please do the following steps at your end:

+ Run the SQL queries below in your M2 database to delete all testing/sample data in the sales data section:

Delete From salesrule Where rule_id NOT IN (Select m2_id From ub_migrate_map_step_7 where entity_name = 'salesrule');
Delete From quote Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote where entity_name = 'sales_flat_quote' OR entity_name = 'sales_flat_quote_active');
Delete From quote_item Where item_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote_item where entity_name = 'sales_flat_quote_item');
Delete From quote_address Where address_id NOT IN (Select m2_id From ub_migrate_map_step_7_quote_address where entity_name = 'sales_flat_quote_address');
Delete From sales_order Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_order where entity_name = 'sales_flat_order');
Delete From sales_order_item Where item_id NOT IN (Select m2_id From ub_migrate_map_step_7_order_item where entity_name = 'sales_flat_order_item');
Delete From sales_order_address Where entity_id NOT IN (Select m2_id From ub_migrate_map_step_7_order_address where entity_name = 'sales_flat_order_address');

+ Once done, you can continue with the data migration in step #7:
php -f bin/ubdatamigration run --step=7;

Regards,
Mall.

Hi there,

https://prnt.sc/rliy9o (error when remigrate sales orders)
 It is the record with blank value causing it to halt the migration.

That issue was because your M1 database had at least one data record which had the bad data in the ‘order_status’ field in the ‘sales_order_aggregated_created’ table.
You can run the following SQL in your M1 database to seek for those data records at your end:

Select * From sales_order_aggregated_created Where order_status = '' OR order_status IS NULL;

+ And then, you have re-fill needed value of the ‘order_status’ field on all found data records. Or you can delete these data records.
 
+ Once done you can continue with the data migration in step #7:
php -f bin/ubdatamigration run --step=7;
 
Regards,
Mall.

Hi there,
I have checked your instance http://joomjiretail.com/admin_qadb2z further. And I saw that:

• Your M1 currently has total 59853 sales orders: http://prntscr.com/rmxr0g
• Our tool helped to migrate total 58231 sales orders: http://prntscr.com/rmxrmu

Meanwhile I saw the ‘migrating’ status for customers migration (step #6): https://prnt.sc/rmxssc

So, please continue to finish data migration in step #6. And then continue to run the delta migration in step #7.

Once done, check the issue you mentioned once again.
 
Regards,
Mall.

Hi there,

Now I need to run the delta migration. Please let me know best way to do that. 

Please follow our instruction about the delta migration in the Readme manual (included in your download package). 
In case you still have any additional question, please let us know here. 

Regards,
Mall.

Hi there,

but stalled after 3 minutes and threw error message in ssh: 
PHP Error[2]: PDOStatement::execute(): MySQL server has gone away
…
Mage1AttributeSet->query()

I saw that this referred to a MySQL server issue only. You have lost the connection to MySQL server of your M1 database at that time.

Was your M1 database on the same Server with M2 database?

When I tried to delta migrate step 6 (customers) from magento admin, I received the following error message:
CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘14088’ for key ‘PRIMARY’

That occurred because you checked the ‘KEEP ORIGINAL IDs’ setting in step #6 while you added more customer’s data in M2 after the first migration. So, please continue with the data migration in step #6 by running the CLI command:
php -f bin/ubdatamigration run --step=6
Then, provide me more details of error message you saw. Based on that, I will suggest a workaround to solve that issue.

https://prnt.sc/rptnvf

That screenshot indicates that you first got a connection issue with your M1 database (PDOStatement::execute(): MySQL server has gone away). Please consider solving the  connection issue with your M1 database first.

Regards,
Mall.
 

Hi there,

Please check the screenshot where it shows all items have been migrated (https://prnt.sc/rpyd7b.)

Yes, I see you have proceeded data migration in all steps with a backup of your M1 database.

The issue is when I switch to the remote database it will stall for step #7, throw error for step #6 and show sql has gone away for step #3.  It does this every time I run the delta migration.

So, you should contact the Hosting provider or System admin of your M1 server to solve the issue “MySQL has gone away” for step #3 first.

And then, after you can finish the delta migration in step #3, please continue with the data migration in step #6 by running the CLI command: php -f bin/ubdatamigration run --step=6
 
Then, provide me more details of error message you saw. Based on that, I will suggest a workaround to solve that issue.
 
Regards,
Mall.

Hi there,

When I run the delta migration for step 6 it shows that the migration has been completed but I see that no migration actually took place when I checked the customers grid page in admin. (see https://prnt.sc/rsqsfh that shows after /usr/local/bin/php -f bin/ubdatamigration run --step=6 --mode=update is ran and https://prnt.sc/rsquh2 which shows no new customer records came through from the delta migration)

It seems that you haven’t reindexed data successfully yet, after you finished delta migration in step #6.

I was able to get all of the customers to migrate by removing all of the customer records and remigrating from the remote database instead of the local one.

So, please continue with your current instance and let me know if you need further assistance.

Regards,
Mall.

Hi there, 

The issue I am facing now is each time I do a delta migration for the products, it gets sent to the ‘default category migrated’ folder and I end up having to move those over to the ‘default category’ folder.

You shouldn’t do that. You should set the Migrated Default Category as the Root category of the current default Store of the default website in your M2. You can change this setting in the Stores managements in your M2 backend.

Also, I’m also noticing a few products migrated over without the images.

Please make sure you already moved/copied all media images from Magento 1 as per our Readme manual. In addition, any media images exluded in M1 will be marked as hidden images after being migrated to M2.

Regards,
Ubertheme team
 

Hi there,

We are also noticing that some of the Magento 1 configurable products that are being migrated over have special price and regular price set instead of on the simple products.  When those configurable products get transferred over to Magento 2 the special price is not used because it was added on the configurable product in Magento 1 and it appears Magento 2 uses the simple product prices and special prices instead of that set on the configurable product

That is a new working rule of Configurable products in M2. If you add a new Configurable product in M2, you will learn more about that. Also, you can find out more about M2’s Configurable product settings via this guide.

 What about products that were already migrated but recently changed after the delta migration (ie: inventory, product name, special price added to simple product, etc.?) How do I bring the changed data for existing migrated products over to magento 2?

To delta update migrated products, you have to run delta migration in step #5 with the ‘update’ mode by running the CLI command:
php -f bin/ubdatamigration run --step=5 --mode=update;

Regards,
Mall.

Hi there,
It’s a pity that we do not have any suggestion in place at the moment. Anyway, it would be best to follow the new working rule of Magento 2 as mentioned in our reply #50 above. 
Regards,
Ubertheme team

Hi there,

and noted that the category pages show a 404 page (see http://joomjiretail.com/americana.html) on frontend even after reindexing and clearing cache.  Please advise.

The not found issue occurred because there is no URL Rewrite for that Category’s Request path (americana.html) in your M2:
https://prnt.sc/rvtm6i
https://prnt.sc/rvtmi3

As you see, there is a Category’s URL rewrite with the Request Path ‘camouflage.html’
And it was working fine in your frontend: http://joomjiretail.com/camouflage.html

You can try with the following steps so that M2 can help regenerate URL rewrite for categories and associated products:
1 -- In categories management, create a new root category named ‘Temp Root Category’
2 -- Open Stores management, edit the default Store of the default Website and set the ‘Root Category’ form field to the newly added root category ‘Temp Root Category’ and click Save button.
3 -- Once done, open Stores management once again, edit the default Store of the default Website and set the Root Category form field to the main root category which you want to publish in the storefront again and click Save button.

Magento will regenerate categories and associated products URLs rewrite in this step. It might take sometime to complete this task (It depends on the volume of categories and associated products)

Once done, re-index the data and clean the Magento cache.
 
And tell me know how it goes then.
 
Regards,
Mall.

Hi there,

If getting the category pages to show on the front end means resetting and starting the product migration step again then I can do that but this needs to be resolved as we are trying to launch soon.  

No, that is not needed.

I followed your steps but  I see that the url rewrites is stuck at 615 records

Yes, I have tested those steps at my end and saw that issue too. This is strange.
 
I have enabled the ‘developer’ mode in your instance to debug further and noticed the following error in the frontend when accessing this URL: http://joomjiretail.com/camouflage.html

1 exception(s):
Exception #0 (Magento\Framework\Exception\LocalizedException): The XML in file “/home/joomjiretail/public_html/app/design/frontend/Infortis/ultimo/etc/view.xml” is invalid:
Element ‘aspect_ratio’: This element is not expected. Expected is ( background ).
Line: 21

As can be seen, that issue related to a bad XML declaration of the third-party module named ‘Infortis/ultimo’. Thus, you should consider getting this issue fixed first.

Also, I saw there is another third-party module named ‘Infortis_UltraMegamenu’ which may affect Magento’s generating category’s URL rewrite function. And it might be the root cause of the issue you mentioned. Could you disable all third-party modules in your site to test the data migrated by our migration tool first?

Regards,
Mall.

Hi there,

Is there another way to get the images to show the dimensions that have the same height and width with no whitespace background like before?

You should contact your third-party theme provider to get better help on that issue.

http://joomjiretail.com/catalog/category/view/s/denim/id/171/) instead of the category slug (ie: joomjiretail.com/denim.html)

That was because that the category (id 171) still had missing URL Rewrite. Please try to re-peform steps as per my reply #54 so that M2 can re-generate URL rewrites.
 
Regards,
Mall.

Hi there,

 but now I am seeing dropdown list for sizes is out of order (see https://prnt.sc/ry8glt)

That doesn’t relate to our migration tool. Instead, it refers to Magento’s function or third-party theme you are using.

If this is not possible, can the module be modified by commenting out the section that delta migrates over special prices?

Yes, you can apply with these steps:
+ Open the PHP file at pub/ub-tool/protected/controllers/Step5Controller.php
and find the lines:

if ($productTypeId == 'configurable') {
    $ignoreAttributeIds = array_merge($ignoreAttributeIds, array (
        UBMigrate::getMage1AttributeId('price', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_price', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_from_date', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_to_date', $entityTypeId),
    ));
}

and replace it with:

if ($productTypeId == 'configurable') {
    $ignoreAttributeIds = array_merge($ignoreAttributeIds, array (
        UBMigrate::getMage1AttributeId('price', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_price', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_from_date', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_to_date', $entityTypeId),
    ));
}
if ($this->runMode == UBMigrate::RUN_MODE_DELTA) {
    $ignoreAttributeIds = array_merge($ignoreAttributeIds, array(
        UBMigrate::getMage1AttributeId('special_price', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_from_date', $entityTypeId),
        UBMigrate::getMage1AttributeId('special_to_date', $entityTypeId),
    ));
}

Once done, you can ignore the product’s special price in the delta migration with the ‘update’ mode in step #5.

Regards,
Mall.
 

Hi there,
I am sorry for replying to you a bit late as we’ve just been back from the weekend. 

How about ignoring media galleries on next delta migration?

Product’s media images are required and migrated by default in step #5 to ensure the product’s data relationship.
 
If you still need to ignore product’s media images in the next delta migration in step #5, you can apply these steps:

+ Open the PHP file at pub/ub-tool/protected/controllers/Step5Controller.php
and find the code line:

$this->_migrateCatalogProductGallery($product->entity_id, $product2->entity_id, $mappingStores, $mappingAttributes, $keepOriginalId);

and replace it with:

//$this->_migrateCatalogProductGallery($product->entity_id, $product2->entity_id, $mappingStores, $mappingAttributes, $keepOriginalId);

+ Once done, you can do data migration in step #5 while ignoring the product’s media galleries.

Regards.
Mall.
 

Hi there,

Another issue I noticed is that I see ‘out of stock’ and ‘product qty not available’ if the quantity is 2 or below 2.  

Please provide me more details about that issue. 

I’m noticing that during delta migrations where an order took place on the production site, it will not be reflected on the inventory migrated over.  For example, if a sale was made on a product, the inventory would be reduced by 1, but when the latest inventory is sent over for that product in the delta migration, it will not reflect the current inventory as if the sale of that product never happened.

The delta function in step #5 of our module covers both newly added products and migrated Products which have changes in M1 after the first migration (The catalog_product_entity.updated_at with changed datatime value)

The context of place order on migrated product in M1 site you mentioned wasn’t updated with the value of catalog_product_entity.updated_at field after M1 reduced the quantity of this product in M1 database. Thus the delta function in step #5 of our module couldn’t handle the changes for this case.

To resolve this case, you can manually update the datetime value of the ‘catalog_product_entity.updated_at‘ field in M1 database for the product which had captured the order in M1. And then, you run the delta migration in step #5 with the ‘update’ mode by running the CLI command:
php -f bin/ubdatamigration run --step=5 --mode=update;

Regards,
Mall.
 
 

Hi there,
We’d like to follow up further below: 

why wasn’t it updated? I’m not sure I understand what this means. Is there something I did wrong during the migration? I followed the steps of doing a base migration from M1 database and then followed up with delta migrations from the remote production database. Did I miss a step?

This relates to the Magento’s functions, not the wrong steps of migration at your end.

I am not sure what you mean by manually update the datetime value? Do I have to actually go to phpMyAdmin and update values in the ‘catalog_product_entity.updated_at’ field and change the values for each new order? I also don’t understand why I have to ‘manually’ update when the data migration module should be doing this automatically.

As explained above, the catalog_product_entity.updated_at value is the time base for the Delta functions of our migration tool which allows filtering which products need to be delta-migrated in step #5 (products with changes in M1)
If you can not manually update case by case after having new orders in M1, you can run the following SQL query to delta update all products in your M1 database (NOTE: with this workaround, the delta migration will take a rather long time as the first migration in step #5):
1. Run the following SQL in your M2 database:

Update ub_migrate_map_step_5 Set created_time = '2000-01-01 00:00:00' Where entity_name = 'catalog_product_entity';

2. Run the delta migration in step #5 with the ‘update mode’:
php -f bin/ubdatamigration run --step=5 --mode=update
 
We hope that helps.
Regards,
Ubertheme team
 

Hi there,

 I tried running the 
I only found the ub_migrate_map_step_5 table on the target database (joomjire_dgg8) and not the base m1 database (joomjire_dgg11).

Yes, you need to run the SQL query I suggested in M2 database (I have just edited our reply #67)

but it threw an error when I ran the php -f bin/ubdatamigration run --step=5 --mode=update command so I restored the ‘ub_migrate_map_step_5’ table.  

Please redo steps as suggested in our reply #67. And provide me details about the error message you mentioned in step #5. I will help to check further and get back to you then.

Regards,
Mall.
 

Hi there,

Message: The table “{{inventory_source_item}}” for active record class “Mage2InventorySourceItem” cannot be found in the database.

What is the version of your M2 instance? That issue occurred because you had not installed Magento_Inventory module. Please consider enabling this module in your M2 instance. 
Once done, you can continue with the data migration in step #5 of our module.

Regards,
Mall.

Hi there, 
Yes, please continue with the process at your end. If you need our further assistance, please get back back to us here.
Regards,
Ubertheme team

Hi there,
I am sorry for replying to you this late as we’ve just been back to work from our weekend. 

I am noticing that there are about half a dozen products that have salable quantity at 0 and quantity at a different number even after reindexing when the delta migration is completed.  How can this be corrected so that salable quantity is the same as regular quantity after delta migrating the products?  

That occurred because you didn’t enable ‘MSI’ in the first migration. Please do additional steps as follows:

+ Run the following SQL query in your M2 database:

Update ub_migrate_map_step_5 Set created_time = '2000-01-01 00:00:00' Where entity_name = 'catalog_product_entity';

+ Once done, you run the delta migration in step #5 with the ‘update’ mode:
php -f bin/ubdatamigration run --step=5 --mode=update;
(Please note this can take a long time because it scans all products)
 
Regards,
Mall.

Hi there,

There were about a dozen products that were out of sync.

That is strange if you already did complete all steps as suggested in my reply #75. Please try to reindex the data and check the issue you mentioned once again.

If you need further help, please provide me information of your instance:

• URL and Admin credentials of your M2 instance
• SSH credentials of your M2 instance
• Let me know the path to your M2 folder
• All product IDs or Product’s SKUs which had the issue you mentioned (a dozen products that were out of sync)

I will help to  check further and get back to you then.
 
PS. Please make sure you mark your reply private when sharing your site info. Then only you and our technical team can access it. 

Regards,
Mall.

Hi there,

 I reindex but still the last 25 customers did not get included in the migration.

Please make sure that you did reindex data successfully after you finished the data migration in step #6.

Also, you can directly check the total of migrated customers in the ‘customer_entity’ table in your M2 database.
 
Regards,
Mall.

Hi there,

 Should I reset customers step and import the customers again?  Please advise.

Please try with these steps:
+ Run the following SQL query in your M2 database:

Update ub_migrate_map_step_6 Set created_time = '2000-01-01 00:00:00' Where entity_name = 'customer_entity';

+ Then, you run the delta migration in step #6 with the ‘update’ mode:
php -f bin/ubdatamigration run --step=6 --mode=update;
+ Once done, reindex the data again. And let me know how it goes.

Regards,
Mall.

Hi there,

Still short 25 customers after running the sql query and the update command.  I also reindexed.

That is strange. Please provide me information of your instance:

• URL and Admin credentials of your M2 instance
• SSH credentials of your M2 instance
• Let me know the path to your M2 folder
• phpMyadmin credentials of your M1 and M2 databases.

I will help to check further and get back to you then.
 
PS. Please make sure you mark your reply private or simply switch this ticket to the private mode, then it’s safe to share your site info here. Only you and our technical team can access it. 

Regards,
Mall.
 

Hi there,

 Still short 25 customers after running the sql query and the update command.  I also reindexed.

I have checked your site and saw that our tool helped to migrate total 14600 customers: http://prntscr.com/slhxyk
 
And I saw that there are total 14603 customers in the Customer grid view in your M2 backend: https://prnt.sc/slhy4s
 
So, please check the issue you mentioned again.
 
Also, when accessing the settings in step #6 of our module, I got this issue: http://prntscr.com/slhzh3
 
Regards,
Mall.

Hi there,

The total customer count is currently at:  14634 on the M1 site (see: https://prnt.sc/sluojj). 

So, please re-perform all steps as suggested in my reply #81 to migrate the missing customers at the current time. Then let me know how it goes.

Regards,
Mall.

Hi there,

running the query and update command worked this time.

I am glad to hear that. Please continue the process at your end and let me know if you need further assistance.

Regards,
Mall.

Hi there,

PHP Error[2]: Creating default object from empty value
in file /home/joomjiretail/public_html/pub/ub-tool/protected/controllers/Step6Controller.php at line 397

That issue because you did deleted at least one migrated customer in M2 backend after the first migration.
Let’s try with steps as following:
+ Run following SQls in your M2 database:

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);

+ Once done, clean cache of our module by run command:
rm -rf pub/ub-tool/protected/runtime/cache/
+ And then, you continue with delta migration in step #6 by run CLI command:
/usr/local/bin/php -f bin/ubdatamigration run --step=6 --mode=update
Regards,
Mall.

Hi there,

PHP Error[2]: Creating default object from empty value
in file /home/joomjiretail/public_html/pub/ub-tool/protected/controllers/Step8Controller.php at line 2118

Please try with these steps:

+ Run the following SQL queries in your M2 database:

DELETE FROM ub_migrate_map_step_8_review WHERE entity_name = 'review' AND m2_id NOT IN (Select review_id From review);
DELETE FROM ub_migrate_map_step_8_subscriber WHERE entity_name = 'newsletter_subscriber' AND m2_id NOT IN (Select subscriber_id From newsletter_subscriber);
DELETE FROM ub_migrate_map_step_8 WHERE entity_name = 'tax_class' AND m2_id NOT IN (SELECT class_id FROM tax_class);
DELETE FROM ub_migrate_map_step_8 WHERE entity_name = 'tax_calculation_rule' AND m2_id NOT IN (SELECT tax_calculation_rule_id FROM tax_calculation_rule);
DELETE FROM ub_migrate_map_step_8_cms WHERE entity_name = 'cms_block' AND m2_id NOT IN (Select block_id From cms_block);
DELETE FROM ub_migrate_map_step_8_cms WHERE entity_name = 'cms_page' AND m2_id NOT IN (Select page_id From cms_page);

+ Once done, clean the cache of our module by running the command:
rm -rf pub/ub-tool/protected/runtime/cache/
+ And then, you continue with the delta migration in step #8 using this CLI command:
/usr/local/bin/php -f bin/ubdatamigration run --step=8 --mode=update

Regards,
Mall.