Migrating from Magento 1.X to Magento 2.X – An Adventure in Details

The story of creation a B2B Marketplace based on Magento 2, migrated from Magento 1. It’s originally from CreativeMinds (cminds.com). The CreativeMinds team specializes in creating cutting-edge WordPress Plugins and Magento & Ecommerce Extensions, aimed to satisfy the growing needs of website administrators, designers and developers worldwide. Feature image courtesy of ideyweb via Bigstockphoto.

We recently completed a project migrating a Magento 1.8 used as a marketplace to the new Magento 2 platform (version 2.1.2).

This store was based on version 1.8 of Magento and was a Marketplace based on the CreativeMinds Marketplace extension with around 500 thousand products. The client requested multiple alterations to the checkout process and admin capabilities.

After considering the work needed we realised that rebuilding the site on Magento 2 was going to take the same amount of time as making the changes considering a lot of the requirements were already included as default functionalities in Magento 2. This led us down the road of creating a B2B Marketplace based on Magento 2, migrated from Magento 1. A new adventure to be sure! A little spoiler… This did not go so smoothly… and may not have been the correct decision at this point of Magento 2.

Initial Assumptions

Our assumptions were as follows:
1. DB migration should be easy using the Magento 2 DB migration code.
2. We found all required extensions that were on the Magento 1 site ready for Magento 2.
3. We would use the default Luma theme as base and make adjustments to it as it has the base structure needed by the customer.
4. We will use the Magento 2 core payment gateway to save time and money (we started with Braintree, but moved to authorize.net).

Sound simple, no?

Just to be clear, our developers have extensive experience in Magento 2 , from creating extensions to more complex projects (but this was our first very big migration).

What actually happened

Let’s start with the first assumption and see what actually happened:

1. DB migration should be easy using the Magento 2 DB migration code.

Well easy it was not. The site had so many custom attributes, custom tables, products and categories. Additionally the extension and code in Magento 2 actually used a slightly different structure. It took a lot of effort to resolve all the conditions and conflicts that arose during the DB migration.

Furthermore the Magento 2 catalog and indexing process especially for url rewrites is different than for Magento 1 and since the site had many products with the same url values (with different url rewrites) this totally broke the indexing in Magento 2 and we had to create a script that ran through all of the products adjusting the url and then saving the products one by one.

To move categories around we had to disable the re-indexing option before moving a category since otherwise it was completely impossible. But finally after a lot of sweat and crying, a hero Magento developer in Kiev we know finally made it work.

2. We found all needed extension that were on the Magento 1 site ready for Magento 2.

Ok, this bit’s going to sound a tiny bit self congratulatory, (Aside from our own extensions) 100% of the 3rd party extensions for Magento 2 did not work! All had issues, some were really poorly written some just did not have all the same features as the Magento 1 equivalents, and some just had bugs. So, some of extension companies had great support and made it somehow work, some we had to adjust the extension to work, the free ones were the worst and we literally had to re-write them from scratch.

Magento 2 extensions are still very young and although the Magento marketplace claims they do code review and QA, in this case although the code was written in the PSR standard it was not doing what was expected or causing issues.

3. We will use the default Luma theme as base and make adjustment to it as it has the base structure needed by the customer.

So this assumption was OK. Though the task was not easy at all, because although the changes needed initially appeared to be slight alterations to the default theme, eventually what the client required was to completely rewrite the theme. All the blocks moved around, all the buttons, all the fonts and so on. It broke the responsive design and we had to rewrite it, so another assumption that ended up eating a tonne of time… So much for assumptions.

4. We will use the Magento 2 core payment gateway to save time and money (we started with Braintree, but moved to authorize.net):

So we started with Braintree, but they didn’t want to approve our client given that he’s selling medical products and they refused to deal with it. Ok. We moved to Authorize.net and the client was able to establish an account. We added his credentials to Magento and were happy, but it didn’t work! The payments were not passing and the worse part, the logging errors for Magento 2 authorize.net are impossible, you have no way to find the errors.

After fighting with this we decided to install Our own CMinds Authorize.net CIM extension just so we can have proper logs to understand when something’s going wrong with the account what errors we’re getting from the API etc. Finally we got it working using our extension, but it all took a lot of time.

5. Bugs Bugs Bugs:

Magento 2 still has so many issues reported that they are fixing every new version but it’s a frustrating wait. Starting from email templates to import bugs, admin accounts issues, permissions issues, and on and on. Eventually almost everything will be fixed and they don’t really affect the process of the store but they’re still very annoying.

Going Live

So finally we went live. The client was happy, despite the expensive adventure and the delivery time being over by about a month. The store is live and selling on Magento 2 functioning as a marketplace with multiple vendors and sparkling new features.

Try to remain positive, Magento 2 is really cool. Bugs are being fixed, extensions are continually improving since they are being used and users are digging out the bugs. Magento Marketplace just reported they are starting manual QA on our extensions so I assume it’s a new general approach that will for sure improve the quality of all extensions. If we had to begin this process again with a new customer, It would probably be a lot easier and faster with the experience of those 4-5 months.