Rule out checkout and pricing UX before blaming the platform
Most replatforming conversations start with a symptom — usually abandoned carts — and jump straight to a vendor pitch. Test the symptom against known causes before you scope anything.
Baymard’s cross-study analysis (opens in a new tab) puts the average online shopping-cart abandonment rate at 70.22% across 50 studies. Among shoppers who state a reason for abandoning rather than just browsing, the leading causes are extra costs being too high (40%), slow delivery estimates (20%), mandatory account creation (18%), and a checkout process that’s too long or complicated (17%).
None of those four causes is controlled by the underlying commerce engine. Extra costs, delivery estimates, account requirements and form length are configuration and copy decisions, made on top of whichever platform you run. A migration that carries the same checkout configuration forward changes the engine underneath and leaves the abandonment rate exactly where it was.
Run this checklist before you write a single line of a migration brief:
- Guest checkout is enabled and not buried behind a “create account” wall
- Shipping, tax and any surcharges are shown before the final step, not revealed at payment
- A delivery estimate appears on the product or cart page, not only after address entry
- The checkout form asks for the minimum fields needed to ship and bill the order
If your abandonment rate sits near 70% and you haven’t checked these four items, you have a UX and pricing problem, not a platform ceiling. Fix them first and remeasure. Only look past this section if the number holds after the fixes.
You should now see: your own abandonment rate categorised against Baymard’s named reasons, before any platform is on the table.
Define what actually counts as a platform limit
A genuine platform limit is narrow enough to check against a document, not a feeling. Three criteria qualify. Everything else is implementation or process debt, and debt is fixable without a migration.
flowchart TD
A[Symptom: abandonment, errors, deadline, security flag] --> B{Vendor-published lifecycle lapsed?}
B -- Yes --> Z[Genuine platform limit]
B -- No --> C{Documented API ceiling saturated after optimisation?}
C -- Yes --> Z
C -- No --> D{Mandatory deprecation on vendor's own calendar?}
D -- Yes --> Z
D -- No --> E[Implementation or process debt: fixable in place]
Criterion 1: a vendor-published support lifecycle that has actually lapsed for the version you run in production, checked against the vendor’s own lifecycle document.
Criterion 2: a documented API or resource ceiling that a cost-optimised integration still saturates, checked against the vendor’s own limits documentation.
Criterion 3: a mandatory deprecation with a fixed date on the vendor’s own calendar, checked against the vendor’s own changelog.
An unmaintained host stack, undocumented business rules and plugin sprawl fail all three. They’re real, they cost money, and they’re fixable in place. The check for each criterion has to run against primary vendor documentation — not a replatforming vendor’s pitch deck, and not an SEO roundup summarising someone else’s pitch deck.
Check whether your platform’s support lifecycle has actually lapsed
Adobe Commerce and WooCommerce publish their lifecycle terms in different places, and the two get confused constantly. Check the right document for the platform you actually run.
Adobe’s lifecycle policy (opens in a new tab) gives every Adobe Commerce release a three-year standard support window measured from its general-availability date. Versions 2.4.6 and 2.4.7 each get one further year of security-only extended support on top of that window. Read the fine print carefully: the policy explicitly excludes third-party dependencies, so an unsupported PHP or MySQL version underneath a supported Commerce release is a separate problem with its own separate clock.
Adobe has never published an end-of-life date for Magento Open Source. The lifecycle policy document applies to Adobe Commerce specifically — if you run Open Source, “lifecycle lapsed” isn’t a criterion you can invoke from that document at all.
WooCommerce’s requirements move with each release rather than on a fixed calendar. WooCommerce 10.9 (opens in a new tab) requires PHP 8.3 or higher (tested to 8.4), WordPress 6.9 or higher, and MySQL 8.0 or MariaDB 10.6 or higher. WooCommerce 10.8 (opens in a new tab), released 26 May 2026, is what raised the WordPress floor to 6.9.
Two pitfalls show up in the wild. First: “WooCommerce doesn’t scale” gets stated as the reason to replatform while the host still runs PHP 7.4 and unpatched MySQL 5.7 — that’s unmaintained hosting, not a WooCommerce ceiling, and upgrading the host is cheaper than migrating the store. Second: a security scan comes back clean today, but the running Adobe Commerce release hits its lifecycle end date within a few months. “Still runs fine” isn’t “still supported” — check the date now, not when the scan changes.
You should now see: the exact document and version field to check for your own stack, before anyone cites “end of life” as a migration reason.
Tell a genuine API ceiling from an inefficient integration
Shopify’s Admin API rate limits get blamed for problems that a query rewrite would fix. Check the actual accounting before you conclude the plan tier is the bottleneck.
Shopify’s GraphQL Admin API (opens in a new tab) limits by calculated query cost, not raw request count. Standard plans get 50 points per second, Advanced gets 100, and Shopify Plus gets 500. A separate, harder rule applies regardless of plan: any single query is capped at 1,000 points, full stop.
Every response returns the query’s actual cost in an extensions object, in this shape:
{
"data": { "...": "..." },
"extensions": {
"cost": {
"requestedQueryCost": 1002,
"actualQueryCost": 950,
"throttleStatus": {
"maximumAvailable": 1000,
"currentlyAvailable": 50,
"restoreRate": 50
}
}
}
}sequenceDiagram
participant App as Integration
participant API as Shopify GraphQL Admin API
App->>API: Query with deep nested connections
API-->>App: 200 OK, extensions.cost.actualQueryCost 950
App->>API: Same-shaped query again
API-->>App: 429 THROTTLED
Note over App,API: 1,000-point cap applies per query,<br/>independent of plan tier
If 429/THROTTLED errors persist after an upgrade to Plus, the likely cause is a single unbounded or deeply nested query approaching the 1,000-point per-query cap — a limit the Plus upgrade doesn’t touch, because it governs points per second, not points per query. Read extensions.cost on the failing query, trim pagination and nested connections, and retest. Only call it a plan-tier ceiling if the cost-optimised version still saturates the per-second budget.
You should now see: one field in one API response that tells you whether your rate-limit errors are a query problem or an actual plan-tier ceiling.
Recognise a mandatory vendor deprecation on a fixed calendar
Criterion 3 is the easiest to confirm and the easiest to fake. A genuine mandatory deprecation has a public date attached to it, published by the vendor, not implied by an agency’s proposal.
Shopify’s retirement of checkout.liquid is the clean example. Shopify’s changelog (opens in a new tab) shows customisation of the Information, Shipping and Payment steps stopped working on 13 August 2024. Thank You and Order Status page customisations, along with script tags, were sunset on 28 August 2025.
That’s what a real forced migration looks like: two dated, vendor-published cutoffs, tied to a named deprecated feature, announced ahead of time in the vendor’s own changelog. Nothing subjective about it — the code either runs after the date or it doesn’t.
Apply one test to any claimed deprecation: does the vendor publish a changelog or notice with an actual date attached, or is the deadline self-imposed by whoever is pitching the migration? If you can’t produce the vendor’s own dated notice, you don’t have criterion 3 — you have a sales deadline.
Weigh the risk of a full rewrite before scoping a migration
Once a real ceiling clears one of the three criteria, the next mistake is scoping the fix as a full cutover when a narrower fix carries less risk.
Martin Fowler’s strangler-fig pattern (opens in a new tab) replaces one failing seam — search, checkout, product information — behind the existing platform via a routing layer, instead of a big-bang rewrite of everything at once.
flowchart LR
U[Storefront traffic] --> R[Routing seam]
R -->|checkout requests| N[New checkout service]
R -->|everything else| L[Existing platform]
N --> DB[(Shared order data)]
L --> DB
Joel Spolsky’s argument against full rewrites (opens in a new tab) still holds for commerce platforms: old code looks messy mostly because it encodes fixes for real production edge cases that nobody wrote down anywhere else. A rewrite throws that accumulated knowledge away and tends to reintroduce the same bugs, while competitors keep shipping.
An ecommerce replatform carries the same risk profile as any full-system rewrite, arguably worse. Discount rules, tax exceptions and inventory-hold logic frequently exist only as running code, with no specification document to hand the new team. A “quick six-month replatform” is still not live at month fourteen because edge-case business rules keep surfacing late in QA, one at a time, each one a surprise.
Inventory the undocumented business rules before you sign a fixed-scope migration contract. If that inventory turns up more than a handful of rules nobody can explain, migrate one seam at a time behind the existing storefront instead of committing to a single cutover date.
You should now see: a documented middle option — migrate one subsystem, not the whole platform — sitting between “do nothing” and “full cutover.”
Run the diagnostic checklist before you scope a migration
The whole framework compresses to three steps. Run them in order, on your own stack, before anyone drafts an RFP.
Step 1 — name the symptom precisely. Not “the platform feels old” — an abandonment rate, a specific 429 error, a missed compliance deadline, a security scan result with a date attached.
Step 2 — trace it to a primary-sourced vendor document. A lifecycle policy page, an API limits page, a dated deprecation changelog. If no such document exists for the symptom, it’s internal debt, and debt gets fixed in place.
Step 3 — only scope a full migration once a real ceiling is confirmed against documentation, never against a replatforming vendor’s pitch deck.
Watch for one number in particular: the widely repeated claim that 90% of platform switchers saw revenue improve traces to commercetools’ own vendor-commissioned survey (opens in a new tab), which doesn’t disclose sample size or methodology in its public materials. Treat it as a vendor claim, not a base rate you can plan a business case around.
You should now see: a short, repeatable checklist you can run against your own platform before anyone pays for a migration scope.
Limitations
No independently verified, methodology-disclosed figure exists for average replatform cost, timeline or failure rate, and this framework doesn’t supply one — treat any such number you’re given elsewhere with the same scepticism applied to the commercetools claim above.
This framework stops at the go/no-go decision. It does not cover vendor selection, RFP structure, or how to run the migration once a real ceiling is confirmed — that’s a separate decision with its own separate risks.