Accurate as of 4 August 2026. Platform capabilities in this space are changing quickly — see the note at the end of this article.

There is a particular moment that tells you something has shifted. Someone new joins the team, looks at how orders flow through your store, and asks why it works the way it does. And the honest answer is: because that’s how the app does it.

Nobody decided it. Nobody owns it. It accumulated.

Outgrowing an ecommerce platform is a success symptom, not a failure. The businesses that never outgrow Shopify are usually the ones that didn’t change much. If your product range, your customer mix, or your fulfilment model looks different today than it did three years ago, it would be strange if the platform you chose back then still fitted perfectly.

What follows is seven specific signals, drawn from replatforming conversations we have had with Australian merchants. Each one gets the same treatment: what it feels like day to day, why the platform behaves that way, how to fix it where you are, and the specific condition that means the workarounds have stopped paying for themselves. At the end there is a scorecard.

One thing to say up front: most people who read this article should stay on Shopify. It is a genuinely excellent platform, it has closed a lot of gaps in the last eighteen months, and replatforming is expensive, disruptive and occasionally regrettable. This is not an argument that you should leave. It is a framework for working out whether you have.

Sign 1: Your pricing is calculated, not listed

What it feels like. A sales rep negotiates a deal over email or the phone. Someone then keys it into the platform by hand, or builds a draft order, or maintains a price list in a spreadsheet that nobody fully trusts. Every large customer is a small exception.

Why it happens. This area changed recently, and it is worth being precise about what moved and what did not — because the summaries circulating are misleading in both directions. Since April 2026, much of Shopify’s native B2B is no longer restricted to Plus: company profiles, volume price breaks, quantity rules, net payment terms and vaulted cards are available on Basic, Grow and Advanced at no extra cost, along with up to three active B2B catalogs.

But the catalog mechanics decide whether any of that solves your problem. On Basic, Grow and Advanced, catalogs are assigned through Markets — not to companies. Genuinely customer-specific catalogs, meaning a catalog assigned directly to a company or company location, remain Plus-only, along with unlimited catalogs, deposits and partial payments. Below Plus your pricing granularity is market-shaped rather than customer-shaped. If you have read that customer-specific pricing arrived on the cheaper plans, that is not quite what happened.

What Shopify does not have natively on any plan is a quote-to-order workflow. There is no request-a-quote, no multi-round negotiation with revision history, no buyer-side approval chain. Draft orders (which can now lock item prices) are the supported pattern, and for many businesses they are enough.

Fixing it where you are. Move informal pricing into company catalogs and volume breaks. Use draft orders with locked pricing for rep-assisted deals. If the gap is approvals rather than pricing, an app may cover it.

The trigger. Your pricing is computed rather than listed — it depends on customer, quantity, product attributes and date simultaneously, and cannot be pre-enumerated into a price list. Or negotiation itself is the sales process, with quotes going back and forth before an order exists. That is where Adobe Commerce’s native B2B (requisition lists, company credit, purchase approval rules) starts to look like a feature set rather than a luxury.

Sign 2: Your products don’t fit the product model

What it feels like. You are creating products that don’t exist to represent products that do. You maintain a configurator outside the platform. You sell by the metre but the cart insists on whole numbers.

Why it happens. Another place to update your assumptions: Shopify’s old 100-variant ceiling is gone, replaced by 2,048 variants per product. But the limit that actually constrains people survived — three options per product, on every plan. Combined Listings (Plus and enterprise) partly works around this by joining up to 60 separate products into one storefront listing, each with its own URL and content, which effectively buys you more dimensions and better SEO per variant group.

Where Shopify remains genuinely thin:

• Bundles — there is a first-party Bundles app, but it does fixed bundles and multipacks only, capped at 30 components, and bundles cannot carry selling plans. No subscription bundles, no pre-order bundles, no mix-and-match.
• Configurable, made-to-order products — no native model for dependent options with a derived price. Quantities are integers, and there is no true unit-of-measure concept, so “cut to length, priced per metre” is not something the platform holds.
• Price that varies by configuration — only by pre-enumerating every combination as a variant, or intervening at the cart with Functions.

This is the area where Magento’s much-criticised complexity earns its keep. Configurable, bundle and grouped product types exist precisely because catalogues are not always a grid of three options. We wrote about how those product types compare across platforms if you want the detail.

Attributes and metafields are not the same thing

There is a second half to this that merchants tend to discover late, usually halfway through a project. Magento has attributes. Shopify has metafields. They look equivalent on a feature comparison table and they behave very differently.

