Ask a merchant on Adobe Commerce what the platform costs and you'll usually get the license number. Ask their CFO and you'll get a different, larger number. Ask the people who run the store day to day and you'll get a third answer: "a team of developers, full time, forever." - sounds familiar? if it does - read on.
This may sound like a hit on Adobe Commerce/Magento - and it is (sorry). That said, we help companies, no matter the technology, even Magento! But remember that is technology is just a tool, to support the business goals. For that exact reason, it's sad to see companies spend so much money on just keeping an Adobe Commerce/Magento store running. Money that could be either saved and used for something else to support the business, or, to build other features.
This article puts focus on exactly that.
The TCO nobody adds up
Adobe doesn't publish list prices, but implementation partners and procurement data converge on a consistent picture. Licenses run roughly $22,000 to $125,000+ per year for the on-premise edition and $40,000 to $190,000+ for Adobe Commerce on Cloud, scaling with GMV. And that license is typically only 20–40% of what a merchant actually spends. The commonly cited rule of thumb across agencies is that total cost of ownership lands at two to three times the license once hosting, extensions, development and maintenance are included, putting most mid-market stores somewhere between $122,000 and $450,000+ per year.
Where does the rest go? Broken out, a typical Adobe Commerce budget looks like this:
Ranges compiled from published 2026 benchmarks by Bemeir, Elogic, Swell, Folio3 and MGT Commerce. Individual stores vary widely.
Two things stand out.
First, the license is the smallest line. Merchants who benchmark platforms on license cost alone are comparing the wrong number.
Second, and more importantly: the biggest single line is people. The development retainer, the integration upkeep, the custom code maintenance, the upgrade cycle. That is where the money goes, and it is worth asking what it buys.
The real cost is the roadmap.
Here is the pattern we see repeatedly when we sit down with Adobe Commerce merchants:
There is a team, in-house, agency, or both. They are competent. They are busy. They ship a security patch, fix the checkout bug that appeared after the last upgrade, rebuild the ERP connector because the vendor changed their authentication model, and spend three weeks getting the store through a minor version bump.
Then someone from marketing asks for the new B2B quoting flow, or a proper search experience, or the customer-specific pricing that sales has been promising for two years. And the answer is: next quarter. Then the quarter after that.
The team isn't underperforming. The platform is consuming them. Every hour spent keeping Adobe Commerce alive is an hour not spent making the business more competitive. You end up paying a six-figure engineering budget for a store that looks and works roughly like it did three years ago.
That's the true TCO: high spend, low velocity. Enterprise money to stand still. That's kind of sad.
So why don't merchants move?
If a modern composable stack can deliver the same or better capability at a fraction of the run cost, and in many cases it can, why is inertia so strong? In our conversations, it comes down to four objections. Each is legitimate. None of them is a reason to stay really.
But, let's be fair. It's not a easy call to make a move.
1. "Better the devil you know."
You know your current platform's failure modes. You know which extensions fight each other, which upgrade will hurt, which developer to call at 2 a.m. A new platform is a blank sheet, and blank sheets are scary.
But familiarity with problems is not the same as absence of problems. The known devil is still a devil, and you are paying him well. The right way to de-risk the unknown is not to avoid it but to shrink it: a scoped proof of concept on your real catalog and real integrations, before anyone signs a replatforming contract.
2. "New tech, new project, new risk."
Replatforming has a reputation, earned over two decades of overrun ERP and commerce projects. Merchants remember the Magento 1 to Magento 2 migration, which was often more painful than the original build.
The honest response is that risk is real, and that the risk profile has changed. Modern commerce platforms are API-first and modular, which means a migration doesn't have to be a big-bang cutover. You can move the storefront while keeping the back end, or move the cart and checkout while keeping the catalog. Each step is testable, reversible, and independently valuable. The risk isn't eliminated; it's decomposed into pieces small enough to manage.
3. "I don't have time to run another project."
This is usually the most truthful objection. The commerce team is already stretched keeping the current platform alive. The idea of layering a migration on top is exhausting to contemplate.
But notice the circularity: the team has no time because of the platform. The migration is the thing that gives the time back. And it does not need to be run by the merchant. The right partner takes on the project management, the architecture, and the build, and involves the merchant's team where their knowledge matters most, in requirements, testing and sign-off, not in sprint planning.
4. "I can't get budget for a new project."
Budget is the objection that sounds financial but is actually structural. The current spend is spread across license, hosting, agency retainer, tooling and internal headcount, often across three or four budget lines that nobody totals. A replatforming shows up as a single new number that needs approval. The old cost is invisible; the new cost is very visible.
The fix is to make the current cost visible too. Build the honest TCO, all lines, three-year view, and put it next to the projected run cost of the alternative. In most cases the migration pays for itself out of the savings within the first 18 to 30 months, and the business case writes itself. The question stops being "can we afford to move" and becomes "can we afford to keep paying this."
Transform, don't just rebuild
We are not in the business of moving merchants from one heavy platform to another. That would just reset the clock on the same problem.
The point of leaving Adobe Commerce is not to run the same store somewhere cheaper. It is to free up the engineering budget that is currently spent on maintenance and redirect it toward the things that actually grow revenue: better search and discovery, conversational and agentic commerce, B2B workflows that match how your customers really buy, and a stack that lets you add capability in weeks rather than quarters. Or maybe just save money on basic stuff, like your ecommerce that's basically just supporting your business but now "the business". And that is why looking at your TCO is important.
