Choosing an eCommerce Platform: Shopify Plus vs WooCommerce vs Magento vs Custom

Why the platform decision is the one you least want to get wrong

I have built and scaled stores on Shopify and Shopify Plus, WooCommerce, Magento, plain WordPress, Webflow, and Wix, and the pattern is consistent: the platform you pick constrains everything you do afterward, and it is the hardest decision to reverse. You can rewrite copy in an afternoon. You can swap a theme in a week. Re-platforming a live store with real orders, real SKUs, real customer accounts, and real SEO equity is a six-figure project that eats a quarter of your roadmap and puts revenue at risk while it happens. So the platform choice deserves more thought than most teams give it, and far less brand loyalty.

The mistake I see most often is that the decision gets made emotionally or by default. A founder loved Shopify at their last company, so the new company gets Shopify. An agency only builds on Magento, so the client gets Magento even when the catalog does not justify it. A developer prefers open source, so a non-technical team ends up owning a WooCommerce stack they cannot maintain. None of those are decisions. They are habits wearing the costume of a decision. The right way to choose is boring and it works: write down your actual constraints, score each platform against them, and pick the one that fits, not the one with the best marketing or the loudest advocate in the room.

The second mistake is choosing for where you are today instead of where you will be in three years. A platform that is perfect for 50 orders a day can fall apart at 5,000. A platform that handles a 40-product catalog beautifully becomes a nightmare at 40,000 SKUs with configurable variants and tiered B2B pricing. The reverse is just as expensive: teams routinely buy enterprise commerce for a store that will never need it, then pay for capability they never use and complexity they cannot handle. You are not choosing a tool for this month. You are choosing the ground your business will stand on while it grows, and the goal is to buy exactly as much platform as your realistic trajectory needs.

I bring the same framing to every platform conversation. A commerce platform is really four things bundled together: a storefront (what shoppers see and how fast it loads), a commerce engine (catalog, cart, checkout, promotions, tax), an operations layer (orders, fulfillment, inventory, customer accounts), and an ecosystem (the apps, integrations, and developers you can hire). Different platforms are strong in different quadrants. Shopify is exceptional at storefront and ecosystem and deliberately limits the engine. Magento is a deep engine that demands a serious operations and development investment. WooCommerce gives you total control of all four and hands you the maintenance bill for all four. When you know which quadrant your business lives or dies in, the choice gets much clearer.

The rest of this guide is the method I actually use. First the real decision criteria, the ones that matter more than the feature lists on the pricing pages. Then honest deep-dives on Shopify and Shopify Plus, WooCommerce, Magento and Adobe Commerce, BigCommerce, and the case for going custom. Then a scorecard you can run against your own business, a realistic three-year cost model, migration considerations, the mistakes teams make, and a worked example that matches a specific business profile to a platform. I am not going to tell you there is a winner, because there is not. I am going to give you a way to find your winner.

The real decision criteria (not the feature lists)

Every platform's marketing page is a wall of checkmarks, and almost none of those checkmarks decide if the platform is right for you. The criteria that actually matter are the ones that map to your constraints and your roadmap. These are the eleven I score, roughly in the order they tend to break a decision.

• Total cost of ownership over three years. Not the monthly sticker price. The fully loaded cost: license or subscription, hosting, the build, apps and extensions, ongoing maintenance and developers, transaction fees, security and PCI, and the eventual migration. Cheap platforms are often expensive and expensive platforms are sometimes cheap once you add it all up.
• Time to launch. How fast can you have a real store taking orders. A SaaS platform can put you live in weeks. A custom or Magento build is measured in months. If speed to market is the whole game, that alone can decide it.
• Catalog complexity. Number of SKUs, variants per product, configurable and bundled products, and how often the catalog changes. A few hundred simple products is a different problem than 100,000 SKUs with complex variant matrices and frequent price changes.
• B2B and wholesale needs. Company accounts, customer-specific and tiered pricing, quotes, purchase orders, net terms, approval workflows. Some platforms treat this as first-class; on others it is a bolt-on that fights you.
• Customization ceiling. How much you can change the checkout, the pricing logic, the catalog model, and the backend behavior. This is where SaaS platforms draw a hard line and open source gives you everything.
• Developer resources. The team you actually have or can afford to hire. A platform your team cannot maintain is the wrong platform no matter how powerful it is.
• Ecosystem and apps. The depth of pre-built integrations and extensions, so you buy capability instead of building it. This is one of Shopify's biggest real advantages and one of custom's biggest real costs.
• Headless readiness. Does the platform expose clean APIs so you can decouple the storefront if and when you need to, without a full re-platform.
• SEO control. How much access you have to URLs, redirects, structured data, page speed, and the technical levers that decide if you can rank.
• PCI and security. Who carries the compliance burden and the breach risk. SaaS platforms absorb most of it; self-hosted hands it to you.
• Scale and reliability. Peak traffic, uptime, and how the platform behaves on your biggest sales day, which is exactly when it matters most and exactly when weak setups fall over.

The trick is not to score all eleven equally. Weight them for your business. A content-led brand that lives on organic and lifestyle blogging should weight SEO control and storefront flexibility heavily. A B2B distributor with 60,000 SKUs and tiered pricing should weight catalog complexity, B2B features, and the engine. A funded startup racing to launch should weight time to market and ecosystem so it can buy capability instead of building it. A regulated enterprise should weight security, scale, and reliability above almost everything. When you weight the criteria honestly, the platforms sort themselves, because no platform is strong on all eleven and the tradeoffs are real. Anyone who tells you their platform wins every category is selling, not advising.

