|

Magento 2 Data Migration Notes

Recently I was assigned to do data migration from Magento 1.8.1.0 to Magento 2.1.0 In this article, I will share some points you must look out for when migrating to Magento 2. There are several things you must be aware of before you start migration:

  • Magento 2 is a memory hog.  So, suggested 2GB RAM is just a bare minimum to run Magento 2.  In most cases 2GB RAM will not be enough if you decide to do migration.  If you are limited in your RAM you can add swap space.
  • When installing Data Migration Tool you will need your authentication keys. Your public key is your username; your private key is your password.
  • If your Magento 1 store has a lot of products you will have to increase the value for max_allowed_packet in MySQL configuration file. I set it to 32 GB.
  • Be sure to install Magento 2 Data Migration Tool of the same exact version as your Magento 2 website.

Before I started migration, I replicated source Magento 1 database on my local server.  After installing Data Migration Tool I copied config.xml.dist (which was in my case in vendor/magento/data-migration-tool/etc/ce-to-ce/1.8.1.0 folder) to config.xml file and added the source and destination database mysql credentials as described in Magento Migration Guide.

When you start migration tool, you will have a lot of errors such as “Source fields not mapped”, “Source documents not mapped”, etc.  You will have to ignore those database tables and columns in corresponding mapping files.  You will be working a lot with map.xml.dist file.  Since data migration is done in several steps, you also will be working with mapping files located in one directory above (ce-to-ce). In my case I had to change map-eav.xml.dist, map-customer.xml.dist, eav-attribute-groups.xml.dist, and class-map.xml.dist.

I also ran into a problem where when I migrated the website, product categories when clicked on showed 404 not found. I figured out it had to deal with Url Rewrite step in data migration process.  After playing around with Version191to2000.php (this is were core_url_rewrite table form Magento 1 is translated to url_rewrite table in Magento 2) file I did not have much luck.  The better solution was to simply skip Url Rewrite step (I just commented it out in config.xml file) and run re-indexing after migration, so the url rewrites were rebuilt automatically.

If your Magento 1 website has SSL certificate installed, you will not be able to get to your Magento 2 website admin login in page if your Magento 2 website does not have SSL. (By the way, your login, password and admin login page do not change after migration.  Data migration does not migrate admin accounts.  You will have to recreate them  manually). In order to fix that you need to set the value of “web/secure/use_in_adminhtml” to 0 in core_config_data table in Magento 2 database.  After doing so and cleaning Magento cache from command line you should be able to get to your Magento 2 admin login page.

After migration you may also run into a problem where you cannot edit your customers or products.  One of the possible problems could be that you have data for your Magento 1 plugins/modules in the database, but those plugins/modules are not installed on Magento 2 website.  To fix this problem, check your eav_attribute (customer_eav_attirbute) tables, locate the data that the old plugins/modules were using and remove those rows in the table.

These are a few notes that I wanted to share after I did Magento 2 data migration.

Share this article

Similar Posts

  • Upload to FTP with PHP

    $fp = fopen(‘https://www.example.com/pdfdoc’, ‘r’); $user = “sammy”; $pass = “password”; $ftp_server = “192.168.10.10”; //should be wrapped in try catch to properly handle errors $ftp_conn = ftp_ssl_connect($ftp_server); $login = ftp_login($ftp_conn, $user, $pass); ftp_chdir($ftp_conn, ‘path/to/folder’); //can also use ftp_pwd ftp_pasv($ftp_conn, true); //passive mode ftp_fput($ftp_conn, “mydocument.pdf”, $fp, FTP_BINARY); fclose($fp); ftp_close($ftp_conn); Above code can be used to upload a…

    Share this article
  • |

    Debugging Webhooks

    A webhook is an HTTP callback, that occurs when something happens (a resource changes its state). Webhooks provide a way to build event-driven apps, because you can be notified about changes. Since webhooks require a publicly accessible URL to function they can be hard to test from your local machine.  There are three main problems…

    Share this article
  • |

    Adding Email Headers in Laravel Application

    Adding email headers in Laravel application is quite simple. SwiftMessage can be customized using withSwiftMessage method of Mailable base class: https://laravel.com/docs/8.x/mail#customizing-the-swiftmailer-message However you have to remember to do it every time you create a new “mailable” class. Some mail APIs require you to put a special header each time you send an email. In this…

    Share this article
  • |

    Testing API Clients

    Since an API client is a boundary between your code and the outside world you should write as little code as possible to implement it. The client should strictly do its job by sending a request and returning a response. That is why we don’t really test the clients themselves but rather the code that processes the response from the client.

    Share this article