

We recently helped a client think through whether they should move to Shopify. We get asked this question so often that we've developed a framework of twelve areas we work through with every client facing the same decision.
Caveat: We are not anti-Shopify. Shopify is a well-designed platform, and for a very large set of merchants it is the right choice. But Shopify has a specific shape and a clear point of view about how commerce businesses are structured. When your business matches that shape, Shopify is an excellent fit. When it doesn't, the work is in identifying where the misalignments are and what they will cost you.
The real question in any platform decision isn't whether Shopify is good (it plainly is) it's whether your business fits the mould Shopify is built around.
Most TCO comparisons we see include the Shopify platform fee and the Shopify Payments transaction rate. That is part of the real number, just not all of it. The full picture also includes app subscriptions, theme licences, theme customisation dev hours, transaction fees, the Plus platform fee, and an agency retainer for ongoing design changes. None of this is a Shopify problem, every platform comes with an ecosystem cost, but the ecosystem cost is where merchant budgets most consistently fall short, and it’s worth knowing these numbers upfront.
One data point from a recent assessment: the client's projected ancillary app stack came to $1,893 per month. This consisted of all the apps they thought they would need to meet their desired functionality. We recommend every client do the same exercise before finalising a business case.
Shopify Payments is a first-class citizen on the platform. It is tightly integrated, unlocks Shop Pay, and works well for the card-first merchants who make up most of Shopify's base. But whether Shopify Payments is the right path for your business is a three-layer question, and the layers need to be worked through in order.
The first layer is availability. Shopify Payments is only available in a subset of markets, broadly the US, UK, Canada, Australia, and Europe around 23 markets in total. In markets outside that footprint, Shopify Payments is not an option and a third-party processor is required by default, with the associated transaction fee applying regardless of preference.
The second layer is payment method coverage. Even where Shopify Payments is available, it does not natively cover every payment method your customers may expect to use. Alipay and WeChat Pay in China are examples where native coverage is limited or absent and third-party apps or gateway integrations must carry the load. In most non-English-speaking markets, local payment method preference is a conversion requirement. The payments assessment needs to start with "what methods do our customers expect to use" before it gets to rate comparison.
The third layer is rate economics. If Shopify Payments is available in your markets and covers your required payment methods, the question becomes whether the rate is competitive against your current acquirer relationship. Using an alternative processor is supported but carries a transaction fee on top of your processor fees, currently ranging from 0.15% on Plus to 2% on Basic. If you have negotiated rates worth preserving, the economics of staying on your existing provider need to be modelled deliberately. The transaction fee compounds at scale in ways that are not obvious from the rate card alone.
For many merchants, working through these three layers in order will make the decision straightforward. For merchants with international ambitions, complex payment mixes, or existing acquirer relationships, it is where some of the most consequential numbers in the business case live.
Most businesses approach the international question the wrong way. They ask “can Shopify do international?”, get a yes, and stop there. The right question is more granular: which version of international are you actually trying to do, and does Shopify Markets handle that version natively?
Cross-border shipping from a single base. You’re shipping to multiple markets, want to show local currency, translate the storefront, and handle basic checkout, but inventory, operations, and fulfillment all run from one place. Shopify Markets was built for this and handles it well.
Localised selling without local presence. You want genuine local pricing, local payment methods, and market-relevant product ranges, but no local entity or warehouse. This is where Shopify starts to show its limitations. The typical solution is pairing Shopify with a cross-border partner like Global-e, ESW, or Zonos. These are capable platforms but come with their own complexities and downsides. They are also an additional contract, integration, and revenue share on international GMV (rates vary by contract and volume but figures in the range of 3-8% are common). This means international cost scales with success rather than staying flat and it needs to be modelled that way by finance teams.
True local market operation. Local entities, local inventory, local teams, market-specific product lines, non-negotiable local payment rates. Shopify Markets can help here but the complexity of running such a multi-entity business, and the complexities involved, can mean the out of the box Shopify/ShopifyPlus isn’t enough and serious consideration needs to be given to the structure of your online presence. Is it one shopify store, or is it now many independent stores?
Before deciding, ask yourself:
Note: the complexity of cross-border solutions like Global-e (multi-store setup, contractual structure, integration depth etc.) warrants its own assessment. We will try to cover this in more detail in the future.
This is where fit matters most, and where we saw it most clearly during the assessment. We looked closely at how the prebuilt integration between the client's ERP and Shopify would actually work. It didn't cover all the scenarios of their operational setup. Simply put, the client's order flow included complexity that the standard connector wasn't built to handle. That's a common pattern.
Prebuilt connectors are designed around the most common integration shapes, and they handle those shapes well. The assessment question isn't "is there a connector?", there almost always is. It's "does the connector handle the 10% of your order flow that isn't standard?" That 10% is where data quality issues quietly accumulate and show up in finance two quarters later.
For this client the gap meant the connector would need custom development to handle their edge cases reliably. That work can be scoped and costed and most probably is manageable but it is not the standard implementation quote, and finding it after contract signature is a different conversation from finding it during the assessment.
Shopify's native returns functionality covers the common cases: return requests, refund issuance, basic restocking. For most categories that's sufficient. For apparel, footwear, furniture, and other categories where returns and exchanges are a core part of the customer experience, the native functionality is just a starting.
Most mid-market merchants in these categories end up on Loop, ReturnGo, et al, that add exchange-over-refund logic, carrier integrations, and warehouse scan-in flows for a monthly cost ($155+ Per Month).
The exchange-over-refund capability is worth calling out specifically as it nudges customers toward an exchange rather than a cash refund and directly protects revenue in high-return categories. These platforms are typically priced on return volumes, meaning cost scales with the part of your business you most want to keep under control. It is worth modelling this before you commit.
Returns tooling is deep enough in categories where it matters that Shopify reasonably leaves it to partners where they fall short, but it does mean that if returns are strategic for you, the returns platform choice is a platform decision in its own right, with its own cost, its own integration, and its own contract, and it's better understood before launch than after.
Shopify is a commerce engine, and a very good one. It has product records, variants, metafields, and, via metaobjects, a flexible content model that covers a wider range of product data needs than it used to. Shopify is not a Product Information Management system. This is true of most ecommerce platforms. That's a separate category of product. For merchants whose product data currently lives in spreadsheets, Shopify's native capabilities are an upgrade and likely sufficient. For merchants running a proper PIM, , Shopify becomes one of several publishing targets, and the architecture question is about sync reliability, attribute mapping, and who owns the data model. Shopify is a commerce platform rather than a catalogue management platform and the question for the assessment is whether your catalogue complexity puts you on the side of the line where Shopify alone is enough, or the side where you need Shopify and a PIM working together.
One of Shopify's real strengths is how much it lets a merchant do without developers. For small merchants that promise holds in full. For mid-market merchants it holds partially, the platform does reduce some of what you need to build, but it doesn't remove it entirely, instead the skills needed shift rather than disappear.
In the client assessment, one of the clearest findings was that there was no internal capability to support customisation. Every customisation decision was also an external-support decision, with the cost and timeline implications that carries.
The skill profile for a serious Shopify operation typically includes developers, app configuration specialists, Shopify Functions developers for any checkout-layer logic (Shopify Functions is the mechanism for custom checkout and discount behaviour on Plus), and if you go headless, a frontend team. Most mid-market merchants don't have this in-house, which means a retained agency relationship becomes a de facto line item. Once your business grows past the out-of-the-box stage, these skill sets become a requirement rather than a nice-to-have and need to be budgeted for.
Before you assess whether Shopify fits your catalogue, you need to understand the shape of your catalogue. Two areas in particular, how your products are structured, and how your supplier model works, have a direct bearing on fit. Merchants who cannot answer them clearly before the assessment tend to discover the gaps only after go-live.
Product structure. Shopify organises products into collections rather than hierarchical categories. Collections are flat and hierarchy doesn’t exist in the data model itself. For catalogues of a few hundred SKUs this is clean and manageable. For deeper catalogues, hierarchy is expressed through navigation structure and naming conventions rather than through the data model. This means every system that needs the hierarchy has to reconstruct it independently. So, the questions to answer before assessment become:
Supplier structure. Shopify’s native supplier model is a single vendor field per product. If your supplier model is one product and one vendor, this is fine. If your supplier model includes multiple suppliers for the same SKU, supplier-specific variants, or orders that route to different fulfillment sources depending on stock, the native model does not hold that complexity. It has to live in metafields, in the ERP, or in a parallel system that needs to stay in sync. Here, the questions to answer before assessment is simply how complex is your supplier model, and where does that complexity currently live? If the answer is “in our ERP and it’s significant”, the ERP integration assessment and the product structure assessment need to be done together.
Shopify’s data model has a clear shape, and the cost of misalignment is not always visible during a standard demo or a surface-level assessment. It shows up much later during integration work, through data quality issues, and in operational workarounds that accumulate quietly. Knowing your own structure clearly before you evaluate the platform is what makes the evaluation honest.
Data migration is frequently underestimated, both in scope,cost, and the decisions it forces.
Customer records and order history are the workstream merchants typically ask about first. They are achievable, and there are mature tools and approaches, but the mapping work between the source platform’s data model and Shopify’s is non-trivial. Historical order volumes for mature merchants are substantial, and “we’ll just bring the last two years” is a decision with real downstream implications affecting customer service, returns, loyalty programmes, and financial reporting.
Product data migration is often the more complex workstream. Attribute structures, variant logic, media assets, and associated content rarely map cleanly from one platform to another. Fixing the gap between “products migrated” and “products trading correctly” is where most migration efforts actually live.
URL structure deserves its own line item. Shopify enforces a fixed URL pattern , /products/, /collections/, /blogs/news/ , which means existing URLs almost always have to change. Redirect mapping is manageable but is real work and connects directly to SEO. Any legacy equity accrued in product or category URLs needs to be captured in 301 redirects before go-live, not after.
One dimension that sits outside the technical workstream and is consistently underprepared for: GDPR compliance. Migrating customer records is a personal data processing activity and needs to be treated as one. Although this is not specific to Shopify and applies to any replatforming project involving customer data, it is important to understand the lawful basis for migrating existing customer data to a new platform and processor set, whether your privacy policy accurately reflects the processing that will occur on Shopify and across its app ecosystem, and what the appropriate retention period is for historical order data. We recommend involving your DPO or legal counsel in the migration scoping conversation, not the post-launch review.
Data migration is rarely the reason a migration succeeds or fails, but it is frequently the reason a timeline slips or a budget overruns, so scope it properly, including product data, URL redirects, and data compliance, before finalising a migration plan.
Shopify's SEO defaults are solid with clean URLs, sitemap, structured data, and themes that perform well on Core Web Vitals. The constraints that exist are deliberate design choices. URL structure follows a fixed pattern (/collections/, /products/, /blogs/news/), canonical behaviour is opinionated, and multi-locale SEO via Shopify Markets has specific patterns around language handling. For most merchants these are fine but for merchants with specific URL or canonical requirements driven by legacy SEO equity or particular technical preferences the platform's defaults are the starting point for the evaluation.
SEM is less a platform question and more a feed and tracking question that sits on top of any platform. Shopify's native Google and Meta integrations cover common needs while sophisticated merchants typically extend this with feed management platforms and server-side tracking to close gaps in attribution at scale. This is expected but worth budgeting for.
AI optimisation is a genuinely new front. LLM-driven search , ChatGPT, Perplexity, Google AI Overviews, are all reading product data differently from traditional crawlers. Structured data, clear product descriptions, category-defining content, and review integration all carry more weight than they used to. Shopify's native product schema is a reasonable foundation for this and the optimisation work is largely content-side, meaning the platform enables it but doesn’t do it for you. Again, this is true of any ecommerce platform, but is worth naming as part of the 2026 reality rather than leaving as an afterthought.
Design customisation on Shopify is a three-tier question, and being clear about which tier you're working in changes the cost estimate by an order of magnitude.
Theme-level customisation - swapping templates, adjusting Dawn-derivative themes, visual-brand work within the theme editor. This is inexpensive and well supported and where Shopify's no-code promise is most real.
Component-level customisation - custom sections, bespoke product page layouts, non-standard navigation, product configurators. This is achievable in Liquid (Shopify’s template language), with an effort curve that's steeper than merchants often expect. As this becomes more complex, it starts to point towards Hydrogen, Shopify’s headless framework. Hydrogen unlocks significant frontend flexibility but also significantly increases implementation cost, ongoing complexity, and the sophistication required from your development team.
Checkout-level customisation is heavily constrained by design. Checkout is the part of the platform where Shopify's opinions are strongest, because it's the part where Shopify's scale and conversion data drive genuine advantage. Checkout Extensibility and Shopify Functions have expanded what's possible on Plus to a small extent but the overall shape of the checkout journey is Shopify's, and "checkout must follow the platform provided journey" is worth naming as a consideration at assessment time. Merchants with specific checkout ambitions need to know the constraints they're operating within from the outset.
Shopify is not a CMS. Don’t try to force it to be one. It will be painful and expensive. For merchants with straightforward content needs (blog, collection pages, basic curation) the native capability is sufficient. For merchants with more ambitious content-commerce integration such as editorial landing pages, personalised sort orders, campaign-driven merchandising then the answer is typically a stack: a search and merchandising platform, a CMS for editorial content, and a personalisation layer if needed. No single platform handles all of this well so it’s sensible to combine several that specialise in one specific part to achieve the full goal.
The common outcome of merchandising rules in one tool, content in another, search in a third etc is not inherently a problem, it only becomes one when no one has designed the architecture deliberately. The cost of integration and the cost of unclear data ownership are both real, and both are easier to design around before go-live than to untangle after.
The question is rarely just "should we move to Shopify?" It should be “which platform shape fits our business shape?” Every platform has a point of view. Shopify's is clear,consistent, optimized for time-to-market, polished merchant experience, with a world-class checkout, and an ecosystem where most extensions are solved by apps rather than by custom code. For the merchants who fit this shape, Shopify is hard to beat. For merchants whose business has a different shape (deeper catalogues, more complex sourcing, non-standard checkout requirements, heavy existing tech investments to name a few) the question isn't whether Shopify is a good platform, but whether the fit is close enough that the workarounds are worth it, or that the business is willing to work without the confines are what’s provided to avoid further cost.
We'd encourage a harder look when:
The merchants who succeed on Shopify are the ones who chose it with their eyes open. The ones who struggle are the ones who assumed the fit before testing it.