Migrating from Magento 1 to 2? Here is a tip to help keep your DB as clean as possible › Xumulus
1041
post-template-default,single,single-post,postid-1041,single-format-standard,select-core-1.5,pitch-child-child-theme-ver-1.2,pitch-theme-ver-3.4.2,ajax_fade,page_not_loaded,smooth_scroll,grid_1300,vertical_menu_with_scroll,blog_installed,wpb-js-composer js-comp-ver-6.6.0,vc_responsive
Xumulus / All Posts  / Migrating from Magento 1 to 2? Here is a tip to help keep your DB as clean as possible
In All Posts, Magento

Migrating from Magento 1 to 2? Here is a tip to help keep your DB as clean as possible

Thinking of upgrading your Magneto 1 to Magento 2 and trying to learn from those you came before you on best practices and ways to avoid headaches.  Keep reading for some tips and tricks on Magento 2 Upgrades.

As many folks have already upgraded and we have had the pleasure of doing or managing some of these sites after the fact, one thing with Magento 1 to Magento 2 migrations has become a common theme, sometimes old data structure linger around and that can causes issues. Here are some that we have seen:

  • Upon saving a product and giving it a new URL nothing happens and the URL won’t change.
  • Magneto New from and to dates seem to not go away in the DB but are used in some places, often times the client would get the error “The from date is not greater than the to date” on save, though there was not way to view these in the product edit page, you would still get the error.
  • Special price from and to dates also seem to persist but are no longer editable. Pretty close to the same as the above but in this case, the client would have things change the price as they were added to the cart, as the product page ignored these but the cart was not.
  • During upgrades, errors are thrown with data structure changes based on fields that are loaded with what looks like spam.
  • Probably a few more of these around Magento 2 Commerce edition with its scheduling and row id structures. Though I don’t have great documentation around this, there is a row_id that enables some of the scheduling features.

For example

We had a client not able to generate a new URL for a product, any time the product was saved it simply kept the existing URL. It appears the cause of this was that the url_path field was no longer used and or even shown in the Magneto 2 UI, but if that value was present in the DB, anytime you saved the product it used that field.  This was outlined in this StackExchange issue.  Though ours was a bit different with the attribute

DELETE FROM catalog_product_entity_varchar WHERE attribute_id = 87

We did that and sure enough, now if you save a product key then you immediately get the new URL in the frontend.

You may want to validate the url_path attribute id before you go deleting anything though.

SELECT * FROM `eav_attribute` WHERE `attribute_code` = 'url_path'

It should be noted not all systems have the same id numbers.

So this is very similar to another EAV type of data issue we have seen.  The sale_price_from and the sale_price_to dates, these were deprecated from Magento Commerce Edition, in favor of using the scheduler to schedule the changes. Wel,l either something went wrong or but we had one client where the prices were changing in the carts because the dates were there, but now one could manage them.   And one place in the front end used them, while others did not.

So, now to the point of the article.  The other day I was looking into Migrating someone from Woo Commerce to Magento 2.  I started to investigate this based on using Cart2Cart.  This tool allows you to migrate via various cart API users accounts, passwords, orders as well as products.

Then it hit me

Hey, why don’t we start doing our Magento 2 migrations this way, use the software to cleans the DB if you will and make sure we start with a fresh new Magneto 2 specific DB, then migrate you one data with Cart2Cart.

Well, this is exactly what we will be doing from now on, to make sure carry over as little “legacy problems” in the data as possible. If you are at all familiar with the Magento EAV data structure you will likely know what I am talking about, its a tremendously flexible data model, but it does seem to be prone to lots of issues where data structures are referenced in the code base, they are no longer intended to be used.

The bottom line

You should at the very least, consider a Magento 1 to Magento 2 migration plan that opts to use data migrations trough API layers and native imports, rather than through a database “upgrade” script. The upgrade script can keep some stuff around you may not want or need.

#keepitclean