Errors page not found after migration

Hi there,

migration was successfull but now we have  page not found errors on all menu items in frontend and searches are returning no results

Please check and make sure you already did the following things:

• Set the migrated Root category as the Root category of the current default Store of the default website in your M2 instance
• Reindex the data successfully and clean your M2 cache

Also, please make sure that your products are available in stock.
 
Regards,
Mall.

Hi there,

All category names are empty and can´t add their name, it´s not saved. We reindexed all data but don´t work, the products aren´t appearing in frontend.

That is strange. It seems that you haven’t finished data migration in step #3 (migrating attributes) yet.

Please provide me information of your instance:

• URL and Admin credentials of your M2 instance
• SSH credentials of your M2 instance
• And let me know the path to your M2 folder

I will help to check further and get back to you then.

Regards,
Mall.

Hi there,

 We reindexed all data but don´t work, the products aren´t appearing in frontend.

Before you reindex the data, you need to set the migrated root category as Root category of the default store in your M2: https://prnt.sc/tn4bt7
And I saw all your products had missing value of ‘Visibility’: https://prnt.sc/tn4iqp
And that is the root cause why your products weren’t shown in the frontend.

All category names are empty and can´t add their name, it´s not saved

I checked the migrated categories in your M2 backend and saw that issue. That is strange. Because your categories had name in M1 database: http://prntscr.com/tn4ra2
For all that, please try with these steps:

1. Run the following SQL query in your M2 database:

Update ub_migrate_map_step_4 Set created_time = '2000-01-01 00:00:00' Where entity_name = 'catalog_category_entity';

2. Run the delta migration in step #4 by running the CLI command:
php -f bin/ubdatamigration run --step=4 --mode=update;
3. Run the following SQL query in your M1 database to clean the bad data records of the ‘Visibility’ attribute in the table ‘catalog_product_entity_int’. These data records caused the issue on ‘Visibility’ of migrated products I mentioned above:

Delete From catalog_product_entity_int where attribute_id = 102;

4. Run the SQL below 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';

5. Run the delta migration in step #5 by running the CLI command:
php -f bin/ubdatamigration run --step=5 --mode=update;
And then, reindex the data and clean M2 cache and check the issues you mentioned again.

Regards,
Mall.

Hi there,

I have created a new admin user named ‘ub’ in your M2 site.

And I try to check further into your M2 site but I couldn’t access the Catalog views because your M2 site had an issue with the permission of static files: http://prntscr.com/tnllw7
I thinks that is the root cause of the issue you mentioned: 

And now I can´t open products view in m2 administrator.

Thus, please deploy static files in your site once again and re-update the permission of folders and files in your M2 root folder at your end.

And let me know how it goes then.
 
Regards,
Mall.

Hi there,

 ´ve corrected permissions and reindexed and now catalog shows all products. But with “visibility” camp empty.

I have created a new admin user named ‘ub’ to debug further. 

After checking the current M2 site, I saw the issue you mentioned with the migrated product: https://prnt.sc/tpsyb5. I found the root cause of that issue was that you hadn’t check the related product attribute ‘visibility’ in Step #3: https://prnt.sc/tpsval
I am not sure why you got that. As you see, there are many other system product’s attributes which weren’t migrated yet.
 
Thus, please discard the steps suggested in my reply #5 and try with steps below:

1. Revert M1 database to the stage before you run steps suggested in reply #5.
2. Reset data migration in steps: #8,#7,#6,#5, #4, #3 of our module. You can reset each step by running the CLI commands:
php -f bin/ubdatamigration reset --step=8
php -f bin/ubdatamigration reset --step=7
…
php -f bin/ubdatamigration reset --step=3
3. Once done, navigate back to Step #3 backend setting and make sure all system product’s attribute were checked to be migrated (custom product’s attributes are optional. Then, you run data migration in step #3 and verify the data in this step first. Please make sure all product’s attributes you selected are migrated correctly.
If you get any issue with the settings in this step, please let me know at that point of time.
4. After you complete successfully this step, you can switch to next steps as you did before.

Regards,
Mall.
 
 
 

Hi there,

 I did all your instructions and selected all attributes and run step 3… but then this attributes don´t appear as migrated in backend settings.
Running from console step 3, results as “Step 3 migration completed succesfully… Total Data Migrated: 29%.” I don´t know if this is normal.

No, that isn’t normally. It seem that, the PHP’s setting of ‘max_input_vars’ param weren’t handled for current volume of attributes in your M1 database.
Please try update PHP’s settings to increase value of ‘max_input_vars’. Let’s try with: max_input_vars=10000
and make sure you restart M2 server after your changing PHP settings.
And then, you reset the step #3 again by run CLI command:
php -f bin/ubdatamigration reset --step=3
And then, you redo setting and migrate data in step #3. And tell me know how it goes.
Regards,
Mall.
 

Hi there,

Also all category names in backend are empty and can´t be modified.

I checked your M2 backend and saw that issue: https://prnt.sc/tr1y5j. That is strange though.

I checked further into your instance and saw that:
+ Our migration tool helped to migrate total 360 categories: 
https://prnt.sc/tr1v5s
https://prnt.sc/tr1vs2
+ And there are total 361 categories’ names in your M1 database: http://prntscr.com/tr1wed

MariaDB [mildot]> Select count(*) From catalog_category_entity_varchar where attribute_id = 41 and store_id = 0;
+———-+
| count(*) |
+———-+
| 361 |
+———-+

and our tool migrated total 360 categories’ names to your M2 database: 

MariaDB [mildot2]> Select count(*) From catalog_category_entity_varchar where attribute_id = 41 and store_id = 0;
+———-+
| count(*) |
+———-+
| 360 |
+———-+

So, you can see all M1 categories and associated category’s data were migrated to M2 database successfully.

And I saw the same issue when creating a new Category in your M2 backend, you can verify all that at your end too.
 
Also, I noticed that there are some third-party extensions in your M2 site. Do they affect that issue? Can you disable all third-party extension to verify the migrated data first?
 
Regards,
Mall.
 
 

Hi there, 
 
We are sorry for replying to you this late as our team has just been back from our weekend. 

Well, we restored an old copy pre-migration and migrated all again with your suggestions. All are migrated correctly and we can edit categories and categories have their name.

So, this indicates that the issue did not relate to our migration tool.

But when root store is changed to migrated the categories names appears as blank and can´t be modified.
The third extensions can affect menu links and url rewrites but this categories error appears only when migrated changes are applied…

This refers to Magento 2’s function or associates with the third-party extensions that you’re using in your M2 instance only. It does not associate with our migration module though. Please help to check further at your end.
 
Regards,
Ubertheme team