When to Replatform, and How to Survive It
Platform share barely moved in a year. Adobe is now selling a way to avoid replatforming. Here is when migration is genuinely right, and what it actually costs.
Replatforming is the most expensive decision an ecommerce team makes and the one they're least equipped to evaluate, because the person proposing it is usually either an agency that builds on the destination platform or a developer who's tired of the current one. Neither is a neutral party. Neither is lying, either.
Start with a number that should slow everybody down. Across the whole measurable web, platform share barely moved between 2024 and 2025. WooCommerce held flat at about 36% of ecommerce sites. Shopify went from about 20% to 21%. Wix went 7% to 8%. PrestaShop dropped 4% to 3%[1].
That's a market where the noise about migration vastly exceeds the migration. Most stores that talk about replatforming don't, and a decent share of the ones that do shouldn't have.
Here's the other signal, and it's a good one because it comes from a vendor acting against its own historical interest. Adobe now sells a product whose stated purpose is to let you "grow and scale your catalog without re-platforming your entire commerce stack"[2]. When the enterprise platform vendor starts selling not-replatforming, the composable pendulum has swung.
What actually changed, and what did not
What changed: the composable story got quieter
For about five years the received wisdom was that monoliths were legacy and every serious retailer was heading toward a set of best-of-breed services stitched together. Some did. What emerged from the ones who went furthest was an integration bill nobody had modelled, and a realisation that a mid-market retailer with a single storefront doesn't get four years of competitive advantage from choosing their own search vendor.
Adobe Commerce Optimizer is the clearest artefact of the correction: an explicitly non-migratory storefront and merchandising layer that sits alongside whatever backend you already have, including non-Adobe ones[2]. The pitch is "keep your backend, improve the bit customers see". That is the opposite of what the same category was selling in 2021.
What did not change: the reasons to actually move
There are real ones. Unsupported software, a platform your payment or tax requirements have outgrown, an ownership change that killed your roadmap, or a total cost of ownership that has quietly doubled. Those haven't gone anywhere and they're covered below.
What has changed is that "our platform feels old" is no longer sufficient, because there's now a whole product category built on decoupling the storefront from the backend precisely so you don't have to do the expensive thing.
Does this actually impact you? Six honest triggers
Migration is justified when one of these is true. Not when the site looks dated.
1. Your version is going out of support
This is the only trigger with a date attached, which makes it the easiest to plan around and the most commonly ignored. Adobe publishes a lifecycle policy with two phases, bug-fix maintenance then security-only, then nothing[3]. Current positions: 2.4.6 support ends 11 August 2026, 2.4.7 runs to April 2027, 2.4.8 to April 2028, and 2.4.9 went GA in May 2026[4].
Note what that gives you: an upgrade is usually much cheaper than a migration, and the upgrade path within Magento is documented[5]. A lot of "we have to replatform, we're on an unsupported version" conversations are actually "we've deferred upgrades for four years and the accumulated debt now looks like a migration."
2. API deprecation you can't keep up with
Shopify ships a new API version every quarter, supports each for at least 12 months, and guarantees at least nine months of overlap between consecutive versions[6]. That's a generous cadence and it's still a permanent maintenance obligation on every integration you own. If you have six custom integrations and nobody assigned to version churn, you have a slow-motion outage scheduled.
3. The economics stopped working
Platform fee plus transaction fees plus app subscriptions plus agency retainer. Shopify charges 2% on Basic down to 0.2% on Plus for third-party gateways[7]; BigCommerce charges 2.0% on Core down to 0.6% on Scale for open payment providers, and auto-upgrades your plan when GMV passes a threshold[8]. Those auto-upgrade clauses are the thing that turns a predictable cost into a surprise.
4. A capability the platform structurally cannot do
B2B pricing tiers, multi-warehouse allocation, per-country catalogues, 3,000 variants on one product. Note that some of these moved: Shopify raised the variant limit to 2,048 per product on 15 October 2025, up from 100[9]. If the constraint that drove your migration plan was the old 100-variant ceiling, re-check it before you spend anything.
5. Performance you can't fix in place
Sometimes true, often not. Across the whole web only 48% of origins pass Core Web Vitals on mobile[17], so "we fail Core Web Vitals" is not by itself evidence of a platform problem. The Web Almanac's platform-level numbers are stark: Shopify at 76% of origins passing, BigCommerce 55%, Magento 36%, WooCommerce 33%[1]. Before concluding your platform is the problem, read the page speed piece, because most of that gap is hosting, images, plugins and theme quality rather than the platform itself.
6. Nobody will maintain it
The least discussed and often the most decisive. If your platform's talent pool has evaporated locally, every future change costs more and takes longer, regardless of the technical merits.
The stakes if you get it wrong
Three failure modes, in order of how often I've seen them.
Organic traffic collapse. URL structures change, redirects get done at 80%, category pages lose their rankings, and six months of paid spend goes into filling a hole you dug. Google's own site-move guidance is specific about redirect mapping and it's routinely half-implemented[10]. Use 301s, not 302s, and map every URL that has ever earned a link[11].
Data loss in the migration itself. Not orders. Everybody migrates orders. What gets lost is order history detail, customer notes, subscription contracts, loyalty balances, review associations, and every product attribute that didn't have an obvious destination field. That last category is the one that hurts eighteen months later.
The re-integration tail. The migration project ends when the site launches. The actual work ends when the ERP sync, the tax service, the fulfilment feed, the returns portal and the review platform are all reconnected and reconciled. That tail routinely runs longer than the build.
What we found: platform share moves much slower than the discourse
We put the Web Almanac's 2024 and 2025 ecommerce chapters side by side, because year-on-year movement is a much better signal than any survey about intent.
| Platform | 2024 share | 2025 share | Movement | CWV pass rate 2025 |
|---|---|---|---|---|
| WooCommerce | ~36% | ~36% | Flat | 33% |
| Shopify | ~20% | ~21% | +1pt | 76% |
| Wix eCommerce | ~7% | ~8% | +1pt | 70% |
| PrestaShop | ~4% | ~3% | -1pt | Not reported |
Source for all of it: HTTP Archive's 2025 ecommerce chapter[1].
Two readings, and I think the second is the interesting one.
The obvious reading: Shopify is winning slowly, Woo is holding, the long tail is eroding. Fine, unsurprising.
The less obvious one: the platform with by far the worst measured performance profile is also the one losing no ground at all. WooCommerce sits at a 33% Core Web Vitals pass rate against Shopify's 76%[1], and its share didn't move.
Which tells you something about how replatforming decisions actually get made. They are not made on measured technical quality. They're made on cost, on who's available to work on it, and on whether somebody senior got frustrated. If performance drove migration, that table would look very different.
One more thing from the same chapter, and it's a methodological caveat worth carrying: headless implementations are systematically undercounted, because "headless implementations reduce platform detectability because the traditional fingerprints in HTML/JS often disappear"[1]. So the composable segment is bigger than any of these numbers show. Nobody knows by how much, and anyone claiming a precise figure is guessing.
If you are on Shopify
Reasons to leave that are real
B2B complexity beyond what Shopify's B2B features cover, genuinely unusual fulfilment logic, or a total cost where Plus plus apps plus transaction fees exceeds what a self-hosted stack costs including the team[7]. That crossover exists and it's higher than most people think.
Reasons to leave that usually aren't
Checkout customisation. Shopify's checkout is closed, that's not changing, and the extension model covers more than it used to[12]. If the migration business case is "we want to redesign checkout," go and read the abandonment data first, because the changes that move the number are mostly available to you already.
Also worth re-checking before you commit: the variant limit moved to 2,048 in October 2025[9]. Several migration business cases I've seen were built on a constraint that no longer exists.
The lock-in that actually bites
Subscription contracts. If you run subscriptions through a Shopify app, those contracts live in Shopify's data model[13] and migrating an active subscriber base to a different platform means re-authorising payment credentials. Some of your subscribers will not come. That cost belongs in the business case and it's almost never in it.
Not on Shopify? The other platforms
WooCommerce
The migration conversation on Woo is usually a hosting and plugin conversation in disguise. Before you price a platform move, price a move to proper managed hosting with a persistent object cache, an audit that removes half your plugins, and High-Performance Order Storage if you're not on it[14]. That's a fraction of the cost and it fixes most of what people migrate to escape.
Check the public roadmap before assuming a gap is permanent[18].
Woo's genuine structural limits show up at large catalogue sizes with heavy faceted filtering and at high concurrent checkout volume. Those are real. "The admin feels slow" is usually not.
Magento and Adobe Commerce
The decision here is three-way rather than two-way, and that's new. You can upgrade in place[5], you can migrate off, or you can keep the backend and put a modern storefront layer in front of it[2].
That third option didn't meaningfully exist a couple of years ago and it changes the maths for a lot of mid-market Magento merchants who have a functioning backend, a genuinely complex catalogue, and a storefront that's embarrassing. Price all three before choosing. Most agencies will only quote you the one they build.
Whichever you pick, the GraphQL surface is what your storefront and integrations will consume[19].
Hard deadline to hold in mind: if you're on 2.4.6, that's 11 August 2026[4].
BigCommerce
The commercial structure is what to watch. Plans auto-upgrade at GMV thresholds and open payment providers carry a percentage fee[8]. Model your costs at next year's revenue, not this year's, before deciding whether you're staying.
Technically BigCommerce is a reasonable place to be, with a documented API surface and no meaningful version-churn problem[15]. Its problem is ecosystem depth, which shows up as "there's no app for that" more often than on Shopify.
Headless and composable
The MACH Alliance is the industry body behind most composable messaging, and reading it as advocacy rather than analysis is the right posture[20].
Going headless is a replatform with the risk concentrated differently. You keep more optionality and take on permanent front-end ownership. The honest test: do you have, and will you keep, at least one full-time front-end engineer? If the answer is "our agency handles it," you're buying a dependency, not independence. More here, and on the composable trade-offs.
The replatforming decision table
| Situation | Do this first | Migrate if |
|---|---|---|
| Version out of support | Price an in-place upgrade[5] | Upgrade cost approaches migration cost |
| Site is slow | Hosting, images, plugin audit[1] | Still failing after all three |
| Costs rising | Model 3-year TCO on both[7] | Crossover inside 24 months |
| Missing a capability | Re-check current limits[9] | Genuinely structural, not a setting |
| Storefront is dated, backend fine | Decoupled storefront layer[2] | Backend is also failing |
| Nobody can maintain it | Assess the local talent pool honestly | You've tried to hire and couldn't |
| Integrations keep breaking | Assign an owner for API versioning[6] | Still breaking with an owner |
How to survive the migration itself
Assuming you've decided. The order matters more than the tooling.
- Freeze the URL map first, not last. Export every URL with organic traffic or an inbound link before design starts, and make the new platform's URL structure a design constraint[10].
- Migrate product data before anything else, and treat missing attributes as blockers rather than backlog. This is where a PIM earns its keep. See the PIM piece.
- Inventory your integrations and get a named owner and a test plan for each. Count them. It's always more than you thought.
- Run both platforms in parallel for at least one full order cycle including a return.
- Keep the old analytics running through the switch so you can tell a tracking break from a traffic drop. The analytics piece covers what breaks.
- Plan for the 404 spike. AI crawlers already waste roughly a third of their fetches on dead URLs across the web[16], and a sloppy migration makes that much worse for your own site.
- Do not launch in Q4. Everyone knows this. Someone will suggest it anyway.
What agentic commerce does to the decision
It adds one requirement and removes one excuse.
The requirement: whatever you move to has to emit clean, server-rendered, machine-readable product data. Price, availability, delivery window, return terms, stable identifiers. If a candidate platform's default output requires JavaScript to show a price, that's now a disqualifier rather than a preference, because AI crawlers don't run it[16].
The excuse it removes: "we need to migrate to be AI-ready." Mostly you don't. Structured data, server rendering and complete product attributes are achievable on all four major platforms. The bottleneck is your catalogue, and your catalogue migrates with you.
What to do this week
- Write down the actual trigger. One sentence. If you can't, you don't have a business case yet.
- Check your version's end-of-support date and put it in the calendar[4].
- Count your integrations. Every system that reads or writes your commerce data. Name an owner for each.
- Export your URL inventory with organic traffic attached, today, whatever you decide.
- Price the three-year TCO of staying, including the upgrade you've been deferring.
- Re-check the constraint that started this conversation. Platform limits move[9].
- Get one quote from an agency that doesn't build on your target platform. The most useful hour you'll spend.
The takeaway
Platform share moved by roughly one point in a year across the whole web[1], and the enterprise vendor that used to sell the biggest migrations now sells a way to avoid one[2]. Both of those should make you slower to move, not faster.
If you want the counterweight to all of this, read a platform vendor's own investor material and notice how much of the growth story is new merchants rather than migrated ones[21].
The migrations I've watched go well had a specific, dated trigger and a boring plan. The ones that went badly started with a redesign and discovered the platform decision halfway through.
Here's the thing I got wrong for years: I treated the launch as the finish line. It isn't. It's roughly the two-thirds mark, and the last third is unglamorous integration reconciliation that nobody budgeted and everybody resents. Budget it.
What's the one sentence that justifies your migration? Say it out loud and see if it survives.
Sources
- HTTP Archive, "Web Almanac 2025: Ecommerce". Accessed 22 July 2026.
- Adobe, "Adobe Commerce Optimizer overview". Accessed 22 July 2026.
- Adobe, "Software lifecycle policy". Accessed 22 July 2026.
- Adobe, "Released versions". Accessed 22 July 2026.
- Adobe, "Upgrade guide overview". Accessed 22 July 2026.
- Shopify, "API versioning", shopify.dev. Accessed 22 July 2026.
- Shopify, "Shopify pricing". Accessed 22 July 2026.
- BigCommerce, "BigCommerce pricing". Accessed 22 July 2026.
- Shopify, "We've increased the product variant limit to 2048", Shopify changelog, 15 October 2025.
- Google, "Site moves with URL changes". Accessed 22 July 2026.
- Google, "Redirects and Google Search". Accessed 22 July 2026.
- Shopify, "Checkout UI Extensions". Accessed 22 July 2026.
- Shopify, "Subscription contracts". Accessed 22 July 2026.
- WooCommerce, "High-Performance Order Storage". Accessed 22 July 2026.
- BigCommerce, "About the BigCommerce platform". Accessed 22 July 2026.
- Vercel, "The rise of the AI crawler", December 2024. (Vercel sells rendering infrastructure; figures are reproducible from server logs.)
- HTTP Archive, "Web Almanac 2025: Performance". Accessed 22 July 2026.
- WooCommerce, "WooCommerce roadmap". Accessed 22 July 2026.
- Adobe, "Adobe Commerce GraphQL API". Accessed 22 July 2026.
- MACH Alliance, MACH Alliance. Accessed 22 July 2026. (Industry body promoting composable architecture; treat its guidance as advocacy.)
- Shopify, Shopify investor relations. Accessed 22 July 2026.