Shopify vs Adobe Commerce (Magento)

Shopify is a hosted product. You rent the platform, the infrastructure and the checkout, and you work inside defined boundaries. Adobe Commerce is a licensed application that somebody has to operate. Even in the Adobe-managed cloud variant, the application, its extensions and its deployments remain your responsibility or your partner's.

Almost everything else follows from that. On Shopify you cannot change the core, but somebody else carries availability, security and scaling. On Adobe Commerce you can override practically any behaviour, and you pay for it with a permanent team that keeps the application current and running in production.

Both routes are legitimate. The question is not which system can do more, but where you want to spend your budget: on operations and maintenance, or on range, content and conversion. If you do not answer that deliberately, you still answer it — through your operating costs for the coming years.

On Shopify you pay a subscription fee, payment and transaction fees, and the apps you choose to run. Hosting, scaling and platform updates are included. The cost curve is therefore reasonably predictable and depends more on your revenue than on your technical complexity. Surprises almost always come from the app stack.

On Adobe Commerce the bill has several lines: a licence or subscription based on a revenue tier, hosting or managed cloud operation, and an ongoing development budget for upgrades, security patches and extensions. That third line is routinely underestimated in business cases, because it never appears as its own item on an invoice.

Magento Open Source carries no licence fee. That shifts the cost rather than removing it: hosting, security patches, extensions and development effort all stay with you, and the deep B2B feature set of the commercial edition is not included. So never model the open source route as the free option; model its operating effort.

Adobe Commerce allows changes right down into the core. You can add your own entities, replace price calculation and rebuild the order process. If your business logic genuinely departs from the market, that is a real advantage: no SaaS system offers this depth, and no combination of apps replaces it completely.

On Shopify you extend around the edges. Apps take over functions, Functions cover custom discount and shipping logic, metafields carry your own data structures, and webhooks and APIs connect the systems alongside. That covers a great deal, but not everything: checkout stays configurable within defined limits, and the core stays untouchable.

The honest test is your backlog from the past twelve months. If the special requests are mostly about pricing rules, shipping logic and data enrichment, Shopify covers them without compromise. If they attach to the order object or the catalogue model itself, you will be working against the platform on Shopify rather than with it.

Adobe Commerce ships B2B natively and unusually deeply: company accounts with sub-accounts and roles, quote negotiation inside the shop, requisition lists, purchase limits and customer-specific catalogues. If you want to map those processes entirely inside the shop, this is the larger feature set, without buying and integrating additional software on top.

Shopify covers B2B through company profiles, assigned price catalogues, payment terms and order approvals. That holds up for merchants whose wholesale business is essentially customer-specific prices and repeat orders. These functions belong to the Plus offering rather than the smaller plans, and that belongs in every calculation you make.

The dividing line is the negotiated deal. Once quotes, approval chains and budget controls are the normal route to an order, Shopify becomes an integration project with apps or connected systems. If fixed catalogue prices per customer are enough, the day-to-day difference is far smaller than the feature lists suggest.

Adobe Commerce separates websites, stores and store views. That hierarchy allows separate catalogues, prices, tax rules and payment methods at each level, inside a single installation. For groups running many brands and countries that genuinely differ in commercial terms, this remains one of the strongest arguments for the system today.

Shopify solves internationalisation through Markets: countries are grouped into markets with their own currencies, price adjustments, languages and domains, but on a shared catalogue. That is faster to set up and easier to maintain, as long as your markets essentially sell the same range at different prices.

As soon as markets or brands have their own ranges, their own product data and their own processes, you will tend towards several stores on Shopify. That is workable and often done, but it means separate upkeep. This is exactly the point at which it pays to look honestly at how different your markets really are.

Magento 1 has had no official support for years. Anyone still running it is keeping the shop alive on agency patches and carrying the risk themselves. It is the most common real migration trigger we see — and one that eventually stops allowing the date to be pushed back another quarter.

Magento Open Source is still freely available and still developed in the open. But it is not the commercial edition: the deep B2B set, the managed cloud and vendor support belong to Adobe Commerce. So anyone coming from Open Source is rarely comparing genuinely like with like when they weigh up the options.

Moving from Magento to Shopify is first of all a data model project, not a design project. Attributes, attribute sets, configurable products and customer groups have to be mapped onto products, variants, metafields and catalogues. Those decisions come before the import, because they determine the handles and therefore the redirects.

On Shopify, platform updates run in the background. Your effort sits with the theme and the app stack: apps need reviewing regularly, because every additional app brings load time, data flows and one more dependency with it. The effort is real, but it is plannable and considerably smaller than a version upgrade.

On Adobe Commerce, version upgrades and security patches are projects in their own right. Every extension has to suit the target version, and every customisation has to be tested again. That is manageable when budget and team are planned in. Without that planning the installation ages until the upgrade becomes a project.

Do not treat this point as a detail. Across a five-year horizon it often decides total cost more strongly than the licence does. The sober question is this: do you want a team that keeps the platform running, or a team that works on the business itself every week?