Cloned 1.9 db to to 2.2.5 missing attribute values

Hi there,

 Please help me figure out why this is occurring

Lets provide me information about your instances:
+ URL and Admin credentials to your M2 site
+ SSH credentials and path to M2 folder
+ phpMyadmin credentials of your M1 and M2 databases
I will help to check further and get back you then.
Regards,
Mall.

Hi there,

Please give me your IP to whitelist

Below are our IPs:
113.190.252.133
118.70.176.221
113.190.254.239
Also, please provide me more the Admin credentials of your M2 site.
Regards,
Mall.

Hi there,

When I run the first command, it is a very slow process but some attribute values simply do not update.  For example, in 1.9, we have an attribute net_weight_lbs with attribute_id 258, and in 2.2.5, net_weight_lbs with attribute_id 507.  When running step 5 in mode=update, it does not migrate the value 45 from 1.9 to 2.2.5 for that attribute.

I checked your instances and saw that the attribute you mentioned (net_weight_lbs) had the frontend_input type as ‘text’ and the backend type as ‘varchar’ in your M1 database: https://prnt.sc/omro9k. 

And after migrating to M2 by our migration tool, it had the same attribute’s settings:
https://prnt.sc/omrmzn
https://prnt.sc/omrq2d
 
And all the values of that attribute if exist will locate in the table catalog_product_entity_text: https://prnt.sc/omrpne

And that data values had been migrated by our migration tool in M2: https://prnt.sc/omrqo2

Please check the migrated data in that table at your end once again.

Also, in Magento 2 database, I saw there are total 16 data records migrated by our tool for that attribute which had the value = 45: https://prnt.sc/omrsmc
 
So, what is the Product ID (entity_id) related to the attribute’s value that you mentioned?

it does not migrate the value 45

Regards,
Mall.
 
 

Hi there,

it does not migrate the value 45

I checked again and noticed that the data record which had the value = 45 was missing as you mentioned: https://prnt.sc/oms7ho

Because you’ve done data migration once, to migrate updated information for that data record, you need to run delta migration in step #5 with the ‘update’ mode using CLI command. I noticed from the SSH terminal’s history that you already did run that CLI command. This issue is strange.

So, please try to run delta migration with the ‘update’ mode once again following these steps:

+ Clean cache of our migration tool by running the command:
rm -rf pub/ub-tool/protected/runtime/cache/
 
+ Run the delta in step #5 with the ‘update’ mode:
php -f bin/ubdatamigration run --step=5 --mode=update
 
Then, let me know how it goes. 
Regards,
Mall.

Hi there,

 it does not migrate the value 45

If you have already followed the workaround in my reply #7, it should help to migrate the value 45. So this refers to a strange circumstance.
 
Meanwhile, we noticed that your current instance is M2.2.5, and our migration tool is Pro ver 3.1.5.
 
Could you consider to upgrade your M2 instance to the latest M2.3.2, then upgrade to our Pro ver3.1.9? And re-try the workaround in my reply#7 once again?
 
Regards,
Ubertheme team

Hi there,

I really need this to work for me and cannot upgrade at the moment.  I need someone to look at this and solve the issue for me.

Could you share me a backup of your M1 database? I will help to check further on data migration with your database.
Regards,
Mall.

Hi there,

The file is very large (I think 6gb)

So, lets pause your activities at your end in your instance. I will help to check further directly in your instance you shared.
Regards,
Mall.

Hi there,
I have debug further in your instance and I saw the root issue because your M2 database has one bad data in the log table our module. You could see it in this screenshots: https://prnt.sc/onth0t
I have fixed for that bad data records by run below SQL in your M2 database:

UPDATE `ub_migrate_map_step_5` SET `offset` = '0' WHERE `ub_migrate_map_step_5`.`entity_name` = 'catalog_product_entity';

And then, run delta in step #5 with update mode. And the issue you mentioned was solved: https://prnt.sc/onthr5
Regards,
Mall.
 

Hi there,

How did you manage to find the bad record, in case this happens again?  

In case you got that issue again. Lets do steps as I did in my reply #17.
Regards,
Mall.

Hi there,

The attribute_id 258 is not migrating the value from M1 to M2 (should create a varchar record of 4.00 — 13.00) I have cleared the cache and run the #17 step and it still does not seem to be working.  Can you please see if there is some other cause?

I checked your site again and saw that the data migration in the step #5 of our migration tool has been finished: https://prnt.sc/oods3v. 
 
But when checking in the log’s table named ‘ub_migrate_map_step_5’ of our migration tool, I noticed a strange data record: https://prnt.sc/oodssg
 
It must have the value = 9658 because your M1 database has total 9658 products, and you already got finished data migration in the step #5.
 
Did you make any changes in that data table manually?
 
You can follow steps as in my reply #17:

+ Run the below SQL in your M2 database:

UPDATE `ub_migrate_map_step_5` SET `offset` = 0 WHERE `ub_migrate_map_step_5`.`entity_name` = 'catalog_product_entity';

+ Once done, run the delta migration in the step #5 by running this command:
php -f bin/ubdatamigration run --step=5 --mode=update;

And then, check the latest issue you mentioned again.
 
Regards,
Mall.

Hi there,

 The Delta migration finishes very quickly now (5 seconds) instead of half an hour or more
….
 It was set to 1 again,

I’m sorry about that. The root of that issue was as in this screenshot: https://prnt.sc/oonls0
 
I have cleaned the debug code for the first issue you mentioned. And now you can continue with the data migration in the step #5 by running the command:
php -f bin/ubdatamigration run --step=5;
 
 
Regards,
Mall.