Customers & Sales Not Migrating

Hi there,
 
We initially installed this extension on our Development environment on a fresh Magento 2 installation. We ran the sync on all steps, and everything seemingly worked as intended. We chose to “Keep Original ID’s.” We have since moved to our Staging environment and everything seemed to work as intended. We were able to complete Delta migrations from Prod -> Staging with no issues.
 
However, recently we placed test orders and created new user accounts to test on our Staging environment. We realized what we had done after it was too late and as a result, delta syncs were seemingly no longer working. Creating new orders/accounts on Staging incremented the ID’s and as a result, when trying to perform a Delta Migration, it would no longer be able to complete as a result of the ID conflict created. This is our theory at least…
 
So, to fix this, we decided to Truncate all Customer and Sales data. We then “Reset” Steps 6 and 7 in the UB Data Migration Pro Extension and chose to no longer “Use Original ID’s.” However, upon running the UB Data Migration on Steps 6 and 7, it seems as though data is no longer migrating at all. We are running the steps via command line and it claims it is completing in 100 order increments but nothing is populating into the necessary tables.
 
We ran the following query to truncate the necessary data…

SET FOREIGN_KEY_CHECKS = 0;

TRUNCATE TABLE `gift_message`;
TRUNCATE TABLE `quote`;
TRUNCATE TABLE `quote_address`;
TRUNCATE TABLE `quote_address_item`;
TRUNCATE TABLE `quote_id_mask`;
TRUNCATE TABLE `quote_item`;
TRUNCATE TABLE `quote_item_option`;
TRUNCATE TABLE `quote_payment`;
TRUNCATE TABLE `quote_shipping_rate`;
TRUNCATE TABLE `reporting_orders`;
TRUNCATE TABLE `sales_bestsellers_aggregated_daily`;
TRUNCATE TABLE `sales_bestsellers_aggregated_monthly`;
TRUNCATE TABLE `sales_bestsellers_aggregated_yearly`;
TRUNCATE TABLE `sales_creditmemo`;
TRUNCATE TABLE `sales_creditmemo_comment`;
TRUNCATE TABLE `sales_creditmemo_grid`;
TRUNCATE TABLE `sales_creditmemo_item`;
TRUNCATE TABLE `sales_invoice`;
TRUNCATE TABLE `sales_invoiced_aggregated`;
TRUNCATE TABLE `sales_invoiced_aggregated_order`;
TRUNCATE TABLE `sales_invoice_comment`;
TRUNCATE TABLE `sales_invoice_grid`;
TRUNCATE TABLE `sales_invoice_item`;
TRUNCATE TABLE `sales_order`;
TRUNCATE TABLE `sales_order_address`;
TRUNCATE TABLE `sales_order_aggregated_created`;
TRUNCATE TABLE `sales_order_aggregated_updated`;
TRUNCATE TABLE `sales_order_grid`;
TRUNCATE TABLE `sales_order_item`;
TRUNCATE TABLE `sales_order_payment`;
TRUNCATE TABLE `sales_order_status_history`;
TRUNCATE TABLE `sales_order_tax`;
TRUNCATE TABLE `sales_order_tax_item`;
TRUNCATE TABLE `sales_payment_transaction`;
TRUNCATE TABLE `sales_refunded_aggregated`;
TRUNCATE TABLE `sales_refunded_aggregated_order`;
TRUNCATE TABLE `sales_shipment`;
TRUNCATE TABLE `sales_shipment_comment`;
TRUNCATE TABLE `sales_shipment_grid`;
TRUNCATE TABLE `sales_shipment_item`;
TRUNCATE TABLE `sales_shipment_track`;
TRUNCATE TABLE `sales_shipping_aggregated`;
TRUNCATE TABLE `sales_shipping_aggregated_order`;
TRUNCATE TABLE `tax_order_aggregated_created`;
TRUNCATE TABLE `tax_order_aggregated_updated`;

TRUNCATE TABLE `customer_address_entity`;
TRUNCATE TABLE `customer_address_entity_datetime`;
TRUNCATE TABLE `customer_address_entity_decimal`;
TRUNCATE TABLE `customer_address_entity_int`;
TRUNCATE TABLE `customer_address_entity_text`;
TRUNCATE TABLE `customer_address_entity_varchar`;
TRUNCATE TABLE `customer_entity`;
TRUNCATE TABLE `customer_entity_datetime`;
TRUNCATE TABLE `customer_entity_decimal`;
TRUNCATE TABLE `customer_entity_int`;
TRUNCATE TABLE `customer_entity_text`;
TRUNCATE TABLE `customer_entity_varchar`;
TRUNCATE TABLE `customer_grid_flat`;
TRUNCATE TABLE `customer_log`;
TRUNCATE TABLE `customer_log`;
TRUNCATE TABLE `customer_visitor`;
TRUNCATE TABLE `persistent_session`;
TRUNCATE TABLE `wishlist`;
TRUNCATE TABLE `wishlist_item`;
TRUNCATE TABLE `wishlist_item_option`;