One more thing about criteria: separate the ones that are dealbreakers from the ones that are preferences. A dealbreaker is a constraint that, if unmet, rules a platform out entirely. If you legally require self-hosting your customer data on your own infrastructure, that eliminates the pure SaaS options and no amount of other strengths saves them. If you need to launch in six weeks, that eliminates a ground-up Magento build regardless of how capable it is. Find your dealbreakers first, use them to cut the list to a realistic shortlist of two or three, and only then score the preferences that decide between the survivors. Most agonized platform decisions are agonized because the team never separated the constraints that actually rule things out from the nice-to-haves that do not.

Shopify and Shopify Plus: the fastest path to a serious store

Shopify is the platform I recommend most often, and it is worth being honest about why: for the large majority of stores, the things Shopify does automatically are exactly the things teams get wrong when they have to do them themselves. It is fully hosted SaaS, so you never touch a server, a security patch, or a scaling config. It carries PCI compliance for you. It gives you a fast global CDN, automatic sitemaps and canonicals, a checkout that converts as well as anything on the market, and the deepest app ecosystem in commerce. You can be live and taking real orders in weeks, and the store will stay fast and secure without a systems engineer on staff. For a founder who wants to sell, not to run infrastructure, that is a genuinely strong offer.

The theming language is Liquid, which is approachable, and the Online Store 2.0 architecture with sections and blocks makes merchandising flexible without touching code. The app store means most capability you need, subscriptions, reviews, loyalty, upsells, advanced shipping, is a few clicks away instead of a development project. That ecosystem is the underrated moat: you are buying more than software, you are buying access to thousands of pre-built integrations and a huge pool of developers who know the platform. When something breaks at 11pm on Black Friday, there are a lot of people who can fix it.

Shopify Plus is the enterprise tier, and it is where the platform stops being a small-business tool and becomes something you can run a large operation on. Plus adds the pieces serious brands need: checkout customization through Checkout Extensibility (the successor to the old checkout.liquid, so you can add logic and UI to the highest-converting page without the old lock-in), Shopify Functions for custom discount, shipping, and payment logic that runs on Shopify's own infrastructure, native B2B with company accounts and price lists, multiple expansion stores for regions and brands under one contract, higher API limits, Shopify Flow for automation, and access to Hydrogen and Oxygen if you want to go headless on React without leaving the ecosystem. Plus lists around 2,300 dollars a month (moving toward variable pricing at the top end), which sounds like a lot until you compare it to a fully loaded Magento or custom operation.

Now the honest limits, because they are real and they matter. Shopify is opinionated, and its opinions are a hard ceiling on some kinds of customization. The checkout, even with extensibility, is not a blank canvas the way a self-hosted checkout is. The data model is Shopify's, so deeply custom catalog structures, unusual pricing logic, or complex product configurators can fight the platform rather than flow with it. You do not own your infrastructure or, in a real sense, your platform: you rent it, and Shopify can change pricing, deprecate APIs, or adjust terms, and you adapt. App costs stack quietly, and a store running fifteen apps at 20 to 100 dollars a month each has a real monthly bill hiding under the subscription. And if you do not use Shopify Payments, you pay an extra transaction fee on top of your gateway, which is a deliberate nudge that costs high-volume stores real money.

Who Shopify Plus is right for: direct-to-consumer brands and mid-market retailers who want speed, reliability, and a huge ecosystem, and whose customization needs live mostly in the storefront and merchandising rather than in exotic backend logic. Who it is wrong for: businesses whose core requirement is a deeply custom commerce engine, whose catalog or pricing model does not fit Shopify's data structures, or who have a hard requirement to self-host their data. I have moved brands onto Plus and watched them scale cleanly for years, and I have also watched a team fight Shopify for eighteen months trying to force a configurator-heavy industrial catalog into a model that was never built for it. The platform is excellent. It is not universal, and the teams that are happiest on it are the ones whose needs match its opinions rather than the ones trying to override them.

WooCommerce: total control, and the maintenance bill that comes with it

WooCommerce is the WordPress plugin that turns a WordPress site into a store, and it powers a huge share of the web precisely because it inherits WordPress's reach, flexibility, and content strength. It is open source and the core plugin is free, which is where a lot of the confusion starts, because free-to-download is not free-to-run. You provide the hosting, the security, the performance tuning, the plugin stack, and the developer time, and those are the real costs. What you get in return is something no SaaS platform gives you: complete control of every layer, full ownership of your data and infrastructure, and the ability to change literally anything because you have the code.

The single biggest reason to choose WooCommerce is content-led commerce. It sits on top of the best content management system on the web, so if your growth strategy is organic search, blogging, guides, and rich editorial around your products, nothing beats having your store and your content in the same WordPress install with the same SEO tooling. I have built brands where the blog was the entire top of the funnel, and WooCommerce let the commercial pages and the content pages live as one integrated site with total control over URLs, structured data, redirects, and page speed. For SEO control specifically, WooCommerce gives you more raw access than any hosted platform, because there is no layer between you and the HTML.

The second reason is cost at small scale and flexibility at every scale. A small store can run WooCommerce on modest hosting for very little, and because you have the code, you can build custom functionality that would be impossible or app-dependent on a hosted platform. Custom pricing logic, unusual product types, bespoke integrations with an ERP or a niche fulfillment system: if a developer can write it in PHP, you can have it. The plugin ecosystem is enormous, so much of what you need already exists as an extension, and when it does not, you build it.

