
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.

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.

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.

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 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.