A jacket looks like a simple thing to sell online. Photograph it. Name a price. Add a button. Then send the same jacket into another country, with another currency, a different payment method, and a different assortment. Add a wholesale customer whose price depends on a contract. Suddenly, the button is the easy part.
Adobe Commerce lives in those qualifications. The business descended from Magento supplies the catalogs, storefronts, pricing, checkout, and connections that let companies turn complicated selling arrangements into something a customer can use. Its natural audience includes retailers, manufacturers, distributors, and businesses running several brands or markets.
- The job: run B2B and consumer commerce, including the rules behind each purchase.
- The choice: managed SaaS, dedicated cloud, or a storefront layer over an existing engine.
- The catch: software still needs sound data, integration work, and people who understand the business.
01 The cart they wanted did not exist
Before Magento was a product, Roy Rubin and Yoav Kutner built websites for other people. They used osCommerce, an open-source shopping platform. In Kutner’s later account, maintaining their own fork of that software became uncomfortable; he could not find a suitable alternative. They began building Magento in 2007, initially for their own projects, then decided to release it as open source.
Magento launched in 2008. Its appeal was practical: merchants could change the software. Developers could extend it. In an interview that June, Rubin was already emphasizing multiple-store support. The feature that now sounds like enterprise architecture was there near the beginning.
The ownership changed more dramatically than that idea. eBay acquired Magento, Permira funds bought it from eBay in 2015, and Hillhouse announced a $250 million investment in January 2017. Adobe’s acquisition followed in 2018, at an announced $1.68 billion. The commercial platform became Adobe Commerce; Magento Open Source kept its name.
02 The customer is sometimes a company
Consider a hypothetical maintenance supplier. One buyer needs a hundred replacement parts. Someone else must approve the order. Their company has a negotiated price and permission to buy on credit. An ordinary consumer checkout leaves much of that transaction in someone’s inbox.
Adobe’s B2B tools give the buying company an account with users, roles, and permissions. Shared catalogs control product visibility and customer pricing. Buyers and sellers can negotiate quotes before orders are placed. Requisition lists support repeat purchases; purchase-order rules handle approvals. These are specific ways to move a sales process into self-service.
- 01Who is buying?Company + permissions
- 02What is their deal?Catalog + agreed pricing
- 03Who says yes?Quote + approval
- 04How do they pay?Order + credit terms
Illustrative workflow. Configuration and feature availability vary by offering.
That helps explain Adobe Commerce’s place among enterprise alternatives such as Shopify Plus, Salesforce Commerce Cloud, SAP Commerce Cloud, BigCommerce, and commercetools. The useful comparison begins with actual purchasing rules. A product count alone tells you remarkably little about how difficult a store will be to run.
03 The first year was the hard part
Helly Hansen offers a less tidy picture than a feature list. In Adobe’s historical case study, the outdoor brand described 55 sites with seven language options, along with different payment methods and delivery rules. Its team valued the ability to enter markets and handle traffic peaks. Getting there took work.
“The first year was pretty rough, but now it’s a fairly easy platform to work with.”
Theodor Tollefsen · Helly Hansen
The next constraint was publishing. The company’s mobile-first approach exposed difficulty scaling its WordPress content across languages. It chose Adobe Experience Manager in 2019 to improve that process. The lesson is useful: a working transaction system can reveal the next bottleneck. International expansion also requires a repeatable way to produce and distribute local content.

04 Three ways to move the machinery
On June 25, 2025, Adobe launched Commerce as a Cloud Service. It puts the platform on managed, multi-tenant infrastructure with automatic feature and security updates. The proposition is appealing to teams tired of spending their attention on upgrades. Dedicated Adobe Commerce on Cloud remains a separate option, with single-tenant infrastructure and a different operating model.
Adobe also launched Commerce Optimizer. It supplies storefront, catalog, and merchandising capabilities while an existing commerce engine continues processing transactions. A company can improve the shopping experience without replacing every system behind it. That is a meaningful concession to how much organizational knowledge accumulates inside established software.
Adobe manages the commerce platform and its updates.
A single-tenant deployment with a different maintenance model.
A storefront and merchandising layer; retain the transaction engine.
05 The bill includes the plumbing
Adobe sells Commerce through customized quotes. The business case needs more than the subscription: migrating product data, connecting inventory and accounting systems, testing checkout, supporting extensions, and paying transaction fees. Payment Services uses PayPal processing. Package inclusions and add-ons deserve a close reading.
Here is a practical buying exercise: ask every shortlisted vendor to demonstrate your awkward order. Use the customer with special prices, approval limits, unusual shipping, and a repeat purchase. Then ask who maintains each connection and what happens when it fails. Compare the whole operating bill.
A small shop with a straightforward catalog and limited technical support may struggle to justify this work. Likewise, choosing dedicated infrastructure while expecting the maintenance experience of managed SaaS creates a mismatch. Those are reasons to define the operating model before signing.
06 A new helper, an old responsibility
Adobe announced Commerce Developer Agent’s general availability in September 2026. Developers can describe requirements, refine an implementation blueprint, approve it, and generate App Builder extensions. Adobe’s documentation still calls for reviewing and testing generated code before production. The tool changes some of the work; responsibility for a functioning store remains.
The idea worth copying is older than the agent: make the next sale less dependent on someone remembering an exception. Give the rule a home, make it repeatable, and test it. The customer should be able to buy the jacket without discovering how complicated selling it became.