The honest cost of that freedom: you own everything, including the problems. Security is yours. WordPress and WooCommerce sites are a large attack surface, and an unpatched plugin is how stores get compromised, so you need real security discipline, updates, backups, and monitoring. Performance is yours. WooCommerce does not scale itself; a large catalog or a traffic spike needs proper hosting, caching, a CDN, and database tuning, and a store that was fast at 200 products can crawl at 20,000 without work. PCI is yours: using a hosted gateway like Stripe or PayPal keeps you in the lighter SAQ A scope, but the responsibility sits with you, not a SaaS vendor. And plugin conflicts are a genuine tax: every store is a unique stack of a theme plus a dozen plugins, and updates can break each other in ways that need a developer to untangle.

Who WooCommerce is right for: content-driven brands, businesses that need deep customization without enterprise budgets, teams that already live in WordPress, and anyone for whom owning the infrastructure and data outright is a real requirement. It is also a strong choice when you have or can afford competent WordPress development, because that is the hidden prerequisite. Who it is wrong for: a non-technical team with no developer relationship who wants to set it and forget it, because WooCommerce is not set-and-forget, and a very large, high-traffic, high-complexity operation that would be better served by a platform built for that scale. The freedom is real, and so is the responsibility. I tell teams the truth: WooCommerce gives you a car with no speed limiter and no mechanic included. Some businesses want precisely that; others should run from it.

Magento and Adobe Commerce: enterprise power with an enterprise price

Magento is the platform people reach for when the catalog gets serious, and for good reason: it was built for large, complex commerce, and it does things the SaaS platforms simply cannot. It comes in two forms, and the distinction matters. Magento Open Source is the free, self-hosted community edition. Adobe Commerce is the paid, licensed version (Adobe bought Magento in 2018), and its license is priced on your gross merchandise value, running from roughly the low tens of thousands into six figures a year for large merchants, with a cloud-hosted option on top. Both are heavy, powerful, and demanding.

What Magento does well is depth. Native multi-store and multi-website from one installation, so you can run many brands, regions, and storefronts under one backend. A catalog model built for scale, with configurable, bundled, grouped, and virtual products, complex attribute sets, and hundreds of thousands of SKUs. First-class B2B in Adobe Commerce: company accounts, shared catalogs, tiered and customer-specific pricing, quotes, purchase orders, and approval hierarchies, all native rather than bolted on. Sophisticated promotions and pricing rules. Deep customization, because it is open source at its core and a strong development team can change anything. If your requirements are a large catalog, complex pricing, real B2B, and multiple storefronts, Magento is often the platform that actually fits where a SaaS ceiling would block you.

The price of that power is that Magento is genuinely hard, and this is where teams underestimate it. It needs a serious, specialized development team; Magento developers are a distinct and expensive skill set, and a good agency relationship is not optional. It needs robust, often costly hosting, because Magento is resource-hungry and a poorly hosted Magento store is a slow Magento store. Builds are measured in months, not weeks. Upgrades and maintenance are ongoing real work, not a background task. And the total cost of ownership, license plus hosting plus development plus maintenance, lands well into six figures a year for a serious Adobe Commerce operation. This is not a platform you choose to save money. It is a platform you choose because your complexity justifies the investment.

There is also a strategic reality worth naming. The mid-market has been steadily leaving Magento for Shopify Plus and BigCommerce over the last several years, because those platforms closed much of the feature gap while removing the operational burden. Magento's sweet spot has narrowed to genuinely large and complex operations, particularly B2B and multi-brand enterprises, where its depth still wins. For a headless build, Adobe offers PWA Studio, and Magento's GraphQL API makes it a capable commerce engine behind a decoupled front end, which is increasingly how large Magento builds are architected. But if you are a mid-market DTC brand choosing Magento in 2026, I would push back hard and ask what specific requirement is forcing you toward that complexity, because for most such brands the answer is none.

Who Magento and Adobe Commerce are right for: large merchants with complex catalogs, serious B2B requirements, multiple storefronts, and the budget and engineering team to run an enterprise platform. Who they are wrong for: small and mid-size teams without dedicated development resources, and anyone choosing it for prestige rather than a concrete requirement it uniquely meets. I have shipped on Magento and respect it, but I have also seen it crush teams that bought the power without the operational capacity to wield it. The platform is a Formula 1 car. It is astonishingly capable in the right hands, and it will end you if you do not have a pit crew.

BigCommerce: the SaaS alternative that gets overlooked

BigCommerce is the platform that gets left out of the conversation, and that is a mistake, because for a specific kind of business it is the best answer on the board. It is hosted SaaS like Shopify, so you get the same operational relief: no servers, no patching, PCI carried for you, a fast platform that scales without you tuning it. Where it differentiates is philosophy. BigCommerce leans into being open, publishing strong APIs and positioning itself as headless-friendly out of the box, and it builds more commerce features into the core so you depend less on paid apps. The two decisions that flow from that, no transaction fees on any plan and more native functionality, are its strongest selling points.