In Magento, a product attribute is a first-class part of the catalogue model. Create “Fabric composition” or “Voltage” once and it can be made filterable in layered navigation, searchable with its own relevance weighting, used as the axis of a configurable product, referenced in catalogue price rules, scoped per store view, and grouped into attribute sets so that different product types carry different fields. One definition, and the rest of the platform already knows what to do with it.

Shopify’s equivalent is the metafield, with metaobjects for structured, reusable records. These are genuinely capable — typed, centrally defined, editable in admin, renderable in themes — and for storing and displaying additional product information they are perfectly adequate. But a metafield is data about a product rather than a dimension of it. It cannot become a variant option, which means it offers no relief from the three-option limit above. Making one filterable is a separate exercise through Search & Discovery with its own constraints. And metafields do not feed pricing logic the way a Magento attribute can feed a catalogue price rule. The practical effect is that adding a merchandising dimension in Magento is one configuration change, while in Shopify it is a series of separate decisions in different parts of the admin, each with its own rules.

One recent change matters if you have leaned on metafields as a general-purpose data store. In February 2026 Shopify announced that from API version 2026-04, writes to JSON metafields are capped at 128KB — down from 2MB. Limits on other metafield types are unchanged, and apps that were using JSON fields before 1 April 2026 are grandfathered at the old limit. Existing oversized values remain readable, but you cannot write above the new cap, so anything currently over it is effectively frozen until it is restructured. Stores that used JSON metafields to hold bulk specification data, imported PIM payloads or large configuration blobs have real remediation work in front of them.

To be fair to Shopify, the reasoning is sound: very large values loaded together were pulling tens of megabytes into a single page render and hurting storefront performance. It is a reasonable decision. It is also a clean illustration of the trade you accept on a hosted platform — the storage rules are not yours, and they can move underneath you on the vendor’s schedule rather than your own.

Fixing it where you are. Combined Listings if you are on Plus and the problem is dimensionality. A configurator app if the problem is made-to-order. Reconsider whether every attribute genuinely needs to be an option.

The trigger. You are creating fake SKUs to fool the product model, or the source of truth for what a customer can actually order lives outside the platform.

Sign 3: Checkout has become the constraint

What it feels like. The answer to a reasonable commercial request is “not at checkout.”

Why it happens. Shopify’s checkout is the best argument for staying. It converts, it is maintained for you, and merchants who rebuild it usually end up with something worse. It is also a walled garden with a clearly defined edge.

That edge moved recently, and if you are on Shopify this paragraph is the most time-sensitive thing in this article. Shopify Scripts stopped executing on 30 June 2026 — not deprecated, retired. Functions is the replacement. And script tags on the Thank you and Order status pages stop working for non-Plus stores on 26 August 2026, three weeks from the date of this post. Plus stores passed that milestone in August 2025. If anything you rely on post-purchase still depends on that mechanism — tracking, surveys, referral widgets, subscription upsells — it breaks this month.

Correcting two claims that circulate widely: Shopify can split shipments natively, for all merchants, with customers choosing per shipment. And Shopify can do real-time dimensional-weight and freight rates through the Carrier Service API — though it is included only on Advanced and Plus, with Grow stores able to add it for an extra monthly fee or by switching to annual billing. Neither is a reason to leave.

What you still cannot do, on any plan: change checkout’s structure or routing, add arbitrary steps, inject arbitrary JavaScript, or run a negotiation inside the transaction. Checkout UI extensions live at defined extension points with Shopify-controlled styling.

Fixing it where you are. Migrate off Scripts and script tags now if you have not — this is urgent regardless of any replatforming question. Then establish honestly whether what remains is a genuine requirement or a habit.

The trigger. The transaction itself needs to be something other than “select, pay, done” — quote-to-order, credit assessment mid-flow, complex freight logic that has to sit inside the order rather than beside it.

Sign 4: The app stack has quietly become the platform

What it feels like. Twenty-five or more apps. A four-figure monthly subscription line that nobody has audited in a year. Two apps that conflict in ways only one contractor understands. A bug that takes three vendors to diagnose. Above all: nobody can describe end to end how the site works.

Why it happens. Every individual app decision was correct. The compounding was never decided at all. Each app adds JavaScript, and the aggregate lands on your Core Web Vitals and on mobile conversion.

