Choosing an ecommerce platform is not a decision you make once. The tooling that suits a business shipping twenty orders a day is rarely the tooling that suits it at two thousand, and outgrowing a platform is usually evidence that the business worked, not that someone chose badly at the start.
What makes the second decision harder than the first is that you now have something to lose. A live catalog, years of customer records, accumulated search visibility, and revenue that has to keep flowing while the move happens. So the question shifts. It stops being “which platform is best” and becomes something narrower and more answerable: is our current platform imposing costs and constraints that a migration would remove, and are those costs larger than the cost and risk of moving?
That has a real answer for your store, and it is reached with evidence rather than instinct. Worth reaching for deliberately, too, because replatforming decisions often get made reactively, in the week after an outage, when someone senior asks why the site went down during a promotion. The outage is real information. It is also one data point, and a single symptom is a thin basis for a six-figure project.
This guide sets out how to build the fuller picture: the evidence to gather, the signals that genuinely indicate you have outgrown your stack, the situations where migrating is the wrong move, and what the project involves once you commit.
Start by pricing the status quo
The most common reason stores stay too long on a platform that no longer fits is sunk cost. The reasoning goes: we spent eighty thousand building this, we cannot walk away from it now.
That money is gone regardless of what you decide. It is not recoverable by continuing to use the thing you bought. The only figure that should influence the decision is what the platform costs you going forward, and that figure is almost always larger than the line item finance is looking at.
Build a real total cost of ownership figure
Pull twelve months of actuals and add up:
- Hosting and infrastructure, including any CDN, staging environments, and the surge capacity you provision for peak trading.
- License and subscription fees for every paid extension, plugin, or module in the stack. Include the ones nobody uses but nobody has dared uninstall.
- Maintenance development. This is the line most teams underestimate. Go through twelve months of developer time and separate work that added capability from work that merely kept the lights on: security patches, extension compatibility fixes, breakages after a core upgrade. The keeping-the-lights-on portion is pure platform tax.
- Opportunity cost of the queue. How many marketing requests sat in a development backlog for more than two weeks? What was the campaign value of the ones that expired before they shipped?
- Downtime and degradation. Take your revenue per hour during peak trading periods, and multiply by hours lost to outages plus a conservative estimate for hours spent degraded.
The sum is your real annual platform cost. Compare it to the fully loaded cost of a managed platform: subscription, transaction fees, apps, theme development, and the amortized cost of the migration itself over three years.
For a lot of mid-market stores that number comes out clearly in favour of moving. For some it does not. Either way, you now have a defensible figure rather than a feeling.
Two ways old infrastructure quietly drains budget
The maintenance treadmill. On self-hosted platforms, a meaningful share of your development budget buys no new capability. You patch, you fix extension conflicts after a core update, you keep the server upright. You are spending real money to remain exactly where you are.
The change latency tax. When a merchandiser wants to swap a homepage banner or a marketing manager wants to spin up a landing page for a flash sale, and both require a developer ticket, your commercial team’s speed is capped by your engineering team’s capacity. Competitors who can ship those changes in an afternoon will take the sales you were slow to chase.
Five signals that you have genuinely outgrown your stack
One of these on its own is usually a fixable problem. Two or more, persisting across quarters, is a structural mismatch between your business and your platform.
Each signal below includes how to verify it, because “the site feels slow” and “the site fails LCP on mobile for 40% of sessions” lead to very different conversations internally.
1. Traffic spikes take the store down
The failure mode is specific: the store is fine at ordinary volume and falls over exactly when volume is highest. Black Friday. An influencer post landing. An email to the full list.
This is the most expensive possible time to be offline, and the losses compound: you lose the session, the acquisition spend that bought it, and some portion of the customer relationship.
Speed matters below the outage threshold too. Google’s own research, cited widely since it was published, found that 53% of mobile site visits are abandoned if a page takes longer than three seconds to load (Think with Google). During a traffic surge, degraded response times apply that penalty to your most valuable traffic of the year.
How to verify it: pull server response times and error rates from your last three peak events and overlay them against sessions. If p95 response time climbs sharply as concurrency rises, you have a scaling ceiling rather than a bad week.
2. Every commercial change requires a developer
Your merchandising and marketing teams understand your customers better than anyone. If they cannot change a hero image, adjust copy, reorder a collection, or publish a landing page without filing a ticket, you have a bottleneck that costs you in two currencies: developer hours spent on trivial edits, and campaigns that never launched.
How to verify it: count the tickets. Take a quarter of development requests, classify each as content, configuration, or genuine engineering, and calculate what proportion of your engineering capacity went to the first two categories. If it is above a quarter, the bottleneck is structural.
3. Extension conflicts have become a permanent condition
Platforms with thin native functionality force you to assemble capability from third-party extensions: tax calculation, reviews, loyalty, subscriptions, shipping rules. Each is built by a different vendor against a different assumption about the core.
The predictable result is that a routine update to your inventory extension breaks checkout. You are not maintaining a store; you are running continuous incident response, and every fix carries a non-trivial chance of causing the next incident.
How to verify it: count production incidents over twelve months and tag each with root cause. If extension conflicts and post-update regressions dominate, the problem is architectural, not a run of bad luck.
4. Your storefront and your operations are out of sync
At low volume, manually re-keying orders into your fulfilment system is tolerable. At scale it is not, and the bespoke integration someone wrote three years ago becomes the weakest link in the business.
When that link breaks under load, the failure is visible to customers: stock levels on the site diverge from actual stock, orders ship late, and you oversell items you do not have. Overselling is particularly damaging because the customer has already committed emotionally and financially before you disappoint them.
How to verify it: measure oversell incidents per thousand orders and the lag between a sale and the corresponding inventory decrement in your system of record. Both should be near zero.
5. Mobile checkout is losing sales you have already paid for
Most sessions are mobile. If your checkout requires long forms, multiple page reloads, or manual card entry on a small screen, you are shedding buyers at the last and most expensive step of the funnel.
Some abandonment is structural rather than fixable: people comparison shop, people browse without intent. But research from the Baymard Institute puts average ecommerce cart abandonment at roughly 70%, with 17% of shoppers abandoning specifically because checkout was too long or complicated. That second figure is the addressable portion, and it is large.
How to verify it: build a funnel from cart to purchase, segmented by device. Compare mobile and desktop completion rates at each step. A mobile-specific drop concentrated at a single step points at a fixable interface problem; a uniform gap across every step points at platform-level performance.
The signals summarised
| Signal | What it costs | What a managed platform changes |
|---|---|---|
| Outages under peak load | Revenue lost at the highest-value moment of the year | Infrastructure scales without your involvement |
| Developer bottleneck on content | Engineering hours on trivial edits; campaigns that never ship | Merchandisers edit sections directly |
| Extension conflicts | Unplanned incidents, often at checkout | Fewer third-party dependencies in the critical path |
| Storefront/ops divergence | Overselling, late shipping, eroded trust | Maintained integrations to major systems |
| High-friction mobile checkout | Abandonment at the most expensive funnel step | Accelerated checkout and stored wallet credentials |
When migrating is the wrong decision
Agency content rarely covers this, but it matters more than any of the above, because a migration undertaken for the wrong reason destroys value.
Your problem is a theme problem, not a platform problem. If the store is slow because of an unoptimized template, uncompressed hero images, and eleven marketing scripts in the head, replatforming will carry all of those decisions to the new platform. Fix the front end first and re-measure. You may find the ceiling was never the platform.
You are mid-way through another major change. Replatforming during an ERP implementation, a rebrand, or a warehouse move means that when something breaks (and something will) you will not be able to isolate the cause. Sequence them.
You do not have an owner. Migrations fail on coordination, not code. If nobody internally has the authority to arbitrate between merchandising, finance, operations, and engineering, the project will stall in exactly the place where those functions disagree.
Peak trading is within four months. The pre-launch validation window is where migrations are won. Compressing it to hit a date before your highest-revenue period is the single most reliable way to turn a manageable project into a bad quarter.
Your requirements are genuinely unusual. Heavily bespoke pricing logic, unusual regulatory obligations, or a deeply integrated proprietary system may cost more to reproduce on a hosted platform than the migration saves. Establish this early with a technical feasibility review, not after committing.
What you actually gain, and how to assess the claims
Worth separating durable structural advantages from vendor marketing.
Structural, and reliably true: infrastructure and scaling stop being your problem; security patching and platform upgrades happen without your involvement; commercial teams get direct control over merchandising and content; multi-currency, multi-language, and market-specific domains are configuration rather than separate builds.
Vendor claims, to be treated as claims: Shopify states that its accelerated checkout network, Shop Pay, can increase checkout conversion by up to 50%. The underlying mechanism is real: recognized shoppers with stored credentials complete checkout with far less friction than those typing card details on a phone. But “up to” figures published by a vendor about its own product describe a best case under favourable conditions, not an expected result for your store. Treat it as directional, and plan to measure your own lift after launch rather than budgeting against someone else’s number.
That distinction is worth carrying into every platform evaluation you run. The structural advantages are what you are buying. The conversion percentages are marketing until you have measured them on your own traffic.
The four workstreams of a migration
Moving an established store is not a data transfer with a design refresh attached. Four workstreams run in parallel, and underinvesting in any one of them is where projects go wrong.
Data preparation and cleansing
Your database has accumulated a decade of mess: duplicate customer records, orphaned tags pointing at deleted products, inconsistent attribute naming, variants that exist only as a workaround for something the old platform could not do.
Migrating that mess faithfully reproduces it on the new platform. The preparation phase should extract catalog and customer records, normalize formatting, resolve duplicates, and map your existing product structure onto the target platform’s model, which will differ (sometimes significantly) in how it represents options, variants, and metadata.
Do this before anything else. Every downstream workstream depends on knowing what your data actually looks like.
Search visibility preservation
This is the workstream with the highest downside risk, because the damage is delayed. You launch, everything appears fine, and organic traffic degrades over the following weeks.
The mechanism is straightforward. Your existing URL structure (say /shop/category/product.html) will not survive the move, because Shopify uses fixed patterns like /products/product-name and /collections/collection-name. Every indexed URL, every backlink pointing at your old structure, and every link in every email you have ever sent will resolve to a 404 unless you map it.
The deliverable is a complete redirect map: every old URL, its closest equivalent on the new platform, and a permanent 301 redirect between them. It has to be built from a crawl of the live site plus your Search Console and analytics data, so that pages with traffic or links are not missed. It has to be validated before launch, not after.
This is covered in depth in the dedicated SEO articles in the eComCademy blog, and it deserves that depth: it is the difference between a migration that is invisible to customers and one that costs you a year of accumulated search equity.
Storefront rebuild
Themes do not port between platforms. Different templating language, different structural assumptions, different component model. You are rebuilding, not copying.
Treat that as the opportunity it is. You have behavioral data on the current store: where sessions drop, which navigation paths convert, which product page elements get engagement. Rebuilding gives you a chance to act on it rather than faithfully reproducing a design whose weaknesses you have already measured.
Keep the build lightweight. The performance advantage of a managed platform is easy to spend on heavy scripts, oversized imagery, and animation, and stores routinely arrive on a fast platform and immediately make it slow.
Systems integration
For any store past a certain size, the storefront is one node in a wider system: ERP, warehouse management, accounting, CRM, customer service. Each connection needs to be specified, built, and tested against realistic volumes.
The failure mode is an integration that works fine in testing at ten orders and falls over at four hundred. Load-test the integrations, not just the storefront.
Pre-launch validation
Launch day should be an anticlimax. Everything that could reveal a problem should have revealed it in the preceding weeks, in a password-protected staging environment.
The validation set that actually catches problems:
- Real transactions through every payment method you offer, confirming funds settle correctly, not just that the confirmation page renders.
- Tax and shipping calculation across every region you serve, including the awkward cases: thresholds, exemptions, multi-item baskets crossing weight bands, addresses that historically caused problems.
- Synthetic load at multiples of your realistic peak, with integrations connected, so you are testing the whole system rather than the storefront alone.
- Manual walkthrough of the complete purchase path on real devices, across several phone models and both major mobile browsers. Emulators miss things.
- Redirect validation on a sample of your highest-value URLs, confirming each resolves in a single hop to the correct destination with a 301 status.
Cutover
Schedule the DNS switch for your lowest-traffic window, genuinely lowest, from your own analytics, not an assumption. For most stores that is somewhere in the small hours mid-week.
Lower your DNS TTL well ahead of the switch so propagation is fast and a rollback is quick if needed. Have a defined rollback trigger agreed in advance, with a named person authorised to call it. Deciding what constitutes “bad enough to revert” at three in the morning, under pressure, is not a decision anyone makes well.
Making the call
Replatforming is not an upgrade you graduate to at a particular revenue level. It is a response to a specific, measurable mismatch between what your business needs to do and what your current platform will let it do.
If you have built the TCO figure, verified two or more of the structural signals, and confirmed that none of the “do not migrate yet” conditions apply, you have a case that will hold up to scrutiny. If you have not, the honest answer might be that your platform is fine and your theme is not, which is a far cheaper problem to solve.
Either way, the work of gathering that evidence is not wasted. It gives you a baseline to measure against, and it is the same dataset you will need to prove the migration worked.