Let me take those in turn, because they are real money. BigCommerce charges no additional transaction fee regardless of which payment gateway you use, where Shopify charges an extra fee if you do not use Shopify Payments. For a high-volume store that wants to use a specific gateway, that difference compounds into a meaningful number over a year. And because more features are native, no-cost multi-currency, product options and variants without an app, built-in faceted search on higher plans, robust B2B on the B2B Edition, you install fewer paid apps to reach the same functionality, which lowers the quiet stacking cost that catches Shopify stores. On paper, for a growing mid-market merchant, that math is attractive.

BigCommerce is also a genuinely strong headless option, and it markets itself that way honestly. Its APIs are mature, and a common architecture is BigCommerce as the commerce engine behind a Next.js or other modern front end, giving you SaaS operational simplicity on the backend with full front-end freedom. If you like the idea of not running infrastructure but you want more storefront control than a templated theme allows, BigCommerce as a headless backend is one of the cleaner paths to that, and often a lighter lift than going fully composable.

The honest weaknesses: the app and theme ecosystem is much smaller than Shopify's, so while you need fewer apps, the ones you do need may not exist, and you have fewer designers and developers who specialize in the platform. That thinner ecosystem is the real tradeoff for the richer core. BigCommerce also enforces annual sales thresholds per plan tier, so crossing a revenue line forces you up to the next plan even if you do not feel you have outgrown it, which some merchants find frustrating. And the storefront theming, while capable, has historically been less loved by designers than Shopify's, which is part of why headless is a popular route on it.

Who BigCommerce is right for: growing mid-market and B2B merchants who want SaaS simplicity without transaction fees, who value more built-in functionality over the largest app ecosystem, and who may want a headless architecture without running their own infrastructure. It is a particularly strong B2B SaaS option, an area where Shopify only recently got serious. Who it is wrong for: a store that depends on a specific app or integration that only exists in the Shopify ecosystem, or a design-led brand that wants the deep bench of Shopify theme talent. My honest take is that BigCommerce loses a lot of deals it should win, purely because Shopify's brand and ecosystem gravity pull the default choice. If you are evaluating Shopify Plus, put BigCommerce on the shortlist and run the numbers, because for B2B and for fee-sensitive high-volume stores it frequently comes out ahead.

Going custom: composable, headless, and building your own

