The open architecture of Magento, which later became Adobe Commerce, made the platform flexible but expensive to keep current. Learn why Adobe Commerce as a Cloud Service (ACCS) ends the upgrade cycle, and how Adobe’s AI migration tools help merchants move from self-managed Commerce or other platforms.

At some point or another, almost every one of us has heard an old-timer utter the old adage, "They don’t build ’em like they used to." If you’ve bought a refrigerator or a washing machine in the last ten years, you likely know this to be true. And then, someone debuts a car that has 2 Gs of suction for driving upside down and handily does barrel rolls midair.

While not quite as dramatic as a flying car, one of the world’s most widely used and most capable e-commerce platforms also falls within the bounds of that famous quote, in a positive way.

Ten years ago, I likely would have argued with my current self for writing this article. I’ve spent most of my career on the same platform. Starting with Magento, which later became Adobe Commerce, I’ve spent the last 15+ years writing code and architecting e-commerce systems for which the sky is the limit. Custom modules, plugin chains four levels deep, late nights on a client call because a patch release ran into an extension nobody remembered installing. I still love the platform that has shaped so much of my adult life. I also know what it costs to own and maintain, probably better than most of the people signing the checks.

When I talk to customers about Adobe Commerce as a Cloud Service (ACCS), I’m not working from a script. It’s the platform I didn’t realize I wanted until it became a reality.

Why self-managed Commerce got expensive to own

Magento got to where it got because it was open. Anyone could crack open the core and make it do what a business needed. That built an enormous ecosystem including extension marketplaces, third-party agencies, and billions of lines of code. It also produced some stores I wouldn’t wish on anyone.

If you’ve spent any time in this space, you probably know how it goes. A merchant launches on a clean architecture, followed by a few years of agencies and internal teams adding features against deadlines. A preference, a core class rewrite, an observer that only works because of a private method somebody found in 2019. Nobody did anything wrong, exactly. But when the next major upgrade comes due, it’s a six-figure project that eats the better half of a year. Less than two years later, you do it again.

Licensing and hosting are on the spreadsheet, but the upgrade engineering time usually isn’t. I’ve worked on teams where upgrades and security patches took up much of the roadmap, and the things customers would have liked to see kept sliding out to the next quarter.

What changes with ACCS

With ACCS, Adobe runs the core application and the infrastructure underneath it. There’s no version to move to because you’re already on the current one. Patches show up without you planning a full regression cycle around them.

For architects, the bigger change is around customization. You don’t touch the core anymore. Extensions run off-platform on App Builder and talk to Commerce through APIs and events.

I didn’t love this at first. I’ve spent years being able to reach into whatever class I needed. For someone like me, out-of-process extensibility feels like someone took my tools away. Like the old-timer dads I mentioned earlier, it took me some time to come around to this newfangled thing. What finally did it for me was simple logic: if your code can’t touch the core, an update to the core can’t break your code, and your code can’t break the core. We spent more than a decade telling developers to keep that separation, mostly without success. Now the platform enforces it with great success.

A faster storefront with Edge Delivery Services

The storefront is good news too. Edge Delivery Services (EDS) with the commerce drop-in components gets you fast pages without multiple performance tuning projects. Remember the days of trying to figure out how to get Lighthouse scores of 100 across the board and never quite achieving it? Well, an EDS frontend starts you off at 100, and it’s your job to keep it that way as you build. Additionally, marketers can update the website content without opening a ticket or doing a cloud deployment.

Moving to ACCS from other platforms

Not every merchant I talk to runs Adobe Commerce. Many of them are on other platforms and stuck. Usually they’re on a closed software-as-a-service (SaaS) product that’s easy to run until they need real business-to-business (B2B) pricing or a complicated catalog, and then it isn’t. Or they’re on something heavily customized and living the upgrade cycle I just described. ACCS gives them the depth of Adobe Commerce without having to operate it. If they already use other Adobe products, it plugs into those as well.

How Adobe’s AI tools simplify migration

Migration is where most of these conversations stall. If you have ten years of PHP customization, the first question is "what happens to all that code?" Nobody wants to hear "rewrite it."

This is the part that’s changed most in the past year. We now have AI tooling at Adobe built for this exact situation. The Migration Assessment Tool (MAT) scans your existing codebase, maps each customization to the extension points it touches, rates the complexity, and lays out a phased plan. It also finds code that’s redundant or dead. On older stores, that pile is bigger than anyone expects, and every module you can delete is one you don’t have to migrate.

Then there are the AI coding tools for Commerce, which run inside the integrated development environment (IDE) developers already use. They connect a coding agent to Commerce and App Builder knowledge through Model Context Protocol (MCP) servers, including search over the current Commerce docs. In practice, that means help converting PHP extensions into App Builder apps that follow the patterns we’d recommend anyway, not just code that happens to compile.

Of course, none of this replaces an architect. You still need someone who knows why that strange pricing customization exists before deciding what to do with it. What the tools remove is the grind of reading through hundreds of modules by hand, and they’re more thorough than a person on day nine of a code review. I’ve been that person many times and have undoubtedly missed things.

You also don’t have to do it all at once. The current store can keep running while you move pieces over.

Why start your migration now

Every month on a self-managed platform adds a little more code you’ll eventually have to move. If you start migration to ACCS before your next upgrade cycle, you might be able to skip that upgrade entirely, and that’s usually the easiest budget conversation you’ll ever have.

As I said earlier, ten years ago I probably would have argued with my current self over this article. Time and experience have shown me that I would have ultimately lost that argument.