• en
    • et
    • fi
    • da
    • no
    • sv

Previous minor versions of Magento 2 – How to proceed?

magento 1 vs 2


When the long-awaited first version of Magento 2 was released in 2015, it seemed logical that it would not make sense to make new major developments based on Magento 1. Since then, most of the stores built on Magento (ie 2.0.x and 2.1.x) are already on the new software, but it is logical that several updates to the first versions of the new software are necessary. Therefore, switching from them to the latest minor version today (e.g. 2.0.x or 2.1x switching to the latest version 2.3.x) may mean larger investments, as Magento has significantly improved the new versions with the support of the community.

Let’s now give a quick overview of the nuances of the transition from earlier versions of Magento 2. It’s important to understand that the end-of-life for the first versions is officially here:

Magento 2.0.x – support ended in March 2018
Magento 2.1.x – support ended in June 2019
Magento 2.2.x – support ended in December 2020.

Why are the first minor versions of Magento 2 no longer being developed? Answer:  

  • The changes made by both the community and Magento’s own team are significant enough to require major revisions;
  • The speed at which e-businesses are evolving has increased, placing greater demands on software;
  • Supporting multiple versions of software is more costly, and it is “easier” to get e-stores to upgrade, because hardly anyone will ever build on an old version.

“Endless updates.”

Several years ago, a decision had to be made – whether to build your e-store on a stable version of Magento 1, which will become legacy in a few years, or take a risk with a new version. Understandably, many merchants now have the question – I built the store on the new platform, but now I need a major upgrade again? And secondly, if the investment to upgrade to 2.3 is made, when will this journey need to be undertaken again?

No end date for the latest version 2.3.x has been announced as of today. As developers, we can say that this is already a “mature” version, which will be of high quality and will certainly have a longer lifespan, even if 2.4.x should be significantly better. Also, in our opinion, the 2.2 version is already a good software, and less time consuming to upgrade to 2.3. The problem is with versions 2.0 and 2.1. Some merchants have retrospectively blamed themselves or the developer, when in fact the issue lies in understanding the logic of the overall software lifecycle.

On top of the old version, the shop owner may feel like a hostage – it doesn’t seem worth investing in the development of the old version and the new investment feels even bigger. Another unpleasant surprise is that many third parties do not support modules on old versions and new modules are only made for the latest versions. Perhaps if you want to continue with the old version for some time, in some cases it may be necessary to invest in a downgrade (which may not be a bad idea from a business point of view).

magento 2 versioonid

Less is more?

An important nuance that tends to be forgotten is that the bigger the IT system, the more expensive it is to maintain and change/upgrade. When analysing new solutions, there are more possibilities to consider, more test cases, proper documentation, etc. to be completed. A good e-store is never finished, and it is natural to take ideas from customers and competitors alike to continuously improve the store.

The cost of upgrades is also influenced by third-party developments, i.e. how much the mechant has wished to save on e-commerce development by using off-the-shelf solutions. One of the advantages of Magento is the large network of developers/communities and the modularity of the software. If a merchant wants some functionality, it is possible to get it cheaply from the module store and add it to their e-store, but there are no free lunches. It’s tempting to look at Themeforest for a variety of interesting designs, and prefer a few hundred dollars for UX analysis to tens to hundreds of hours for a custom solution.

“Someone has already done it, let’s use it!” is a good argument to save on the development costs of a store, but you have to consider the sustainability of the solution and its compatibility with other modules. There are stores that are legacy, full of a huge number of very different modules that have been made to work together and for which there is no time estimate for upgrading. This is where an initially favourable add-on can become a problem.

The upgrade process is as follows – modules and special solutions are mapped, a copy of the store is made to the development server, the upgrade is applied and the store is tested. During the patching process, it is checked whether there are newer versions for third-party modules. If there are no newer versions of said modules, the developer has to upgrade the third-party module himself, and sometimes it is worth replacing it with one from another provider altogether. This is particularly relevant for the earlier minor versions of Magento 2, where the changes are larger.

We are not saying that off-the-shelf solutions should not be used – it is a risk assessment task and depends a lot on the merchant and his/her plans. At Lumav, we have reduced the long term risk for our customers by no longer developing new stores on off-the-shelf designs, by preferring a tried and tested development partner when modules are required, and by having a back-up team on every project who also know the project.


Now, with e-commerce growing at the expense of physical stores during the crisis, more and more retailers are realising that a competitive e-business solution is mandatory rather than a convenience. Developers, too, are adapting, as we can see, and offering faster-to-market, maintenance-free packages, but is this the magic wand? If e-business is to be built, why invest in development/maintenance-intensive platforms in the first place, and instead go for rental solutions with everything already in place?

The e-business case cannot be seen as a competition but rather as a fight. The customer always buys his goods from one place and the famous Viking anecdote “We did well in battle, we came second…” applies here too. The fact is that the more demands are made on e-businesses, the more demands are made on their platforms. If Magento wants to be the world’s most advanced e-business platform provider, it can be expected that they themselves will be constantly thinking about how to offer new technical solutions that will help its users to gain a competitive advantage. Whether a merchant needs to, and can, get up to speed with everything and get on board immediately is already a business decision for each individual.

To summarise, three points to conclude:

  1. Whether to invest in reliability or opt for an inexpensive off-the-shelf solution; as well as when and how often to upgrade your e-store is a business decision. It depends mainly on how competitive your sector is.
  2. The more complex the system, the more time-consuming are maintenance and upgrades, including the amount of analysis and testing involved.
  3. In a competitive industry, it cannot be assumed that new platforms will never need to be upgraded, and there will be fewer changes. On the contrary.

As with Magento 1 updates, making/implementing major updates to Magento 2 is a business decision. If you need input on which upgrade path would be the best for your business, contact us and we’ll find a solution together.

Share this post: LinkedIn facebook
Cookie Consent EN Google Consent Mode v2 and Cookie Consent Module for Magento 2
When GDPR was implemented in 2018, we created a technical solution for it for...
Read more 26. March 2024
Gardenhouse24 Successful E-business Gardenhouse24: Ten Countries in Three Years
Becoming an exporter is the dream of every ambitious entrepreneur – it shows that...
Read more 31. January 2024


    Lumav - Magento Partner

    As a Magento Certified Partner, we provide our customers with the best solutions for business growth.