There is a second-order cost worth naming, because it shapes your options later: app-held data is not really yours. Reviews, loyalty balances, wishlists, subscription contracts and page-builder content live with the app vendor, and the quality of export ranges from good to nonexistent. This is consistently the largest hidden cost in a migration, and it scales with app count. It is also a reason to reduce app sprawl even if you never leave.

Fixing it where you are. Audit the stack against actual usage. The checkout extensibility migration is a useful forcing function — it surfaces exactly which apps are still maintained.

The trigger. You avoid changes because you cannot predict what will break, or your monthly app spend is approaching what a platform with these capabilities built in would cost to run.

Sign 5: Fulfilment reality is more complex than the inventory model

What it feels like. Someone decides each morning which warehouse ships what. You oversell in ways that are not a stock-counting error.

Why it happens. Location count is rarely the issue — Basic, Grow and Advanced allow 10 locations and Plus allows 200. Shopify supports fulfilment priority, automatic splitting across locations, third-party fulfilment services alongside owned stock, and native pre-orders through purchase options (Shopify Payments or PayPal Express only).

The difference is in routing sophistication. Shopify’s priority is a single global ordered list plus proximity and cost heuristics. Magento’s Multi Source Inventory models sources, groups them into stocks, assigns stocks to websites, and lets you select or write the allocation algorithm — with reservations as a first-class concept, so saleable quantity is source quantity minus what is already committed. If you have ever tried to reconcile concurrent orders against shared stock, you know why that matters. We explained how MSI actually works in an earlier post.

Fixing it where you are. Tune fulfilment priority properly; most stores never revisit the default. Use a fulfilment service integration rather than manual routing.

The trigger. Your routing rules are conditional — “prefer own stock below a threshold, otherwise dropship, except in this region” — and cannot be expressed as one ordered list. Or overselling is costing you real money at concurrency.

Sign 6: Integrations keep hitting the same ceiling

What it feels like. Every system you connect needs a piece of middleware. Sync lag shows up as customer-facing errors. Someone has written a reconciliation script to catch what the webhooks missed.

Why it happens. Let us be fair here, because this is where agency articles overreach. You will build or buy an integration layer on any platform. A bare Magento install has no ERP field mapping either. “You need middleware” is a project cost, not a Shopify defect.

Two things are genuinely different. First, API rate limits are hard ceilings you cannot buy your way past with infrastructure — only with plan tier. Shopify’s GraphQL Admin API allows 100 points per second on standard plans, 200 on Advanced, 1,000 on Plus. On a platform you host, throughput is an infrastructure decision. Second, webhooks are documented as at-least-once with no ordering guarantee, so consumers must be idempotent and must reconcile. Missed, duplicated and out-of-order events are expected behaviour rather than faults.

Also worth knowing if your integrations are more than a year old: the REST Admin API has been legacy since October 2024, and new public apps have been GraphQL-only since April 2025.

Fixing it where you are. Make consumers idempotent, add a reconciliation sweep, batch through bulk operations rather than per-record calls. Most rate-limit pain is inefficient integration code rather than a genuine ceiling.

The trigger. You are at the rate ceiling with efficient code, or integration latency is causing order problems your customers can see.

Sign 7: You want policy over your agent surface, not toggles

What it feels like. AI assistants are starting to send you traffic and orders, and you are not entirely sure what they can see, what they were told, or what you agreed to.

Why it happens. This is the sign where we have had to revise our own position, so we will be direct about it. The argument that “on a closed platform you simply inherit whatever AI integration the vendor ships” was reasonable a year ago. It is not accurate now.

Shopify has shipped a great deal here: the Universal Commerce Protocol with Google, per-store Storefront MCP servers, Shopify Catalog as a syndication layer into ChatGPT, Gemini, Copilot and Meta, and an Agentic Storefronts admin surface with per-channel toggles, an opt-out from automatic enrolment in future channels, a global catalog kill switch, and product-level Unlisted status. BigCommerce shipped agentic catalog exports, a storefront MCP and an agentic checkout kit at Commerce Live in April. Adobe announced a Commerce MCP Server at Summit — though for Adobe Commerce, not Magento Open Source.

Magento Open Source ships none of this in core. But “not in core” and “does not exist” are different statements, and the difference is where this platform’s character shows: the community filled the gap rather than waiting for Adobe to. There is now a working ecosystem of MCP extensions for Magento and Adobe Commerce, a good part of it open source. Bold Commerce published an early server. Freento’s module is open source and listed on the Adobe Commerce Marketplace. Angeo ships an MIT-licensed agentic suite including MCP checkout. Vendors such as Mirasvit and MageDelight offer commercial equivalents.

