Something you need doing cannot be done. A customer needs a price nobody else gets, a bundle needs to take stock from three products, the checkout needs one extra field, and every answer you find online is an app you have to pay for monthly. Meanwhile the subscription list has quietly grown to eight, and somebody in a forum has told you that you have outgrown the platform and should move.
Maybe. Three completely different problems get called outgrowing Shopify, and only one of them is worth a migration. A genuine platform limit, where the thing you need is simply not possible. A missing feature, where an app or a small piece of custom work handles it for a fraction of a rebuild. And a setup problem, where the platform can do it and your store was configured by someone in a hurry. Telling those apart is most of this article, and it usually saves people a great deal of money.
Limit, app or setup? The test
Take the specific thing you cannot do and ask three questions in order. The first one it fails is your answer.
- Can any store on any plan do this, if they pay for it? If a competitor on the same platform demonstrably does it, you have a setup or a plan-tier problem, not a limit. Often the feature exists on a higher tier, and the step up costs a fraction of a rebuild.
- Does an app do it, and would you accept how the app does it? Nearly everything has an app. The real question is whether the app's version of the job matches yours, because a workaround you have to explain to every member of staff forever is not a solution, it is a tax.
- Could a developer do it inside the platform? This is the step almost everyone skips. Modern hosted platforms allow far more custom logic than their reputation suggests: custom fields on products and customers, custom code at checkout on the right plan, a storefront built entirely by you. A few days of work often removes the thing you were about to migrate over.
If it survives all three, it is a real limit and worth taking seriously. In our experience most complaints do not get past question two.
The limits that are actually real
Categories rather than version numbers, because the specifics move every year and the shapes do not.
- Pricing that depends on who is logged in. Wholesale and trade pricing is the most common genuine wall. The platform's own B2B features are good, and on the lower tiers there is a cap on how many distinct price lists can be active at once, plus gaps around self-service trade registration and pricing driven by customer tags. Our guide to B2B wholesale ordering covers that decision in full.
- Products that are configured rather than chosen. Made-to-measure, build-your-own, anything where the customer specifies rather than selects. Variant and option limits are designed for a catalogue of finished goods, and configurable products fight them constantly.
- Stock that is not one item on one shelf. Bundles and kits that must decrement their components, batch and serial tracking, stock reserved across several locations, inventory shared with a physical shop. Apps exist for all of these and they are the apps most likely to disagree with each other.
- A checkout that is not a checkout. Deposits, part payment, quote-then-approve, purchase orders, approval chains inside the customer's organisation, or delivery slots booked against real capacity. The checkout is the most protected part of any hosted platform, deliberately, and what you may change there depends heavily on your plan.
- Another system that must be the master. If your ERP or warehouse owns price and stock and must never be overwritten, that is workable on any route and materially easier when you control both ends.
- The arithmetic at your volume. When the platform percentage plus the app subscriptions exceed what running your own would cost. This arrives later than agencies imply and sooner than platform advocates admit, and it is a calculation rather than an argument.
The app bill, added up honestly
This is the part that changes people's minds, and almost nobody has done it. Open your billing and list every app with its monthly cost and any percentage it takes per order. Then multiply by twelve.
| What it does | Typical monthly | Twelve months | Notes |
|---|---|---|---|
| Reviews | $20 to $50 | $240 to $600 | Cheap, and almost everyone has one. |
| Loyalty or rewards | $30 to $100 | $360 to $1,200 | Often tiered by order volume, so it grows with you. |
| Subscriptions | $40 to $100 plus a percentage per order | $480 to $1,200 plus fees | The percentage is the part that hurts at scale. |
| Bundles and kits | $25 to $80 | $300 to $960 | The one most likely to disagree with your stock app. |
| Advanced shipping rules | $20 to $60 | $240 to $720 | Frequently replaceable by platform settings nobody configured. |
| Back-in-stock and alerts | $20 to $50 | $240 to $600 | |
| Search and filters | $30 to $150 | $360 to $1,800 | Scales with catalogue size. |
| Wholesale or trade pricing | $40 to $150 | $480 to $1,800 | Often the app that started this whole question. |
Eight apps at the middle of these ranges is roughly $300 a month, or $3,600 a year, before the platform subscription and before payment processing. That is the number to hold in your head for the rest of this article.
Two things to check while you are in there. Some apps charge a percentage per order as well as a monthly fee, which is a structure that punishes exactly the growth you are working for. And some bill outside the platform's own billing, so uninstalling the app does not cancel the subscription. Audit against your card statement rather than the dashboard, and most stores find something they stopped using months ago.
The middle route almost nobody explains
Between configuring a theme and rebuilding everything there is a third option that fits more stores than either: keep the platform running commerce, payments, stock and orders, and replace only the shop your customer sees with something built by you.
You get design and speed freedom, custom product pages that behave the way your products need, and the ability to build the one screen the app store does not sell. You keep the parts that are genuinely hard and genuinely dangerous: payments, card security scope, order management, the admin your team already knows. Illustratively $15,000 to $60,000, against a full custom build at $60,000 and up, and it is what a good deal of our online store work actually is.
It is not a universal answer. It does nothing for a limit that lives in the commerce engine itself, such as pricing per logged-in customer or stock that must decrement across a kit. Where your problem is the front of the shop, though, it removes the reason to migrate entirely.
What a migration involves, and what it costs
| What happens | |
|---|---|
| Moves cleanly | Products, variants, images, customers, historical orders and your content. These are exports and imports: careful work rather than difficult work. |
| Needs real work | Every old address mapped to its new one. Store URLs follow a predictable structure, so this is very doable and absolutely must be done. Skipping it is how businesses lose the search traffic that was paying for the store. |
| Does not move | Anything that lived inside an app: reviews, loyalty balances and points, and above all recurring subscriptions, where customers frequently have to re-authorise payment on the new system. If you sell subscriptions, ask about this before you commit to anything. |
| Gets rebuilt | The theme and every piece of custom work in it. Design does not transfer between platforms, and neither do most app-driven page sections. |
| Illustrative cost | $25,000 to $90,000 for a like-for-like move with the data work, more where the front end is being redesigned at the same time. Usually less than the original build, because the decisions and the content already exist. |
Budget for the fortnight after launch as well as the build. Migrations rarely fail on the day; they fail in the following month, on the edge cases nobody tested.
For a sense of what the equivalent spend buys on a fresh build rather than a move, what an online store costs sets out the same tiers from scratch, and our e-commerce work is where both conversations start.
Most stores have not outgrown Shopify
Three situations where we tell people to stay, and mean it.
- The problem is one feature. One genuine gap solved by one app, or by a few days of custom work inside the platform, is not a reason to rebuild a working store. The migration costs more than a decade of that app.
- The app bill is annoying rather than decisive. Three hundred dollars a month feels like a lot until you compare it with the hosting, maintenance and development that owning your own commerce engine requires. Running your own is not free; it is differently expensive.
- Nobody on your side wants to own software. A hosted platform is somebody else's responsibility for uptime, card security, fraud and the day something breaks at midnight on the busiest weekend of the year. That is worth real money, and businesses that move without appreciating it are unhappy within a year.
Not for you if
The decision checklist
- Write down the exact thing you cannot do, in one sentence, without using the word limitation.
- Run it through the three questions: can any store do this, does an app do it acceptably, could a developer do it inside the platform?
- Add up twelve months of apps, including any per-order percentages.
- Ask whether your problem is the front of the shop or the commerce engine behind it. The first has a middle route; the second does not.
- Check whether the feature exists on a higher plan tier, and what that step costs against a rebuild.
- If you sell subscriptions, find out what happens to them in a migration before you go any further.
- Price the migration and the middle route side by side, over three years rather than at signature.
You are not really deciding between platforms. You are deciding whether the thing blocking you lives in the shop window or in the machinery behind it, and how much of that machinery you want to be responsible for. Most stores should keep the machinery and change the window. The ones that genuinely need their own engine usually know exactly which rule they are fighting, and can say it in a sentence.