TRUNCATE TABLE sequence_invoice_1;
TRUNCATE TABLE sequence_order_1;
TRUNCATE TABLE sequence_shipment_1;
TRUNCATE TABLE sequence_creditmemo_1;

SET FOREIGN_KEY_CHECKS = 1;

Is there something we are missing? What exactly does the “Reset” setting do? Running via CLI definitely suggests it is doing something as it claims the steps are being completed but again, not seeing anything populating the necessary tables.
 
Thank you,
Application Development Team
American Textile Company
 

6 answers

Profile photo of ubdev Staff 36100.00 $tone February 6, 2019
Public

Hi Paul,
 
We are terribly sorry that we’re now having a National 7-Day Festival event, and our team will be off through Feb 6.
 
For the other days this week, we will have technical team on duty to follow up the technical support, however it will take us a bit longer to follow up with you in case you reach us during this time.

We’re sorry for this unexpected circumstance and the delay caused due to this festive time. We will get back to you within Feb 7. 
Thanks for your understanding. 

Regards,
Ubertheme team

#1
Profile photo of Mall Staff 107160.00 $tone February 7, 2019
Public

Hi there,

So, to fix this, we decided to Truncate all Customer and Sales data. 

You shouldn’t do that. To remigrate in all steps, you could do reset first and then, start data migration from grow up.

Running via CLI definitely suggests it is doing something as it claims the steps are being completed but again, not seeing anything populating the necessary tables.

That is strange. Do you have change or move servers after the first migration? Let’s re-check database credentials of M1 and M2 databases in configuration file of our migration tool at path: pub/ub-tool/protected/config/db.php
Regards,
Mall.

#2
Profile photo of App Dev 30.00 $tone February 8, 2019
Public

Thanks for the reply. That does seem to have been the case… the database got flipped to our development database in the db.php file on our Staging server. Changing that to use the correct database seemed to fix the issue.

We ran the sync again and made sure to choose to no longer “use original ID’s.” It completed and everything seemed to match correctly.

So, to continue testing on our end…

We placed a test order. Ran the Delta Migration on Step 7 (Sales) before Step 6 (Customers) and it pulled in the Orders as intended. However, it seems as though the 1 new customer account is not syncing. It is showing in the Database table customer_entity… however not showing in the “Customers” section of the Magento 2 Admin panel.

Is this incorrect usage on our part? Must Step 6 be always ran prior to running Step 7? Can we test transactions and customer account creation on the environment we are migrating to and still be able to delta sync without problems? If so, why are we having problems with that?

And final question is relating back to the original ticket. Is it common for users to run your extension on a similar environment to us? Development/Local -> Staging -> Production. It seems like the extension has some issues that we are running into with the db.php seemingly changing the “Destination” DB to the “Development” DB even though on “Staging.”

If possible or if you have any further questions, we can potentially initiate a phone call to further discuss these issues we are encountering.

Thank you.
 

#3
Profile photo of Mall Staff 107160.00 $tone February 10, 2019
Public

Hi there,

However, it seems as though the 1 new customer account is not syncing. It is showing in the Database table customer_entity… however not showing in the “Customers” section of the Magento 2 Admin panel.

To see newly migrated customers in grid view in back-end, you must reindex the migrated data first.

Is this incorrect usage on our part? Must Step 6 be always ran prior to running Step 7?

Yes that is right. Because the sales data has relationship with customers data.

Can we test transactions and customer account creation on the environment we are migrating to and still be able to delta sync without problems?

Yes, if you didn’t check to ‘Keep original IDs’ in setting in related steps of our migration tool you could do that.

And final question is relating back to the original ticket. Is it common for users to run your extension on a similar environment to us? Development/Local -> Staging -> Production. It seems like the extension has some issues that we are running into with the db.php seemingly changing the “Destination” DB to the “Development” DB even though on “Staging.”

If you changed database credentials for both M1 and M2 databases, you must re-settings in step #1 of our migration tool. And you could manual check/update databases credentials in the configuration file at path: pub/ub-tool/protected/config/db.php
Regards,
Mall.
 

#4
Profile photo of App Dev 30.00 $tone February 11, 2019
Public

Can you please reach out via email and assist in looking into the issue we are encountering? I can share my screen to demonstrate the issue we are facing. Delta Syncs are still seemingly not working.
 
Thank you.

#5
Profile photo of ubdev Staff 36100.00 $tone February 12, 2019
Public

Hi there, 
You can send over the screenshot of the issue you mentioned via our email info (at) ubertheme.com. 
Meanwhile, please provide us your site credentials below so that we can check further as well: 

  • URL and Admin credentials of your M2 instance
  • SSH credentials of your M2 instance
  • Let us know the path to your M2 folder

Please mark your reply ‘private’, then it’s safe to share your site info here. Or you can send over to our email above if you choose to. 
Regards,
Ubertheme team

#6

Please login or Register to Submit Answer

Written By

Comments