Magento2 Migration for Dummies – January 2020 Update

created January 12, 2020, last updated January 30, 2020.

closeThis post was last updated 1 year 2 months 5 days ago, some of the information contained here may no longer be actual and any referenced software versions may have been updated!

We run a small business with a small IT budget (i.e. zero) and I am migrating a Magento 1.x ecommerce website to Magento 2 – which is no mean feat!

It is now January 2020, in my last post from June 2019 I had just about completed the import of approximately 5000 products using my own migration scripts to help me export skeleton product data from Magento 1 into Magento 2 and then synchronise the full product data.

I had expected this project to take at least 6 months, it’s now 7 months later and I am still not finished! So what happened in the last 6 months?

Firstly I was extremely busy and unfortunately could not allocate 100% of my time (or even 50% sometimes) to the project, over the months between September and December it was even less which naturally meant that a lot of migration tasks took a lot longer than I had initially expected.

After getting my product import and sync processes working smoothly I started to look for a suitable Magento 2 theme. It’s natural when upgrading from one shop to another that you want to try and keep things looking the same, after all – there was nothing wrong with the old shop look right? Magento 2 migration is more than an upgrade, it’s a complete technology refresh – so it makes sense to try and improve on as many aspects of your old store as possible. My frontend development skills are ok, but to create a new Magento 2 theme from scratch with all the basic features you expect from a commercial theme is a whole new project in itself. In my view it makes much more sense to buy a theme that meets your basic requirements and then customise it to meet your needs.

When it comes to buying commercial Magento themes on a budget there is a lot on offer but my advice is to choose carefully and be prepared to buy three or four themes before you find the one that you will develop to become your Magento 2 store theme. A basic Magento 2 theme is not expensive, expect to pay between $100 and $400 for a good theme on  Themeforest or the Magento Marketplace. However, buyer beware! Not all theme developers are the same. On a site like Themeforest look carefully at the developers sales figures, reviews and comments. A theme with 20,000 sales must be doing something right! Pay attention to the version of Magento 2 the theme supports, make sure it is up to date – Magento  often make theme breaking changes with minor releases, there is no guarantee that a Magento 2.3.2 theme will work on 2.3.3 unless the developer says so in the release notes. There is no way to try before you buy, so purchase the theme and evaluate it. If it does not function as it is supposed to there is a good chance you will get a refund from Themeforest if you state your case clearly.

What makes a good theme? Look for a theme that gives you lots of design options, some themes have over 20 different designs included in the theme to choose from. Look for bundled extensions such as ajax layered navigation but beware – if the bundled extensions are not up to date you may have problems getting support for them. Avoid gimmicks like frontend gui editors that are overly complex and might not required if you are a developer.

Whilst building my Magento 2 development environment I made the decision to use Elasticsearch as the catalog search engine, Magento state that use of the mysql database as the Magento search engine will be deprecated. Because of this theme selection and testing process took over two months as the first three themes I tested whilst claiming to be compatible with Elasticsearch were not. It soon becomes clear when talking to theme developers what level of PHP and Magento skill they have (or don’t have). One theme developer who was very keen to resolve my Elasticsearch problem for me simply changed the catalog search setting back to mysql in admin without telling me! It took me a few days to notice that, and afterward I ditched the theme. Having found a suitable theme I started to develop the look of the theme and product presentation.

It was around about this time that we realised we could make use of Magento 2 visual swatches a lot more in our products. Our Magento 1 shop has a lot of grouped products, and a lot of configurable products with dropdown option selection. We made the decision to convert configurable products to use visual swatches with options for size and colour. This meant I had to redesigning hundreds of products and basically delete and reimport them. Magento 2 is not a Shop upgrade, it’s a Shop refresh – take this opportunity to improve your Magento product presentation as much as you can.

I systematically worked through our product categories exporting Magento 1 product skeleton data, modifying it manually in Excel, importing it in Magento 2 and then synchronising content, pricing, images etc. By the end of November the first three categories were complete – never underestimate the time required to  process and import Magento product data! Even with spreadsheets, scripts (and MAGMI) it’s a lot of work. If your store has 100 simple products manually editing them is doable – with 1000’s of products manual product editing is just not viable.

So here we are in January 2020, I have more time now to spend on the project and I am (reasonably) confident that we will launch by March 2020!

Here are my lessons learnt over the last six months

  1. Don’t try and upgrade your Magento 1 store to Magento 2. Use this opportunity to refresh and redesign your store! Think outside the Mage1 box…
  2. Create a good product data workflow that allows you to quickly bulk import and modify products
    1. Use MAGMI – yes it works with Magento 2!
  3. Evaluate commercial themes very carefully, make sure they are completely compatible with the latest Magento 2 release before you commit to developing.
  4. Always create your own child theme referencing the commercial parent theme, make all your changes in your child theme NOT the parent.
  5. Use a vcs like Bitbucket to commit your child theme and code changes to, use this for the parent theme also – it’s a great way to control parent theme changes when a new theme version is released.
  6. TEST – always have another dev box you can spin up with a copy of your latest data to test any updates and changes that might break the database or your code!
  7. MAKE BACKUPS, and take backups of the backups. Losing this much work is unthinkable…

I am starting to see light at the end of my migration tunnel – still a lot of work to do with products and theme customisation and a whole lot of testing – not to mention new hosting and go live planning, and, and – AND…


This site uses Akismet to reduce spam. Learn how your comment data is processed.