Is it normal for Magento 2 upgrades to cost so much?

You may be understandably shocked by an upgrade quote. This article gives you the backstory that you might not otherwise have.

Adobe Commerce is a powerful platform that has generated billions of dollars of revenue for its merchants. Because it is open-source, every line of code can be customized. This makes the platform even more attractive because many ecommerce merchants come to the re-platforming table with a long list of unique challenges. A platform that is so moldable is a dream come true. This has been, and continues to be, Magento’s best feature since its release in 2007.

For many merchants, this has facilitated tremendous growth. Instead of CSRs focusing on daily mundane tasks, they are freed to chase larger revenue goals.

How can we avoid upgrades altogether?
If you are tired of upgrades, it may be time to consider a new platform. Software-as-a-Service has been on the receiving end of a bad rap from the Magento community about how “inflexible” it is. While this may be somewhat true of a platform like Shopify, we don’t see merit for BigCommerce.
Migrating to BigCommerce is likely not as huge of an undertaking as you think, especially with a qualified company like SwiftOtter—the cost will likely be significantly less than your migration to Magento 2. In fact, we have written a free 45-page quickstart ebook that walks you through the process. SwiftOtter can help you land on a platform you will be thrilled with for the next decade.

The Problem

Unfortunately, what is the best part of Adobe Commerce is also its Achilles heel. Because everything can be customized, everything can thus break. There are over 4 million lines of code in the core. All changes have to be compatible—with all future versions. While good agencies, like SwiftOtter, make significant efforts to reduce this “technical debt”, it still is impossible to mitigate completely.

Because Adobe considers the Adobe Commerce product to be “mature”, they have publicly stated that no significant features will be added to the core. Instead, the peripheral products, like Live Search, Product Recommendations, etc., will receive ongoing attention.

The downside to this approach is that merchants see upgrades as a costly vehicle oil change. We are supposed to do this, but no observable value is seen. We can get the PCI compliance gods off our back, but that’s it.

Overview of the platform

My siblings and I spent hundreds of hours enjoying Legos in my younger years. We would typically get Legos for birthdays and Christmas and immediately built them.

Think of Adobe Commerce as a project containing hundreds of thousands of Legos (according to Lego, their most significant set has “only” 11,000 pieces). If we were to have purchased an addon set of Legos, following the instructions to add or replace pieces on a vanilla Lego set would be quite easy.

However, we were the type to make changes to these sets. The end product sometimes looked vastly different than the original. This analogy continues to be extrapolated to merchants as few run a vanilla Magento website. Time and effort required exponentially increase as more Lego pieces have been added to the vanilla set.

An upgrade involves replacing many pieces—pieces on which other customized pieces may exist. Worse yet, some original pieces may have been replaced, and the new size and shape do not fit. Missing one broken scenario can add to considerable time costs and customer frustration.

While upgrading Magento is significantly easier than in this Lego analogy, the principle remains intact.

Below is a simplified version of this story.

Adobe Commerce is represented by the green and blue bricks on the left—your new desired functionality, by the bricks on the right.

To add this new capability to your website, you need to use a “bandaid” to keep the stack in place. In this graphic, without this bright-green brick, the entire stack would topple over. There are unfortunate circumstances in which even the best developer has to use such a “bandaid” (although for these bright people, like our folks at SwiftOtter, this is a rare situation). The more significant problems occur on websites where these “bandaids” are used far more than necessary, creating a situation akin to a house of cards.

The upgrade added a new green brick to the stack on the left. Due to how this stack balances, it will likely stay up for some time. Do you notice the light gray brick? This pseudo brick shows the new gap between the “bandaid” and the ground level.

Invariably this missed aspect of the upgrade will come back and cause a problem, potentially catastrophic.

Adobe recognizes this architectural problem and is working hard to fix it. Unfortunately, the ultimate solution is to re-platform. They’ve been down that road once with the Magento 1 to Magento 2 transition. That won’t happen again.

Thus, Adobe is slowly introducing a new system called AppBuilder. This opinionated environment interfaces between the new Adobe services, Adobe Commerce, and eventually a headless frontend.

This new route treats the core Adobe Commerce application as mostly untouchable (similar to Software-as-a-Service). Ironically, this is very similar to BigCommerce or Shopify. AppBuilder contains the customizations. This firewall approach will eliminate the problems with upgrades, representing a more streamlined path in the future.

How does an agency of excellence like SwiftOtter work to minimize upgrade costs?
Experience.
If there was one word that illustrates the value that we, at SwiftOtter, brings to the table, it’s that we have done more than our fair share of upgrades. The upgrades have been done by the most qualified Adobe Commerce developers in the space.
The more you’ve done something, the faster you’ll be able to do it in the future.

Why are upgrades so expensive?

Significant version jumps

You can easily make a financial argument that it’s less expensive to upgrade many versions at once—instead of every time a version is released. The downside to this approach is PCI compliance is often in question.

Either way, making a significant jump will increase the overall cost. Sometimes, the upgrade will need to be pieced into several upgrades. This makes for a longer deployment outage and increases the overall risk.

Complex website

Going back to our Lego example above, the more modifications that have been made to the vanilla build, the more time (and potentially creativity) it takes to make the new pieces fit correctly.

This means there can be significant unknowns to moving this website into production.

SwiftOtter utilizes tools in our ongoing customer engagements to reduce this risk. If these tools are not in place over time, the following best is to take the necessary to ensure the upgrade goes smoothly. We at SwiftOtter, have plenty of experience in this department—but these changes are not necessarily inexpensive.

