State of Magento 2 - Part 2 - Cost of Ownership

TL;DR

In this article we look at the cost of ownership in Magento 2 versus Magento 1. Overall, a merchant can expect to spend money on the license (for Magento Commerce / Enterprise) the migration (more of a replatforming), feature enhancement and upgrades. Most merchants should expect their cost of ownership to increase.

This is the second article in this series. You may want to catch up and read part 1 if you haven’t already.

Licensing Costs

Magento Commerce

Adobe Magento charges a tiered license fee for Magento Commerce (see part 1 for an explanation of the confusing Magento product names). The tiers are based on revenue: the more money that flows through your store, the more you will pay. It’s not automatic, but Magento audits your revenue periodically and adjusts your license fee.

Magento Commerce… the more money that flows through your store, the more you will pay…. Magento Open Source is free to download

Magento Open Source

Magento Open Source is free to download, however, unless you have developer skills, you will need the help of a developer to set it up for you. That part may cost you from a few hundred USD to a few thousand depending on where you get it hosted and the options you choose when setting it up.

Costs of Migration from Magento 1 to Magento 2

When merchants approach Razoyo with a project to migrate their site from Magento 1 to Magento 2,  they always want to know how much it is going to cost. I wish I could wave a magic wand and come up with a number, but, it just doesn’t work that way. So, my answer is generally the one that every merchant hates: “It depends.”

First of all, let me make one thing clear: you will not be able to bring over any of your old code from Magento 1 to Magento 2 with the rare exception of some front-end javascript.

The two whys

The first why begs the second. The first why is usually expressed as, “why can’t we use any of the code?” The answer is that Magento 2 is just too different from Magento 1 and there was NO thought given to backwards compatibility. Basically, there are so many changes to the way the code works that it is easier to start from scratch than to modify the code you have already written.

there are so many changes to the way the code works that it is easier to start from scratch than to modify the code you have already written

When I say no, nada, niente, null, I mean that none of the following from Magento 1 can be used in Magento 2:

• Extensions
• Custom modules
• Design templates
• Integrations (including web services accounts)
• Customizations of the database schema

Basically, we’re talking about everything you invested in from a customization standpoint in Magento 1.

So, the second why is, “why did Magento make it that way?” That is one for the architects at Magento. My humble opinion is that there were some inherent flaws in the Magento 1 architecture (possibly because it evolved from a community effort) that they decided it was better to scrap the old code and start over. Magento is not the only open-source software project to do this (see Angular and AngularJS).

This would have been great if more tradeoffs had not been made along the way. One of the main reasons to break with Magento 1 architecture would have been to improve the stack to be more compatible with modern web development techniques. However, as mentioned in the frameworks section of my 2018 state of Magento 2 article, this did not happen mainly because of the numerous fits and starts in the Magento 2 development project.

One of the main reasons to break with Magento 1 architecture would have been to improve the stack to be more compatible with modern web development techniques. However, …this did not happen

I agree it’s not a great answer to the two whys, but, it is the answer.

Migrating your design

This I can make very simple. Your design isn’t coming over. If you purchased a template, the Magento 2 version, though it may have the same name, is completely rewritten. Moving from Magento 1 to Magento 2 is a redesign whether or not you intend to change the look of your site.

Migrating your data

In our experience, the data migration can be as much as 30% to 40% of the migration budget. Magento touts that they have migration tools which make it easy. It is true that a tool exists, but, even if your site has no customizations at all, developers have to configure the migration tools with code.

For every custom module (extension or not) that you use, you have to decide what to do with the data. Often, the new database schema is different in significant ways in Magento 2 even for the same extension. This is even true for some core features. A developer has to work on that.

The more data you have, the more planning and testing have to be done to ensure the smooth launch of your Magento 2 site.

Extension issues

Of course, you have to repurchase all of your extensions. In addition to purchasing the Magento 2 versions of your extensions, you need to plan time and budget for dealing with extension bugs.

Why are there so many bugs in Magento 2 extensions?

We have worked with a number of extension developers, including some of the most popular and expensive extensions, to get the bugs out of their Magento 2 extensions. While it’s impossible to know exactly what is going on inside extension companies we find that the bugs have a couple of main origins:

Changes to Magento core

There are many examples, but, one of the most frustrating was an extension that relied on data from Magento orders. Magento changed the way it saves order data from Magento 1 to Magento 2 on complex products.

