The biggest disadvantages of Magento you need to know
Without a doubt, Magento is one of the most versatile ecommerce engines available. However, like any other platform, it has its strengths and weaknesses.
What are the biggest disadvantages of Magento?
6 biggest disadvantages of Magento
Magento disadvantages – summary
After an internal discussion and brainstorming with our team, we identified 6 disadvantages that we consider the biggest weaknesses of Magento, which are often overlooked by many. Still, everyone should be aware of this before deciding to use this engine.
These 6 points are:
If you are interested in how I’ve evaluated these and why, from my point of view, they are considered disadvantages, I encourage you to continue reading.
With the introduction out of the way, let’s move on to a detailed discussion of these disadvantages.
Often, in conversations with various ecommerce directors or owners considering using Magento, they overlook future Magento maintenance costs.
However, I know that Magento’s maintenance and development costs can be an unpleasant surprise, so it’s important that before you decide on Magento, you are aware of the maintenance costs you will face.
In one of my previous articles, I detailed Magento’s maintenance and development costs. There, I presented 3 scenarios:
It turned out that over a 5-year perspective, factoring in 7% inflation, Magento’s maintenance and minimal development costs with a budget hosting service amounted to about 249.200 EUR/USD.
If we opt for good hosting, the cost would rise by 28.000 EUR/USD over those 5 years.
This means that it is unlikely that costs would be lower than 249.200 EUR/USD over 5 years. These are real costs that you should take into account.
The second downside of Magento, which is rarely mentioned and not often talked about, is that you can’t edit orders once they’ve been placed in the Magento panel. Magento’s logic is that if you want to change anything in an order, you should simply cancel that order and place a new one.
What are the consequences of such a policy? There are several. This can be an incredible hindrance if you imagine customer service will work within the Magento admin panel.
For example, if you sell pants and get a call from a customer who informs you that they placed an order for a certain model but, upon reflection, decided to change sizes. In such a case, customer service cannot edit the order – they cannot enter the system and change the size. In this scenario, customer service must cancel the order and enter a new one. Sometimes, this might be a minor inconvenience, depending on the organization of other business processes in your company, but sometimes, it can be a significant problem. That’s why I would advise against using Magento as an Order Management System (OMS).
It’s better if that function is carried out by a different tool. Keep in mind that if you edit an order in the Order Management System, these changes will not be transferred to the order in Magento. Consequently, the user in the Magento order history can access incorrect data. However, there is a way around this issue – you can link order details from the Order Management System in the customer panel in Magento.
Another downside of Magento is product data management. The admin panel, to put it mildly, isn’t designed for mass actions on products.
With Magento, the number of SKUs can reach 500,000 or even 800,000. After all, we often choose Magento because we need an engine that can function correctly with such a large database. I hope no one assumed they would manage such a product database from the Magento admin panel. If you imagined managing products and mass editing products in the Magento panel as something simple, you might be in for a surprise.
It’s unfeasible. Instead of assuming you’ll be doing this in the Magento panel, it’s better to contemplate immediately that implementing some PIM (Product Information Management) will be necessary.
The fourth downside to Magento is that while there are many available third-party modules for Magento, OFTEN is of very low quality. There are modules that are excellently written. Their implementation into Magento generally does not create problems. Nevertheless, there are many modules whose implementation into Magento causes chaos in the code and, in short, breaks down the whole engine.
The maintenance costs for such a Magento, in which, for example, we have implemented 7 low-quality modules, can be very high, as we will have to allocate a significant budget for continuous error correction (especially after every Magento update). In such a case, the costs I mentioned earlier would not be about 249.200 EUR/USD over 5 years, but I think that easily 30% to even 50% would have to be added to that amount. That’s why it’s worth keeping in mind that sometimes it’s better to write a bespoke module for your project.
It should be added for formality’s sake that an experienced programmer is needed to assess the quality of a third-party module.
The fifth point is the checkout. The checkout in Magento is written in Knockout JS, which, unfortunately, is not a super solution.
As we know, the checkout process is one of the most complicated elements in ecommerce. Here, many different functions come together in one process and affect each other mutually.
If we decide to change the standard Magento checkout to something completely different, with a different number of steps and functionalities, those changes would be costly.
While possible, they would be expensive and undoubtedly increase Magento’s maintenance costs. Why? Imagine a situation where we want to add a new delivery method to the order placement process. However, if we have so greatly modified the checkout that we cannot use the standard module provided by the delivery company, we took care to ensure that the Magento plugin was available, up-to-date, and adapted… but to the standard order placement process, we can’t use the ready-made plugin. Therefore, we must write this module ourselves, which means we have to assign this task to the software house that works with us.
Of course, the Magento checkout can be customized to your own needs by adding small changes, such as information about discount amounts on promotional products. Such simple modifications are possible to implement and do not generate a large technical debt.
However, if you want to significantly change the order placement process and create something completely different from the standard Magento, this involves subsequently high, and over time even huge, costs of maintaining and developing the Magento platform. You need to be aware of this.
The last point I would like to address is the issue of transferring Magento projects between different software houses. This is a controversial topic, but it’s worth being aware of how this situation looks.
Magento is an open-source platform, and many companies specialize in maintaining and developing stores on this engine.
Most people who decide to use Magento do so with the conviction that if cooperation with their current software provider does not go well, they can take their Magento, go through the process of choosing a new software house or ecommerce agency, sign a contract with another company, and move their Magento project there.
Theoretically, this is true. However, in practice, if at the very beginning, you choose a software house that makes many basic mistakes related to the implementation of Magento, such as implementing 20 low-quality modules that break the code, it turns out that the portability of such Magento virtually does not exist.
This means that even if you move Magento to another software house, it will not solve the problems of continuous errors. You will still need to correct what has already been patched.
In summary, if you are thinking about Magento, it’s worth remembering that, like any ecommerce solution, Magento is not without its flaws.
You should be aware of these disadvantages and assess from a business perspective whether these are points you can live with and which you consciously decide to accept. Every ecommerce engine has errors and flaws that differ from system to system. In the case of Magento, 6 main disadvantages can be distinguished.
First, the maintenance costs are relatively high. You should anticipate that over 5 years, maintaining Magento, even with cheap hosting and minimal development, may cost around 252.000 EUR/USD.
The second downside is that orders that have entered Magento are practically uneditable. You can cancel the order and place a new one, but there is no way to edit orders already in the Magento system.
The third downside is that the admin panel is not adapted for mass actions on products. Therefore, you should move product management outside of Magento.
The fourth downside of Magento is the presence of many low-quality modules on the market. It’s easy to stumble upon a low-quality module, which later will result in high maintenance and development costs for your Magento.
The fifth downside is the checkout, which is difficult to edit. If you plan to completely overhaul this process, turning it upside down, Magento might not be the best choice. Later, such a system’s maintenance and development costs could be high. There is a possibility for minor modifications to the checkout process so that it is efficient and effectively turns visitors into clients. However, I recommend a partial change in the logic of this process.
The sixth point concerns the transferability of the Magento project between different programming companies (Software House). This transferability is illusory if Magento was poorly coded from the very beginning.
If you’re wondering whether Magento will be a good choice in your case, be sure to read: how many hours of your work will it take to implement Magento?!
