Your server falls over at nine on a Friday evening and there is nobody to call. That is the pitch for cloud commerce, and it is a good one.
What the pitch skips is that "cloud" is not one product. It covers at least three different arrangements, with very different consequences for what you control, what you pay, and how hard it is to leave. Owners sign up for the first, discover the second in year two, and only meet the third when they try to move.
It is store software that runs on somebody else's servers and is paid for as a subscription. You get an admin login. You do not get a server to patch, a database to back up, or a call at two in the morning because a disk filled up.
The vendor takes hosting, security updates, capacity during traffic spikes, and the plumbing underneath. You keep products, pricing, marketing, and everything the shopper sees.
That is the whole idea. Every serious argument about cloud commerce is really an argument about exactly where that line sits.
Full software as a service. Shopify and BigCommerce are the obvious examples. The vendor owns both the software and the infrastructure, and you rent access to it. Fastest to launch, least to maintain, and the least room to do anything the platform did not already anticipate.
Managed cloud running software you control. Adobe Commerce on cloud infrastructure is the clearest case. The application is the Magento codebase, the same code a store can run on its own servers, but Adobe operates the environment. You can build custom modules and change how the store behaves. You cannot change the machine underneath it: Adobe's own Starter architecture documentation states that production environments are read-only, that permissions on those read-only file systems cannot be changed even by Adobe Support, and that the operating system and web server cannot be upgraded by the customer. Adobe sells two cloud architectures, Starter and Pro, so read the documentation for the one you are actually being quoted.
Self-managed on cloud infrastructure. Your open-source store running on a general cloud provider or a specialist ecommerce host. Cloud in the literal sense, and every operational decision still belongs to you or your agency. That tier is worth evaluating on its own terms, which we did in our ecommerce hosting buyer's guide.
Here is the part most owners miss: almost none of the platform work we get called into at Encomage involves someone who picked the wrong model. It involves someone who picked one model believing it was another, and only found out when they needed something the arrangement did not allow. Our rescue of an inherited Adobe Commerce store started exactly there.
The savings are real and they are worth naming honestly.
You stop sizing servers for a Black Friday peak you then pay for the other eleven months. On a self-managed store that capacity is bought in advance and sits idle most of the year, and the conversation about right-sizing it tends to happen once, in the wrong direction.
You stop owning security patching. This is the saving that matters most and gets discussed least. On a self-managed store it is a standing job: somebody has to watch for the release, read what it touches, test it against your customizations, and schedule the deploy. When we are called into an inherited store, unapplied patches are the most common thing we find, and the reason is almost never negligence. The job has no owner and no deadline, so it loses to whatever does.
For a store doing a few hundred orders a month with a small team and no in-house engineer, that trade is close to a straight win. If that is you, the rest of this article is a checklist for later rather than a decision for today.
The subscription is the visible number, and it is the least interesting one. As of August 2026, Shopify's published plans run at $29, $79 and $299 a month on annual billing, or $39, $105 and $399 if you pay month to month, with Plus starting from $2,300. Build your forecast on the second set of figures unless you have already committed to the year.
The costs that catch owners out are tied to sales rather than to the plan. If you take payment through any provider other than Shopify's own, Shopify adds a third-party transaction fee on top of whatever your processor already charges: 2% on Basic, 1% on Grow, 0.6% on Advanced and 0.2% on Plus, per that same pricing page.
Two details from Shopify's own billing documentation matter more than the percentage itself. The fee is calculated on the cost of products minus discounts, plus tax and shipping charges, so you pay it on money that was never your margin. And it is not returned to you when you refund the order.
Capability is metered by plan too, which is easy to miss at signup and expensive to discover later. On Shopify's own comparison table, checkout customization is listed as limited on every plan except Plus, where it becomes full. API access on the entry plan is listed as limited data access, and only becomes full from the tier above it. Basic, Grow and Advanced allow one headless storefront; Plus allows twenty-five. None of that is hidden, but it does mean the thing that eventually forces an upgrade is often a feature you assumed you already had.
Uptime promises get quoted in sales conversations far more often than they get read.
Adobe's Unified Service Level Agreement, effective 10 October 2023 and covering Adobe Commerce on Cloud production environments, sets a minimum uptime percentage of 99.9%. The document itself notes that a month like July contains 44,640 minutes, which puts that promise at roughly forty-five minutes of allowed downtime per month.
Miss it and you get a service credit: 5% of monthly fees when uptime lands between 99.5% and 99.9%, 10% between 95% and 99.5%, 15% between 90% and 95%, and 25% below 90%, capped at 25% cumulative in a month. Those credits are stated as Adobe's sole liability and the customer's sole and exclusive remedy. If a four-hour outage costs you six figures in orders, the contractual answer is a percentage off next month's licence fee.
The same agreement carries a list of excluded services that sit outside the uptime commitment entirely, including order management, the commerce integration framework and payment services. That is not unusual, and Adobe is not unusually strict here. It is simply that a published uptime percentage describes a refund policy rather than a promise about your revenue, and almost nobody reads far enough to notice.
Adobe is the worked example because its agreement is public and specific. Run the same reading on whichever platform you are actually shortlisting. The questions do not change: what percentage is committed, what the credit is worth in money rather than in percent, whether that credit is the only remedy available to you, which parts of the product sit outside the commitment, and whether the plan you are buying carries any uptime commitment at all or only the enterprise tier above it does.
Four questions, roughly in the order they will hurt you.
Who owns the code that makes your store different from your competitor's? On full software as a service, your differentiation mostly lives in themes and apps you licence rather than own. That is fine until it isn't.
What comes with you if you leave? Product, customer and order data usually export cleanly. Checkout logic, theme customization, app configuration and years of URL structure usually do not. This is the question that decides how expensive your next platform decision will be, which is why our ecommerce development engagements tend to start with it rather than with a build estimate.
Which of your requirements is the platform's edge case? Every business has one. Complex B2B pricing, multi-warehouse stock, an unusual tax position, a payment method that exists in one market only. Find yours and test it before you migrate, not after.
And what does the contract actually promise, measured in money? See above.
If you are weighing all this against staying on software you control, the comparison between Magento Open Source and Adobe Commerce walks the same trade-off from the other direction.
Most of the platform work we take on starts with a store that has outgrown the arrangement it was set up under, or inherited one nobody documented. That work usually opens with an unglamorous audit of what the current platform actually permits, because that answer decides whether the right move is a migration, a rebuild, or leaving well enough alone.
Let’s build something powerful together - with AI and strategy.
