Replatform or repair: how a UK ecommerce operator should decide

This is for UK ecommerce operators choosing whether to rebuild the store or repair what they have. The cost table for a UK replatform already lives in what an ecommerce replatform costs in the UK in 2026, so this piece doesn't reprint it.

The symptom is not the diagnosis

The conversation usually starts with a feeling, not a measurement. Checkout is slow. The agency takes a fortnight to change a banner. A developer has said Magento is dead, or that Shopify will fix the SEO. Someone has already sent a rebuild quote.

Shopify's own 2026 replatforming guide, published 18 March 2026, draws the line an operator needs: replatforming makes sense "when the problem is the platform", not the configuration. Before you commit, they say, identify issues that can be fixed with configuration, integrations, or small upgrades. Other problems are architectural. That line is from a vendor that sells migrations.

Elogic, who migrate enterprises between Adobe Commerce and Shopify Plus for a living, put it more bluntly in June 2026: most "we must leave Magento" problems are frontend, hosting, or tech-debt issues, now fixable in place with Hyvä, Adobe Commerce Cloud, or Adobe Commerce as a Cloud Service. The useful sentence is not a sales line: sometimes the valuable advice is do not move.

If the store is slow, that is a page-weight, hosting and tag problem until proven otherwise. If rankings slipped after a theme change, that is canonicals, indexation and internal links until proven otherwise. If the catalogue is a mess, a new platform will copy the mess, then charge you to reshape it. The platform gets blamed because it is a noun you can fire. Configuration does not make a satisfying villain.

Run the constraint test before you take a rebuild quote

Three questions, in this order. Write the answers down. If you cannot, you do not have a rebuild brief yet. You have a mood.

• Does this platform support the fix? Shopify's test for staying is explicit: consider optimising when the core issues are site speed, SEO, or UX, and the platform supports those fixes, and when a stable integration ecosystem already works. Magento and Adobe Commerce support frontend replacement, hosting moves and version upgrades. Shopify supports theme, app and tag work without a Plus rebuild. If the fix is available on the current stack, price that work first.
• Are workarounds compounding year on year? Shopify's case for leaving is the other half of the same page: hard technical ceilings (checkout customisation limits, no way to support a new sales channel), maintenance and workaround costs compounding, a vendor roadmap that has slowed, or architectural flexibility the current platform cannot offer. A pile of patches is not automatically a ceiling. A ceiling is a thing the vendor will not let you do.
• What does the next three years of the business actually need, and who will run it? Bemeir ships both Adobe Commerce and Shopify Plus. Their decision order is business roadmap, team shape, operational complexity, then budget. A team built around Magento expertise should not throw that away because a demo was prettier. A team that does not want to run servers, patches and deployments is looking at a different problem than "the theme is old".

Shopify also says staying on the wrong platform can be as costly as moving. That is the counter-view, and it is real. The constraint test exists so you can tell the difference between that case and the more common one, which is an unmaintained store with a rebuild brochure on the table.

Bemeir's own pattern, from their work, not from a published sample: roughly 40 percent of Magento merchants who evaluate Shopify Plus are better served by migrating, roughly 40 percent by staying (often with a Hyvä frontend), and roughly 20 percent sit in an ambiguous zone where a short discovery is cheaper than the wrong five-year bet. Treat those shares as one agency's experience.

You are not buying a licence

A rebuild quote is mostly not the platform. Elogic's Replatforming Cost Index 2026 (published 16 June 2026, updated 3 September 2026) puts the platform licence at 20 to 40 percent of total spend. Implementation, ERP integration and data migration drive the rest. Their mid-market all-in figure is $150,000 to $300,000 over 5 to 10 months. Those dollars are an agency index, not a UK survey. Use them as composition, not as your purchase order.

The UK ranges, by store complexity, are in the cost article this piece pairs with. What you need here is the reasoning that article is built on: you are comparing how much data and integration work each bidder has actually scoped. The monthly Shopify Plus or Adobe licence is the line everyone can see. It is not where a replatform budget goes.

Two costs that still hide after that:

• Dual-running. Elogic lists parallel-run licence overlap of 4 to 12 weeks, paying for old and new at once.
• Internal time. Their index puts the gap between quoted price and invoice as predictable, and names internal team time as one of the costs most often absent from scoping.

A repair slice that hits the actual constraint (frontend, hosting, data cleanup, redirect map) is the same class of work a migration would do, without throwing away the catalogue model, the ERP mapping and the URL inventory you already have. If a rebuild quote cannot show those lines separately, it is not finished. If a repair quote cannot show them either, that is not finished either.

A rebuild is an SEO event even on the same domain

You do not need a new domain for Google to treat this as a site move. Google's Search Central documentation on site moves lists URL path changes in the same class as HTTP to HTTPS and domain changes: example.com/page.php?id=1 to example.com/widget is a move.

What Google says will happen, in their words: "Expect temporary fluctuation in site ranking during the move." For medium-sized sites it can take a few weeks or more for new URLs to replace old ones in results. Larger sites take longer. The speed depends on how many URLs you have and how fast the server responds.

Permanent server-side redirects are the mechanism. Google recommends HTTP 301 or 308 when a URL has permanently moved, and states that 301 and other permanent redirects do not cause a loss in PageRank. That is not the same as "SEO is safe". The redirect does not burn link credit. Bad mapping, redirect chains, homepage dumps and blocked crawls do the damage.