At some point a business asks if it should just build its own commerce, and the honest answer is: almost never, and when the answer is yes, you already know it. Going custom means assembling your storefront and commerce logic from parts rather than buying a packaged platform. In 2026 that usually means one of two shapes. Either a headless build where a packaged commerce engine (Shopify's Storefront API, BigCommerce, commercetools, or an open-source engine like Medusa or Saleor) sits behind a fully custom front end built in something like Next.js, or a fully composable MACH architecture where you wire together best-of-breed services, a commerce API, a separate CMS, a separate search provider, a separate payment and tax layer, through APIs into a system you own end to end.

The appeal is total control and no ceiling. Every pixel of the storefront, every step of the checkout, every piece of catalog and pricing logic is yours to define. You are not constrained by a platform's opinions, its data model, or its roadmap. For a business whose commerce experience is a genuine competitive differentiator, a highly custom configurator, an unusual purchasing model, a content and commerce fusion that no template supports, that freedom is the whole point. Headless also lets you deliver a very fast storefront, because you control the rendering, and to publish to many channels, web, app, kiosk, marketplace, from one commerce backend. The composable promise is that you swap any component without replatforming the whole, so you are never again locked into one vendor's weakest module.

Now the reality, because this is where dreams meet payroll. Custom is the most expensive and slowest option by a wide margin, and the cost never stops. You need a real engineering team, not a developer and an agency retainer, an actual team, and you need it forever, because you now own the maintenance, security, scaling, and every integration that a platform used to handle for you. The build is measured in many months. Every capability that comes free on Shopify, a working checkout, tax calculation, fraud screening, an admin your ops team can use, you either build or integrate and maintain. Composable's flexibility is also its complexity: five best-of-breed services means five vendors, five contracts, five integration points, and five things that can break, and someone has to own the seams between them. The total cost of ownership is the highest of any option here, and the risk is real.

So the decision rule I use is strict. Go custom only when the commerce experience is a core differentiator that no platform can deliver, and you have the engineering capacity to build and run it indefinitely, and the scale to justify the cost. That describes very large or very unusual businesses and almost no one else. For the vast majority, a good SaaS platform with selective headless where it counts gives you most of the flexibility at a fraction of the cost and risk. The smart middle path most teams should consider first is headless-on-SaaS: keep Shopify or BigCommerce as the commerce engine so you inherit checkout, PCI, and operations, and build a custom front end only where storefront differentiation actually pays off. That gives you the parts of custom that matter without owning the parts that only hurt.

The failure mode I have watched more than once is a mid-size team talking itself into a full composable build because it sounds sophisticated and modern, then spending a year and a large budget rebuilding capabilities that Shopify would have handed them for a monthly fee, and shipping late with a smaller feature set than a templated store. Composable is a genuine architecture for the businesses that need it. It is also a very expensive way to feel advanced if you do not. Be ruthlessly honest about which one you are, because the market is full of people who will happily sell you the expensive version.

One more thing worth saying about the open-source commerce engines specifically, because they are gaining real momentum and they change the math a little. Tools like Medusa and Saleor let you self-host a modern, API-first commerce backend without a Shopify or commercetools subscription, and for a team with strong engineering they are a legitimate foundation for a custom build at a lower license cost than the enterprise composable vendors. But do not let the lower license fool you: you are still paying the full custom price in engineering time, hosting, security, and maintenance, and you are betting on a smaller ecosystem than the established platforms. They are a good answer for a specific profile, an engineering-led business that wants ownership and modern architecture and has the team to run it, and a trap for anyone choosing them to save money without the team to back it up. The license was never the expensive part of going custom. The people were.

The decision framework: a scorecard you can actually run

Enough deep-dives. Here is how you turn all of this into a decision instead of a debate. I run a weighted scorecard, and it takes an afternoon, and it is worth more than any amount of arguing about which platform is best in the abstract, because it forces the conversation onto your constraints instead of the platforms' marketing. The method is simple: list your criteria, weight them for your business, score each shortlisted platform, multiply, and add. The platform with the highest weighted score is your answer, and the exercise of building the scorecard usually makes the answer obvious before you finish the math.

Step one, shortlist with dealbreakers. Take the eleven criteria from earlier and find the two or three that are hard constraints for you. Must launch in six weeks. Must self-host data. Must support native tiered B2B pricing across 40,000 SKUs. Use those to cut five platforms down to a realistic two or three. Do not score platforms that a dealbreaker already eliminated; it wastes time and tempts you to talk yourself back into a bad fit.

Step two, weight the criteria. Assign each surviving criterion a weight from 1 to 5 based on how much it matters to your specific business, where 5 is decision-critical and 1 is barely relevant. This is the most important step and the one teams rush. A content-led DTC brand and a B2B distributor will produce completely different weightings from the same criteria list, and that is the point: the weighting is where your business's actual priorities enter the math. Do it as a team so the weights reflect a shared reality, not one person's preference.

Step three, score each platform 1 to 5 on each criterion, honestly, based on how well it meets your need, not on general reputation. Shopify scores high on time-to-launch and ecosystem, lower on customization ceiling. Magento scores high on catalog depth and B2B, low on time-to-launch and cost. WooCommerce scores high on customization and SEO control, low on hands-off maintenance. Multiply each score by the criterion's weight, sum the columns, and you have a weighted total per platform. The numbers rarely surprise the people who built the weighting honestly, because the act of weighting already surfaced the priorities. What the scorecard adds is a defensible, written record of why you chose what you chose, which is exactly what you want when someone questions the decision a year later.

One practical tip on running the scorecard as a group: have each stakeholder weight and score independently first, then compare, because the disagreements are the most useful output of the whole exercise. When the head of engineering weights customization at 5 and the head of marketing weights time-to-launch at 5, that is not a problem with the scorecard, it is your two priorities made visible, and you resolve it as a business decision rather than letting whoever runs the meeting quietly win. I have seen a platform choice flip entirely once the team saw, in numbers, that they had been optimizing for a constraint that mattered to one department and not to the business. The scorecard is as much a tool for surfacing disagreement as for producing a total.

A few disciplines make the scorecard trustworthy. Weight before you score, so you are not tempted to inflate weights to justify a platform you already picked. Score against your need, not the platform's overall quality; a platform can be excellent and still score low for you because its strengths are not your priorities. Include cost as a scored criterion rather than treating it separately, because a platform can win on capability and lose on total cost, and the scorecard should surface that tension rather than hide it. And treat a near-tie as real: if two platforms score within a few points, the decision is genuinely close, and you should break the tie on the softer factors, which team is more excited to build on it, which ecosystem you trust more for the next five years, rather than pretending the math is more precise than it is. The scorecard is a thinking tool, not an oracle. Its job is to make the tradeoffs explicit so the decision is made on your reality instead of on a sales deck.

Total cost of ownership: what these platforms really cost over three years

The sticker price is the least important number in a platform decision, and it is the only one most teams look at. What matters is the fully loaded cost over three years, because that is the horizon over which you will live with the choice, and the ranking of platforms by three-year cost is often the reverse of their ranking by monthly price. A free platform can be the most expensive one you run, and a platform with a scary monthly fee can be the cheapest once you count everything. Here is the model I use, and the line items people forget.

There are seven cost buckets in any real commerce operation. The subscription or license: Shopify's tiers, Shopify Plus at roughly 2,300 dollars a month, BigCommerce's plans, Adobe Commerce's GMV-based license into six figures, or zero for WooCommerce and Magento Open Source core. Hosting: near zero on SaaS because it is bundled, real and sometimes large on self-hosted WooCommerce and Magento, especially at scale. The build: weeks of work on SaaS, months on Magento or custom, and developer time is the single biggest hidden cost in most builds. Apps and extensions: the quiet monthly stack that can rival the subscription on an app-heavy Shopify store, lower on feature-rich BigCommerce, license-based on Magento extensions. Maintenance and development: ongoing, small on SaaS, substantial on self-hosted and custom where you own updates, security, and fixes. Transaction fees: Shopify's extra fee if you avoid Shopify Payments, gateway fees everywhere, zero platform fee on BigCommerce. And security and PCI: carried for you on SaaS, your cost and your risk on self-hosted.

The pattern that emerges is consistent. SaaS platforms front-load a visible subscription and back-load very little, so the three-year cost is predictable and the surprises are small. Self-hosted platforms show a low or zero license and hide the cost in hosting, development, maintenance, and security, so the three-year cost is higher than the sticker suggests and less predictable. Custom is the highest on every bucket except license and never stops, because you are permanently funding an engineering team to run what a platform would have run for you. When I model this out honestly for a mid-market store, a well-run Shopify Plus operation and a well-run WooCommerce operation can land closer than teams expect, because Shopify's subscription is offset by WooCommerce's development and maintenance load, and the deciding factor becomes which kind of cost your business is better structured to carry: a predictable vendor fee or an internal engineering burden.

A few numbers to make it concrete, understanding that every business is different and these are directional, not quotes. A small WooCommerce store can genuinely run for a few hundred dollars a month all-in, which nothing else here matches at the bottom. A mid-market Shopify Plus store typically runs the 2,300-a-month subscription plus a few hundred to a couple thousand in apps plus periodic development, landing in a predictable band that a finance team can plan around. A serious Adobe Commerce operation routinely exceeds one hundred thousand dollars a year fully loaded once license, hosting, and the specialized development team are counted. A custom composable build starts higher than all of them and stays there. The right question is never which is cheapest in the abstract. It is which delivers the capability you actually need at the lowest three-year cost, and that answer depends entirely on your requirements.

One cost bucket almost everyone forgets: the exit. Every platform has a switching cost, and it belongs in the model even though you hope never to pay it. A store built deeply into one platform's proprietary features, Shopify's checkout apps, Magento's custom modules, a bespoke composable stack, is expensive to leave, and that lock-in has a real, if deferred, price. Platforms with clean data export and standards-based architecture are cheaper to exit, which is worth something even if you never do. I factor a re-platforming reserve into any long-term model, because the industry average store re-platforms every several years, and pretending you never will just means the cost arrives as a surprise instead of a plan.

Migration: moving platforms without torching your traffic

Re-platforming is the highest-risk project in commerce, and most of the damage teams suffer is self-inflicted and avoidable. When you move platforms you are moving four things at once, the catalog, the customers and orders, the design, and the SEO equity, and each one has a way to go wrong that costs you revenue on launch day. I have run migrations that gained traffic and I have cleaned up migrations that lost half their organic overnight, and the difference was almost never the platform. It was the plan.

The single most important thing in any migration is the URL map. Your old store has years of ranking URLs with links and equity pointing at them, and your new platform will structure URLs differently, its own patterns for products, collections, and pages. If you launch without a complete, tested set of 301 redirects from every old URL to its new equivalent, you drop those rankings, and you drop them at the worst possible moment. Before anything else, crawl the old site, export every URL that has traffic or links, map each to its destination on the new platform, and have those 301s ready to go live the instant you cut over. This one discipline is the difference between a migration that holds its traffic and one that craters. Redirect the images too, and the old sitemap, and anything an external link might point at.

Data migration is the next battleground, and the trap is assuming it is a clean export-import. Products, variants, categories, customers, order history, and reviews all have to move, and the data models rarely line up one to one between platforms. Custom fields, metafields, and attributes are where migrations quietly lose information. Budget real time for mapping the old catalog structure onto the new one, especially if you are moving between very different models, a flat WooCommerce catalog into Shopify's collection structure, or a Magento configurable-product setup into something simpler. Test the import on a staging store, check a sample of products by hand, and confirm that variants, pricing, and inventory came across correctly before you trust it. Reviews are worth migrating carefully, because they are hard-won trust signals you do not want to abandon on the old platform.

Then there is the launch itself, and the rule is: never big-bang a migration without a staging rehearsal. Build the new store fully on a staging environment, load real data, test checkout end to end with real payment and tax, run a full crawl to catch broken links and missing redirects, and only then cut over. Keep the old store's analytics and Search Console running so you can watch for ranking drops in the days after launch and react fast. Expect a short dip; even a well-executed migration often sees a brief wobble as search engines recrawl and reprocess, and the sign of a good migration is that it recovers within weeks rather than never. If traffic drops and does not come back, it is almost always a redirect or indexing problem, and Search Console will show you exactly which URLs are failing.

The strategic advice I give before any migration is to question if you should do it at all, because re-platforming is sometimes the expensive answer to a problem that was really about execution rather than platform. If your Shopify store is slow because it runs twenty apps, moving to Magento will not fix that, it will give you new and harder problems. If your WooCommerce store keeps breaking, the issue might be a bad host and a bad plugin stack, not WordPress itself. Re-platform when you have hit a genuine, structural ceiling that your current platform cannot clear, native B2B you cannot get, catalog scale it cannot handle, a customization it forbids, not when you are frustrated with a fixable execution problem. And when you do migrate, treat the URL map and the staging rehearsal as non-negotiable, because those two disciplines prevent the large majority of migration disasters I get called in to fix.

The criteria people underrate: SEO control, PCI, and scale

Three criteria get less attention than they deserve in platform decisions, and each one can quietly decide if a store succeeds. They are the technical SEO control the platform gives you, who carries the PCI and security burden, and how the platform behaves at real scale on your biggest day. I want to spend a section on them because they rarely make the sales pitch and they always make the difference.

SEO control first, because organic search is free, compounding traffic and the platform sets your ceiling on it. What you need is access to the technical levers: clean editable URLs, full control of title tags and meta descriptions, the ability to add and edit structured data, control of redirects, editable robots and sitemaps, and enough control of the front end to hit Core Web Vitals. The platforms differ more than their marketing admits. WooCommerce on WordPress gives you the most raw access of anything here, because there is no layer between you and the HTML, which is why content-led SEO brands love it. Shopify gives you strong fundamentals, automatic sitemaps, canonicals, fast hosting, but historically limited things like editing robots.txt (now possible) and forces some URL structures, so you work within its patterns. Magento is highly capable but its SEO strength depends on a competent developer configuring it, because a misconfigured Magento store generates URL and duplicate-content chaos. If organic is your growth engine, weight this criterion heavily and test the actual level of control before you commit, because getting it wrong caps your cheapest channel.

PCI and security is the criterion teams ignore until it becomes the only thing that matters. Every store that takes card payments has to meet PCI DSS, and the question is who carries that burden. On hosted SaaS, Shopify, BigCommerce, the platform maintains PCI compliance for its infrastructure and, if you use its payment layer, keeps you in the lightest compliance scope. On self-hosted WooCommerce and Magento, the responsibility is yours, though using a hosted gateway like Stripe or PayPal that keeps card data off your servers reduces your scope to the lighter SAQ A rather than the full audit. Beyond PCI, security is a live cost on self-hosted platforms, unpatched WordPress plugins and Magento vulnerabilities are how stores get breached, and a breach is existential, both the direct damage and the trust you lose. If you do not have the security discipline to patch, monitor, and back up a self-hosted store, that is a strong argument for SaaS, where the vendor carries most of that risk. This is a genuine reason SaaS wins for teams without security expertise, and it belongs in the scorecard.

Scale and reliability is the criterion that only reveals itself on your biggest day, which is exactly when you cannot afford to learn the lesson. Black Friday traffic is many times your normal load, and a platform that is fine on a Tuesday can fall over under a spike if it is not built for it. SaaS platforms handle this for you: Shopify and BigCommerce absorb enormous traffic spikes because that is their job and their infrastructure, and their uptime records are strong. Self-hosted platforms scale only as well as you build and host them; a WooCommerce or Magento store needs proper hosting, caching, a CDN, and load testing to survive a spike, and a store that was never load-tested is a store betting its best day on luck. If your business has sharp seasonal peaks, weight reliability and test it, because an outage during your highest-revenue hour is the most expensive kind of platform failure there is, and it is entirely preventable with the right platform or the right infrastructure work.

The through-line across all three is that they are invisible when things go well and catastrophic when they go wrong, which is exactly why teams underrate them. Nobody notices good PCI compliance until a breach, or good scale until an outage, or good SEO control until a competitor with more of it outranks them for years. Put them in the scorecard with honest weights for your situation, because the criteria that never make the demo are frequently the ones that decide if the store still exists in three years.

The mistakes teams make choosing a platform

I have watched enough platform decisions go sideways to know the mistakes are predictable, and almost every one of them comes from choosing for the wrong reason or the wrong time horizon. Here are the ones that cost the most, in the order I see them.

Choosing on brand and hype instead of fit. Shopify is the default because it is the loudest, and it is often right, but defaulting to it without checking fit is how a complex B2B distributor ends up fighting a DTC platform, or a store that needed BigCommerce's economics pays Shopify's transaction fees for years. Every platform here is the best choice for some business and the wrong choice for others. The brand is not the decision.

Buying for today and ignoring three years out. A platform perfect for 50 orders a day that cannot handle 5,000, or perfect for 40 products that collapses at 40,000, is a re-platform waiting to happen, and re-platforming is a six-figure project you inflicted on yourself by choosing short-sighted. Match the platform to your realistic trajectory, not just your current size.

Over-buying enterprise for a store that will never need it. The opposite error, and just as expensive. Teams choose Magento or a custom composable build for prestige or future-proofing, then pay for complexity they cannot handle and capability they never use, and ship late with a worse store than a SaaS platform would have given them in a quarter of the time. Buy the platform your requirements justify, not the one that sounds impressive.

Ignoring total cost of ownership and looking only at the monthly price. A free platform with a large development and maintenance burden can cost more over three years than a platform with a scary subscription and near-zero operational load. Model all seven cost buckets or you are not comparing prices, you are comparing stickers.

Underestimating the developer requirement. Choosing WooCommerce, Magento, or custom without the development capacity to run it is the most common way teams end up stuck: a powerful platform nobody on the team can maintain is worse than a limited one they can. Be honest about the team you actually have, not the one you wish you had.

Forgetting the exit. Building deeply into one platform's proprietary features without a data-export and portability plan means the eventual migration is far more expensive than it needed to be. You do not have to plan to leave, but you should never build yourself into a corner you cannot afford to leave from.

Letting the loudest voice in the room decide. The developer who prefers open source, the founder who loved a past platform, the agency that only builds on one thing: none of those preferences are your business's requirements. The scorecard exists precisely to take the decision away from whoever argues hardest and give it to your actual constraints. Run it, weight it honestly as a team, and let the criteria decide, because a platform chosen by preference is a platform you will question every time it disappoints you, and a platform chosen by an honest scorecard is one you can defend for years.

A worked example: matching three businesses to three platforms

Let me make the method concrete by running it on three real business profiles, because seeing the scorecard applied is worth more than another list of principles. These are composites of engagements I have run, and in each one the platform fell out of the constraints once we weighted them honestly.

Profile one: a direct-to-consumer apparel brand, 300 products, growing fast, small non-technical team, growth driven by paid social and email, planning to lean harder into organic content. Their dealbreakers: must launch quickly, no in-house developers, needs a beautiful storefront and a huge ecosystem to buy capability instead of building it. We weighted time-to-launch, ecosystem, storefront flexibility, and low maintenance heavily, and catalog complexity and B2B low because neither applied. Shopify won going away. It launches in weeks, carries the operational load a non-technical team cannot, has the deepest ecosystem for the subscriptions, reviews, and upsell apps a growing DTC brand wants, and the storefront talent pool is unmatched. This is Shopify's home turf, and forcing anything more complex on this team would have been a mistake. If their organic content ambition had been the entire strategy and they had a WordPress developer, WooCommerce would have entered the conversation, but with no developer, Shopify was the honest answer.

Profile two: a B2B industrial distributor, 60,000 SKUs, complex configurable products, customer-specific and tiered pricing, net terms, purchase orders, and approval workflows, with an established IT team and real budget. Their dealbreakers: native B2B with company accounts and tiered pricing, a catalog model that handles configurable products at scale, and multiple regional storefronts. We weighted catalog complexity, B2B features, and customization ceiling at the maximum, and time-to-launch and cost lower because the complexity justified a longer, larger investment. This is where Adobe Commerce earns its price: native B2B, a catalog model built for exactly this scale and complexity, multi-store from one backend, and the depth to model their pricing rules without fighting the platform. BigCommerce's B2B Edition was a real contender and we scored it seriously as a lighter-weight SaaS alternative, but the sheer catalog complexity and the configurable-product requirements tipped it to Adobe Commerce, which they had the team and budget to run. For a smaller B2B operation, that call could easily have gone to BigCommerce.

Profile three: a content-led specialty brand, a few hundred products, whose entire growth engine is organic search and deep editorial, guides, reviews, and long-form content tightly woven with the products, run by a team that already lives in WordPress and has a competent developer. Their dealbreakers: maximum SEO and content control, and full ownership of the integrated content-and-commerce experience. We weighted SEO control, content management, and customization heavily, and hands-off maintenance lower because they had the developer to carry it. WooCommerce won cleanly. Nothing matches WordPress for content-led commerce, the store and the editorial live in one install with total control of URLs, structure, and page speed, and the developer requirement that would have disqualified WooCommerce for profile one was already met here. Put this same brand in front of a non-technical team and the answer flips to Shopify, which is the whole point: the platform follows the constraints, not the product category.

Notice what happened across all three. No single platform won twice, and none was chosen for its reputation. Each business's real constraints, weighted honestly, pointed at a different platform, and in each case a different platform would have been a costly mistake. That is the entire lesson of this guide. There is no best eCommerce platform. There is the platform that fits your catalog, your team, your budget, and your roadmap, and the scorecard is how you find it. Run the method on your own business and the answer will surface the same way, from your constraints rather than from anyone's sales deck. For the record, the results I care about, roughly plus 45 percent organic traffic and plus 25 percent conversion on the engagements where I have led this work, came after the platform fit the business, not from the platform itself. The platform sets the ceiling; the work under it is what moves the numbers.

What is next: composable, headless, and the platform that disappears

The direction of travel in commerce platforms is clear even where the timing is not, and it changes how you should think about the decision you are making today. The industry is moving toward composability, toward AI-native operations, and toward a world where the platform matters less than the data underneath it. None of that means you should chase the trend into a build you do not need, but it should shape how you weight one criterion in particular: how cleanly you can evolve without a full re-platform.

Composable and headless keep maturing, and the important shift is that they are becoming available without the full custom cost. The old choice was binary: a packaged platform with a templated storefront, or a hugely expensive ground-up composable build. That binary is dissolving. SaaS platforms now expose strong APIs, Shopify's Storefront API and Hydrogen, BigCommerce's open architecture, so you can keep the operational simplicity of SaaS on the backend and decouple just the storefront where differentiation pays off. The smart architecture for most ambitious brands is not fully composable and not fully templated, it is headless-on-SaaS, taking the parts of custom that matter while keeping the platform to carry checkout, PCI, and operations. When you choose a platform today, weight its API quality and headless-readiness, because that is your option to evolve without re-platforming later.

AI is reshaping the operational layer faster than the storefront, and the platforms are racing to embed it. Merchandising, catalog enrichment, customer service, demand forecasting, and content generation are all getting AI assistance baked into the admin, and the platforms with the data and the ecosystem to deliver that well will pull ahead on productivity even if their storefronts look the same. Separately, and more structurally, AI shopping assistants are becoming a discovery channel of their own, reading structured product data to recommend and increasingly to transact on a shopper's behalf. That raises the premium on clean, machine-readable catalog data, complete structured data, accurate feeds, real reviews, regardless of which platform holds it. The platform that makes your data cleanest and most exportable is the platform best positioned for a world where machines, not just humans, read your catalog.

The deeper shift, the one I would build toward, is that the platform is becoming less important than the structured truth it holds. Your catalog, your pricing, your inventory, your customer and order history: that data is the real asset, and platforms come and go around it. The businesses that will adapt fastest to whatever comes next, new storefronts, new channels, new AI surfaces, are the ones that treat their commerce data as a portable, well-structured asset rather than something locked inside one vendor's proprietary format. That is why data ownership and exportability, which read like boring criteria today, are the ones I expect to matter most over a five-year horizon. The platform you can leave cleanly is the platform that cannot trap you when the ground shifts.

So my closing advice is the same one I opened with, sharpened by where things are heading. Do not choose the platform with the best marketing or the most impressive architecture. Choose the one that fits your business today and can evolve without a re-platform tomorrow, weight API quality and data portability alongside the immediate criteria, and keep your commerce data clean and yours. The platform decision is not a bet on which vendor wins. It is a bet on your own clarity about what your business actually needs, and if you run the method in this guide honestly, that is a bet you win regardless of which logo ends up on the admin login.