Many modules

It’s easy to add a new module. It’s challenging to ensure the module plays well with the other modules. And it’s harder to upgrade modules with these customizations in play. The best approach is for a developer to review the old module, compare it to the new module, and understand how the modifications fit into the plan. They then upgrade the module and refit the customizations around the new module.

This takes significant time.

Poorly implemented code

Complex websites are understandable. After all, this is often the heartbeat of an ecommerce business. Customizations often represent considerable time savings.

What is inexcusable is what we often find in codebases: poorly-written and poorly-optimized code. Years of haphazard fixes have been overlaid with more patches. The result is a house of cards that crumbles every week. Merchants are frustrated and tired of this. An upgrade will not fix these problems.

Hosting environment software changes

Depending on the version jump, changes may be necessary in your hosting environment. This change is almost automatic if you are hosted on a platform like Adobe Commerce Cloud. However, additional time must be added for other hosting providers to coordinate these transitions seamlessly.

Adobe Commerce has done well with staying close to the latest versions of these dependencies. The only downside is this results in more time on upgrades.

Extra costs

While the above represents the foundation for the upgrade, good agencies like SwiftOtter will often cost more. This is for several reasons, all concerning reducing the risk of an upgrade.

For starters, we build in extra room for additional due diligence and testing. Things can break. If we spend a reasonable amount of time reviewing the website, we will likely find most (or all) significant issues. We will also ensure adequate automated test routines are in place to speed up the testing process.

SwiftOtter also likes to give some TLC to poorly-built areas. We often find these with our pre-upgrade discovery and notate them for the upgrade. While changing the oil, while not also cleaning the fuel lines and ensuring the brakes are in top shape?

Of course, we offer these extras to see the base pricing separate from the add-ons.

How to get more value out of an upgrade? Can an upgrade be classified as a Capital Expenditure?

Upgrading to new versions of 3rd-party software is considered a capitalized expenditure. Thus, you can potentially save tax on this project.

However, spending money to save on taxes is not generally a good strategy. SwiftOtter often looks for opportunities to improve the website’s speed. A faster site often translates into more purchases. Search engines prioritize speed factors into better search result rankings.

You may be able to start using PageBuilder if your current version predates 2.4.3. There are other features, like Multi-source Inventory and B2B additions, that you may also find helpful.

What all happens as part of an upgrade?

A good agency like SwiftOtter takes a thorough approach to ensure your upgrade is treated with the highest level of care. After all, this website keeps food on your table, and a major upgrade should be viewed cautiously.

Thoroughly review the system: we review every aspect of your Adobe Commerce website. Our goal is to ascertain what needs to be changed. We use our own systems and Adobe-developed tools to identify which “Legos” need to be moved.
Develop an estimate and timeline for completion: you will be presented with our findings and recommendations for how to proceed. We strive to take the middle-of-the-road approach to balance cost + time with perfect code.
Receive approval: we wait until you give the green light.
Upgrade the core: this is, by far, the easiest part of the process. This should take several hours.
Upgrade the modules: while upgrading modules can be easy, the real-time is in reviewing all module customizations to ensure they still fit together—and fixing them if there is a problem.
Review all customizations: we need to ensure these customizations still work as expected.
Ensure other aspects are upgraded: if your website uses a Progressive Web App (PWA) or other technologies, these need to be inspected. This is also the time to ensure integrations are compatible with the new Adobe Commerce integration.
Document all areas that have been changed: so the testing procedures can be properly built and executed.
Perform an extensive code review: every changed line of code must undergo strict scrutiny to reduce potential problems.
Push code to an integration environment: this gets the code in an accessible location for review.
Test the website: review every corner of the newly-upgraded pre-release website to verify all paths still function as expected.
Rehearse the final delivery: if there are environment-related changes, this step ensures that the delivery to production will be seamless.
Delivery: the moment of truth is here—the delivery is pushed to production!

Will upgrades always be this difficult?
Adobe has made it a critical priority to reduce the complexity and increase the stability of upgrades. Granted, there is only so much they can do, given the open-source foundation and availability for any change desired.
They have also stated that Adobe Commerce is considered “mature”. They will no longer be delivering significant updates or features to the core. Thus, the upgrade process will be significantly easier.

How often do I need to upgrade?

Up until fairly recently, you needed to upgrade every quarter. Doing a drill repeatedly does save time, but still if this isn’t necessary, why do it?

Adobe has also heard customer feedback in this area and they have done two critical things:

Extend the lifespan of each version: these versions now last three years. Upgrade now and it will last you three years.

Relegate critical security patches to quarterly releases: but there is a catch to the last paragraph. Even though each version (2.4.7, for example) lasts three years, you must apply small quarterly security patches. In our experience, this is a fairly trivial task.

In closing

Yes, it is, unfortunately, normal for these upgrades to have a significant cost.

If you’re tired of these expensive upgrades, we can understand. We work to help you realize as much return on investment as possible, but there is a limit.

Have you considered a new platform like BigCommerce? In our experience, BigCommerce sits at the same level of functionality as Adobe Commerce, represents a lower cost to migrate and takes far less cash to keep it running. We have developed a 45-page quickstart guide that walks you through the process. This free ebook is condensed from a 180+ page book that goes into even more detail. We list the Big 3 features (that should pay for your entire migration), how the migration process works, what value you will realize on BigCommerce and even a discovery template.