Migrate when the constraint lives in the platform’s architecture, not in how the store is configured and run. This post gives the signs of a real platform ceiling, the problems most often mistaken for one, a five-question self-check, and a worked example: FleaSolve’s move from WooCommerce to Shopify, with each of its recorded problems sorted into platform or setup.
Is it the platform, or the setup?
Every migration conversation starts with something about the store not working, and the platform is the easiest thing to blame. It is a single named cause, nobody on the current team is at fault, and “we’re moving to a better platform” sounds decisive. None of that makes it the right diagnosis.
A migration fixes constraints in the platform itself. It does not touch the theme, the app stack, the catalogue data or the team’s delivery capacity, and it carries every one of those problems to the new store. Migrating past a configuration problem rebuilds the same problem on new infrastructure, at real cost and risk.
The real signs of a platform ceiling, and the usual misdiagnoses
| Symptom | Usually a platform ceiling when… | Usually setup when… |
|---|---|---|
| Checkout cannot do what the business needs | The step you need (a subscription option, a B2B approval) is unsupported at any price, with any app | It is possible but nobody has built it yet |
| Extensions conflict | Every release becomes a compatibility audit and new integrations break existing ones | One or two plugins clash |
| Failures at scale | Checkout times out at a reproducible order volume, and no caching or hosting change moves it | It happens only with one app or one theme section |
| Running costs | Fees, required apps and hosting, modelled on your real volumes, exceed a comparable build | Fees just feel high |
| “The site is slow” | Rarely | Theme weight, app scripts and images, which a lean theme fixes; see what actually moves Core Web Vitals |
| “Conversion is stuck” | Rarely | Product pages, trust signals, navigation and checkout design |
| “The catalogue is a mess” | Never | Duplicate SKUs and inconsistent attributes, which a migration imports faster |
FleaSolve: one migration, sorted into platform and setup
FleaSolve makes vet-grade flea and tick treatments for cats and dogs in the UK. Its Amazon and eBay listings were doing well; its own store, on WooCommerce, lagged behind them on speed, trust and checkout.
We migrated it to a Shopify 2.0 theme customised for the brand. The case record lists five problems, and they do not all point the same way.
| Recorded problem | Platform or setup? | What the build did |
|---|---|---|
| Ongoing management of WooCommerce plugins, updates and customisations taking time from the brand | Platform: the overhead came with the plugin model | Moved to Shopify, removing the plugin dependencies |
| Speed, scalability and maintenance constrained by the existing set-up | Both: speed is often setup, maintenance load was platform | New theme, designed mobile-first rather than adapted from desktop |
| Weak integration with analytics and retention tools | Both: test what the current platform can connect first | Klaviyo for email and retention; GA4, Google Tag Manager and the Meta Pixel for measurement |
| Design lacked the trust a vet-grade product needs | Setup | Vet-grade positioning, certifications, reviews and compliance messaging placed where a first-time buyer reads before trusting the product |
| Complex navigation, few trust signals at the decision, a weak checkout | Setup | Simpler navigation, better product discovery and a streamlined checkout |
Two of the five were setup problems that a migration on its own would have carried across. They were fixed because the move came with a new theme and new UX work, delivered as one engagement.
The record states the outcomes in plain terms: faster pages, a simpler trust-led checkout, more mobile engagement and less operational overhead from plugins. It gives no figures, and we add none. The full record is in the FleaSolve case study.
The lesson for your own decision: list your problems, sort them like this, and only count the platform column as reasons to migrate. If the setup column is long and the platform column is short, fix the setup first.
A five-question self-check before you commit
- Is the constraint reproducible at a specific volume or checkout step? Consistently, at a documented scale, points to the platform. Only with a particular app or section points to setup.
- Have you tried a lean theme and a smaller app stack? If not, you do not yet know whether the platform is the limit.
- Is the blocked feature unsupported, or only unbuilt? Unsupported is a ceiling. Unbuilt is a backlog.
- Have you modelled running costs on your real volumes? A calculated crossover is a signal; a feeling about fees is not.
- Do you have a redirect map and a rehearsal plan, or just a target platform? If protecting rankings is still “something we’ll sort out during the move”, the migration is not ready to schedule.
- 1Is the constraint reproducible at a specific volume or checkout step?NoOnly with one app or section: a setup problem
- 2Have you tried a lean theme and a smaller app stack?NoTry it first: you do not yet know the platform is the limit
- 3Is the blocked feature unsupported, not just unbuilt?NoUnbuilt is a backlog, not a ceiling
- 4Have you modelled running costs on your real volumes?NoA feeling about fees is not a signal: model it
- 5Do you have a redirect map and a rehearsal plan?NoNot ready to schedule: protect rankings first
What migration risk actually costs, and when not to move
The real risk sits in search. A platform change moves URL structures and template markup at once, so search engines re-evaluate the whole site. Every URL that has earned rankings needs a tested one-to-one redirect before cutover, not a blanket redirect to the homepage added afterwards; a technical SEO review run alongside the build catches what generic rules miss.
Migrations that pay off are sequenced, not rushed. They start with a full inventory of products, customers, orders and ranking URLs mapped to their destination, rehearse the cutover on a staging copy, and keep the old store reachable until every count reconciles. That is the standard our Shopify migration work runs to.
Do not migrate when the self-check lands on theme, apps, data or delivery capacity; fix those on the current platform, faster and with less risk. Do not migrate in the run-up to your peak trading weeks.
And do not assume Shopify is the destination: heavy B2B pricing logic can still fit Magento better, and a content-led store wired into WordPress may be right to stay on WooCommerce. The destination follows from what the store must do.