We maintain one of these ourselves, so read this as a disclosed interest rather than a neutral recommendation. Magenable’s open-source Magento and Adobe Commerce MCP server is an original implementation, built from the ground up rather than forked. It runs as a Node.js service you host yourself, connects to your store’s REST API, and exposes more than eighty tools spanning products (including configurable and bundle types), categories, attributes, customers, addresses, orders, invoices, stock, tax and CMS content. It covers both read and write operations, is multi-store aware, supports SearchCriteria for precise querying, keeps response payloads compact so an agent is not spending its context window on boilerplate, and runs over either a local connection or secure remote HTTPS — which is what allows a store to connect to Claude, OpenAI’s Agent Builder, or any other MCP client. We wrote a practical guide to MCP for Magento and Adobe Commerce if you want the background.

So the honest comparison is not “shipped versus nothing”. It is a trade between distribution and control, and which one you need depends on your business rather than on which platform you admire.

Shopify gives you distribution. Shopify Catalog syndicates you into ChatGPT, Gemini, Copilot and Meta from an admin toggle, and replicating that reach independently is genuinely hard. What it does not give you is policy. The controls are channel and product switches; the default posture is on with an opt-out rather than off with an opt-in; you cannot express “expose these attributes but not those”, “show trade pricing to this agent only”, or “serve agents a different assortment”; and you do not control the MCP tool surface, its schema or its response shape. Commercially, the platform also sits between you and the agent.

Running your own MCP server inverts both halves. You define exactly which tools exist, make any of them read-only, keep sensitive operations such as refunds behind manual approval, log every call, and layer Magento’s own permission model underneath. That is policy rather than toggles, and it is the substantive argument for an open platform in the agentic era. The cost is that distribution becomes your problem: you onboard to each AI channel yourself, you operate and secure the server, and you carry the upgrade burden. Extension maturity also varies — this ecosystem is barely a year old, so evaluate any module on the assumption that it is still moving fast.

Worth knowing either way: Shopify runs a free Agentic plan that lets merchants on other platforms syndicate a catalogue into AI surfaces through it. Some Magento merchants will sensibly use that for reach while running their own MCP server for control. The two are not mutually exclusive.

The trigger. Agent-mediated selling is becoming material to your category and the way your products are represented is a competitive question rather than a plumbing question — differentiated attributes, contract pricing, regulated claims, channel-specific assortment. If AI is currently a small and undifferentiated slice of your revenue, a toggle is fine and this is not your reason to move.

Score yourself

Score each sign: 0 if it is not you, 1 if it is annoying, 2 if it is costing you money or customers.

Total	What it means
0–4	Stay. Your returns are in merchandising, acquisition and conversion, not in platform.
5–9	Fix your two highest-scoring signs where you are. Reassess in twelve months.
10+	The workarounds have become the system. Start scoping properly.

One weighting rule, because a raw total flatters the wrong problems: a single 2 in your core revenue path outranks a spread of 1s. A business losing orders at checkout has a more urgent problem than one mildly irritated by seven things.

If you do move, where to

Stay on Shopify. Listed first because it is the right answer most often. High volume, moderate complexity, marketing-led growth, a catalogue that fits the model — Shopify will beat what you would build, and the gaps that mattered in 2024 have narrowed considerably.

BigCommerce (now Commerce). Genuinely more open than Shopify on APIs, headless-first through Catalyst, more permissive on multi-storefront. But be aware of two 2026 changes before you assume the old pitch still holds. From 1 June 2026 there is an Open Payment Provider Fee of 2% / 1% / 0.6% depending on tier for gateways outside the approved list — structurally the same as Shopify’s third-party gateway fee, which retires “bring your own payments with no penalty” as a differentiator. Plan GMV thresholds were also lowered, so the same revenue now sits a tier higher. The company rebranded to Commerce and reportedly declined a takeover approach in 2025. None of that disqualifies it; all of it belongs in your evaluation.

Magento Open Source. The strongest fit for complex catalogues, computed pricing and sophisticated inventory, and the only option here that gives you unmediated control of your own data and agent surface — with a community MCP ecosystem that has moved considerably faster than Adobe has. Version 2.4.9 shipped in May 2026 with support through to 2029, on a defined annual release cadence, no announced end of life and no licence change. Two honest caveats. First, the upgrade treadmill is a recurring line item, not a one-off — extended support for 2.4.5 and regular support for 2.4.6 both end on 11 August 2026, a week from now. Second, and more strategically: Adobe’s new investment is flowing toward Adobe Commerce as a Cloud Service, and the Summit 2026 agentic announcements targeted the paid product. Choosing Magento Open Source in 2026 means choosing a mature, controllable, well-understood platform on a maintenance trajectory, with the community Mage-OS distribution as a continuity path. That is a legitimate choice. It is not the same as choosing a platform on its vendor’s growth roadmap, and you should make it with your eyes open.