The extension developer was unaware of the issue and the result was incorrect inventory counts for the merchant. We had to explain to the extension developer what the issue was and prove to them that they got it wrong. This is typical because extension developers are used to less-informed developers telling them they have a problem with their extension when, in fact, the developer or merchant is using it incorrectly. So, their first reaction is to deflect.

Once we proved the issue to the developer, they took responsibility and fixed the issue. This cycle costs precious project time and is something that we plan for when quoting out a project.

Designing for Magento bugs

Extension developers have seen the bugginess of Magento 2 and the number of releases they have to keep up with. They do their best to anticipate the changes, but, sometimes that means writing brittle code. When Magento fixes a bug they had designed around, it can break the extension. Sometimes it breaks but not in all use cases. Ferreting out these issues during the build process can be expensive (see Maintaining Magento 2).

It’s not a bug, it’s a feature change

Along with the bugs, many Magento 2 extension developers have changed the way some features work. In some cases, it is a reaction to changes in Magento core functionality. In other cases, for whatever reason, the extension developer decided it was time to redesign a feature. When they also choose not to document the change, it increases costs and time significantly for the developer and merchant.

Other costs

You will need to work with the external connections that access web services accounts whether SOAP or REST to change endpoints and test the connections in their sandboxes. Magento 2’s new REST interfaces are indeed a big step up but not backwards compatible. On Magento 1, the REST APIs were weak enough that SOAP was pretty much the ‘go to’ for developers whereas, on Magento 2, you will want to take advantage of the REST APIs, so, chances are you will have some significant switching costs if you are a heavy API user.

Oh, and you’re upgrading from CE to Magento Commerce or downgrading from EE to Magento Open source? Well, your developer has an even more complex jigsaw puzzle to work out.You may spend up to a year’s worth of EE / Commerce license fee on managing a downgrade. Keep that in mind if you are considering a downgrade.

From an admin user perspective, Magento 2 looks like an upgraded Magento 1. Most of the concepts are the same, but, some of the pricing and other issues are handled differently or have different options on how they can be handled. This, too, means decisions must be made by the merchant and code must be written and tested by the migration script developer. You will also need to spend time training your team on the differences.

There is a bit of a saving grace that we can thank the Magento team for. Some of the things that merchants previously purchased extensions for are now built into core: multi-warehouse inventory (in 2.3) and video in product media gallery, to name a few. So, you may be able to skip some extension purchases. At the same time, you will have to have your migration script developer make the appropriate adjustments if data migration is required.

Some of the things that merchants previously purchased extensions for are now built into core…

Maintaining Magento 2

You will spend more with your developer maintaining Magento 2 than you did with Magento 1. The chief reason for this is the way security upgrades are handled.

In Magento 1, security updates were handled by a special patch known as the SUPEE. These patches added no functionality to the Magento web site, but, closed security holes. The patches rarely broke anything else.

In Magento 2, security updates are handled by upgrading your Magento instance to the latest 2nd digit version. I.e., if you are on 2.2.3.x and a security issue is identified, Magento will issue an upgrade that takes you to 2.2.4.x. Bundled in with the upgrade may be feature enhancements, bug fixes, and so forth. For example, while there were 30 critical security enhancements in the Open Source 2.2.7 release, there were also “over 150 core code fixes and enhancements, and over 350 community-submitted pull requests.”

So, you need to keep your Magento store up to date to keep it secure and will have to do a lot of version updates. Unfortunately, if there are breaking changes or bugs in the release and you have not addressed them, you can crash your site. Bugs have been frequent enough that we have had to increase significantly the amount of regression testing we do before upgrading.

In our experience,** maintaining Magento 2 as compared to Magento 1 costs our clients from 40% to 100% more**. The main culprits are:

• Upgrades - as discussed above
• Core bugs - it is buggier than 1
• Extension bugs - exacerbated by core bugs

Costs of Feature Enhancement

While it is true that Plug Ins have helped us with small feature tweaks, the advantages of feature enhancement have been off set - and then some - by the proliferation of bugs. Most feature enhancement requests take at least 20% more time than they would have in Magento 1 mostly due to the increased amount of regression testing required.

Overall

Magento 2 is more powerful and certainly an upgrade to Magento 1. However, it is also a completely new platform which means it is not as stable (has more bugs) and there is no quick migration from 1 to 2. You have to plan and budget not only for replatforming but for additional and new maintenance costs.