Keep the redirects in place. Google: "Keep the redirects for as long as possible, generally at least 1 year." That window is so they can recrawl and reassign links on other sites that still point at the old URLs. From a user's point of view they suggest keeping them indefinitely, then updating your own high-volume links so people are not bounced through a hop forever.

Repair, done properly, keeps the URLs. Rebuild, on a new platform, usually does not. Magento catalog paths and Shopify collection paths are different URL patterns. Every product, category and content URL needs a 1:1 map, or a parent-category fallback, or a deliberate 404. A blanket redirect to the homepage is the cheap version of this job. Google's own troubleshooting table keeps seeing incorrect redirects to non-existent URLs, leftover noindex, sitemaps that still list the old paths, and a new origin that cannot absorb the crawl spike.

A repair that leaves URLs alone is not conservative. It is refusing to donate a few weeks of ranking noise to a project that has not named its ceiling.

The in-place repairs that look like a new shop

Three repairs get sold as "we need a new platform" because they change what the customer sees.

Frontend. Hyvä is a replacement Magento storefront, not a migration. Nordic Web Team, a Hyvä agency: "You are not migrating to a new platform. You are modernising the frontend layer of your existing Magento store." Catalogue, admin, APIs and integrations stay. Their typical figures: a Luma storefront loads between 2 and 8 MB of JavaScript; a Hyvä storefront typically loads under 300 KB. That is an agency range, not a Hyvä lab number, and it is still the right shape of the problem. You do not need a new order database to stop shipping megabytes of Knockout and RequireJS to a phone.

Hyvä's own docs treat Core Web Vitals as field metrics of how the storefront feels: LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds. The INP killer they name on Magento storefronts is heavy main-thread JavaScript, especially third-party tags loaded in the head. Chat, analytics, cookie banners, autocomplete. A Plus rebuild that copies the same tag manager into a new theme will fail the same way.

Hosting and version debt. Elogic's in-place path is Adobe Commerce on Cloud (or ACCS) when the problem is DevOps burden, and a current supported Magento version when the problem is "we are three versions behind on undersized hardware". Many "Magento is dead" conversations are that sentence with the dates filed off.

Shopify analogue, same idea: a theme rebuild, an app cull, and deferred tags. Not a Plus contract.

None of this is free. A Hyvä project is still weeks of agency time. It is not a 5 to 10 month data migration with a year of redirects.

When rebuild is the honest call

Sometimes the constraint test fails, and the honest job is a rebuild. Name it.

Shopify's leave-list, again: a hard ceiling the current platform will not open, workarounds that now cost more each year than a move, a vendor that has stopped building what you need, or a composable/headless requirement the monolith cannot offer.

Bemeir's migrate-list is more specific, and useful even if you never speak to them. Shopify Plus tends to fit B2C merchants under $30 million GMV with light customisation; DTC brands whose advantage is marketing operations rather than commerce-platform depth; teams that do not want to employ Magento engineers; Magento implementations so indebted that an Adobe rebuild would cost nearly as much as leaving; businesses that used to need Magento complexity and no longer do.

Their stay-list is the mirror: complex B2B pricing and account hierarchies; deep ERP integration under real-time load; catalogues above 50,000 SKUs with heavy attributes; a strong internal Magento team you intend to keep; customisations that are actual business logic, not cosmetics.

Elogic will still send a merchant to Shopify Plus when Magento's complexity is overhead they do not use: a lean team, primarily DTC, simpler catalogue and pricing. They will tell a manufacturer with quote-to-order and contract-price tiers to stay. Both can be right. The platform war is not your problem. Fit is.

If the rebuild is the call, treat SEO as a workstream with a URL map, not a launch-week checklist. Price data migration as a line, not an export. Read the cost article before you sign anything that looks cheap against those ranges.

The field checks you run before you sign anything

Do these on the current store. They are cheaper than a wrong five-year platform.

• Export the URL inventory Google actually knows: sitemap, crawl, Search Console pages, backlinks. If you cannot list the URLs that make money, you cannot price a move.
• Look at CrUX / Search Console Core Web Vitals, not just a Lighthouse screenshot from a quiet evening. Hyvä's docs start there for a reason: field data tells you which metric to fix.
• Write the ceiling in one sentence. "We cannot do X on this platform, and here is the vendor or architectural reason." If the sentence is "it feels old", that is not a ceiling.
• Price a repair slice that attacks that sentence (frontend, hosting, data, redirects) against a rebuild slice that includes URL mapping, dual-running and internal time. Same person should not sell both without showing both numbers.
• Ask whether URLs must change. If they must not, you are looking at a repair or an in-place modernisation. If they must, you are accepting Google's weeks of fluctuation on purpose.

If the repair slice is cheaper and hits the constraint, that is the work. If it cannot hit the constraint, you have a rebuild brief. Either way you have stopped buying a feeling.

What to bring to an audit or a build call

Bring the constraint-test answers, the Search Console URL list, the Core Web Vitals report, and the quote you already have. I will say which work is a repair and which is a rebuild. If I am not the person for it, I will say that too.

The close on this piece is a decision, not a platform. Book a free call when you want that read, not when you want a demo of a stack you have not tested against the ceiling.