Adobe Commerce. The above plus native B2B depth — requisition lists, company credit, purchase approval rules — enterprise support, and the agentic tooling announced this year. The cost structure is a different conversation entirely.

When you should not migrate

Four disqualifiers. Any one of them means the answer is “not yet”, regardless of your score.

Nobody internally owns it. A replatforming project without a decision-maker who can spend half their week on it for several months will produce a worse version of what you already have, at considerable cost.

The real problem is merchandising or marketing. Platform changes do not fix flat conversion, weak product content, or an acquisition mix that has stopped working. They just make those problems more expensive to have. Genuinely test this one — it is the most common misdiagnosis we see.

There is a peak trading period inside the timeline. Do not cut over into your busiest quarter. Ever.

It traces to one app rather than the architecture. If removing a single vendor would resolve most of your score, that is a much cheaper project.

What to do with this

If you scored under 5, close the tab and go and improve something that will actually move revenue this quarter. If you scored 10 or more, the useful next step is not a platform demo — it is writing down which of the seven signs are costing you money, and roughly how much, because that is the document that makes the decision for you.

If you want a second opinion on your scorecard, we offer a 30-minute platform fit call. We work across Shopify, Magento, Adobe Commerce and BigCommerce, so we have no particular stake in which way you go — and we will tell you to stay on Shopify when that is the right answer, which, as this article has hopefully made clear, it frequently is.

A follow-up article will work through the five-year cost model in detail: platform fees, payment margins, the app stack, agency retainer, hosting and upgrades, across three revenue scenarios.

---

A note on accuracy, and our bias

This article is a point-in-time snapshot, published 4 August 2026. The pace of change in this area is genuinely unusual, and several claims that were standard in articles like this one as recently as last year are now simply wrong — a 100-variant ceiling, split shipments requiring an app, Shopify Scripts being the way to customise checkout, Shopify Payments being unavailable in Australia. We have tried to verify every capability claim here against primary documentation rather than repeating received wisdom, and we have corrected our own prior position on the AI and agent question in the process.

Note also that “available on your plan” and “available in the shape you need” are different questions, and the gap between them is where most of the confusion in this topic lives. Shopify B2B is the clearest example: a great deal of it did move to the cheaper plans this year, but the catalog scoping that most wholesale businesses actually need did not. We have tried to draw those lines precisely rather than reaching for the headline. Expect some of this to age too.

Specific limitations you should know about. Capabilities and limits frequently vary by plan tier, by region and by contract, so verify anything decision-critical against your own account rather than against this article. We have deliberately not printed Shopify Plus pricing figures or GMV-based fee percentages: those terms are not published, are individually negotiated, and every number in circulation is second-hand. We have likewise left out the widely quoted agentic-commerce adoption statistics, because we could not trace them to a primary source. Version and end-of-life dates for Magento are drawn from Adobe’s release documentation and community trackers and should be confirmed before you plan an upgrade around them.

Our bias. Magenable is an ecommerce consultancy, and we work across Shopify, Magento, Adobe Commerce and BigCommerce. That means we do not carry the conflict this genre usually does. We are not structurally better off if you leave Shopify, and if the answer is to stay and build there, that is work we are glad to do.

There is a subtler bias, though, and it is worth naming because it is the real one. The bulk of our history is Magento and Adobe Commerce, and we maintain an open-source MCP server for those platforms, referenced earlier in this article. Anyone who has spent years inside a particular catalogue model tends to notice its strengths before its costs, and to reach for its vocabulary when describing someone else’s. Expertise and preference are difficult to separate, and we would not claim to have separated them perfectly here. Read this article — and every “have you outgrown your platform” article, including the ones that reach the opposite conclusion — with that in mind. It is why we have tried to be specific about the conditions under which staying put is correct, rather than leaving that as a token disclaimer. Judge the framework on whether it helps you think, not on whether it agrees with us.

Corrections welcome. If something here is wrong, out of date, or unfair to a platform, tell us and we will amend the article and note the change. That is a better outcome for everyone than a confident piece of content quietly misleading people for the next two years.