A cloud decommission notice lands in an engineering channel, and a platform review deferred for two years becomes a program with a hard deadline. The decision that accounts for most of the cost is whether to replace the commerce backend or keep it and rebuild only the storefront, and it gets made before anyone measures where the bottleneck lives. What follows covers the forcing functions, that fork, and the data and SEO mechanics behind most overruns.
Key takeaways:
Vendor deadlines and deprecations are what put replatforming on the calendar, but slow pages are the trigger teams most often misread as a backend problem.
Field data puts the platform gap in Largest Contentful Paint rather than backend response time, and the frontend controls it.
Turning the existing platform into an API layer and rebuilding only the storefront cuts what has to migrate, in exchange for running two systems side by side.
Data migration eats 30% to 40% of the budget, and customer passwords are the one record type that can't be migrated at all.
The redirect map has to be built before cutover and ordered by traffic, since a map that lands afterward is recovering rankings instead of protecting them.
Copy link to headingWhat is ecommerce replatforming?
Ecommerce replatforming is the migration of a store's commerce stack to a different platform, a different architecture, or both. A move from Adobe Commerce to Shopify changes the platform. Changing the architecture can leave the platform exactly where it is.
Scoping turns on which tiers move, and there are only three answers. A full suite replacement moves both the backend and the storefront. Frontend decoupling moves only the storefront and keeps the existing backend in place behind an application programming interface (API). A redesign moves neither, since new templates and styling don't touch data models, URL structures, or integrations.
Copy link to headingThe three scopes cost and roll back differently
Confusing a redesign with frontend decoupling is how a redesign budget ends up attached to a migration timeline. The differences sit in what has to move underneath the site:
The rollback row is the one that changes how a program gets run. A redesign and a decoupled frontend both have a reversible unit of work, while a full suite replacement executed as a single cutover does not.
Copy link to headingWhat forces an ecommerce replatforming decision?
Replatforming rarely starts as a technology preference. Vendor deadlines with enforcement behind them, pricing that scales with revenue, deprecations that freeze working code, and performance ceilings all arrive on someone else's schedule.
Copy link to headingAdobe Commerce enforcement escalates from suspension to deletion
Missing an Adobe Commerce upgrade deadline takes the storefront offline. Environments on 2.4.4 or 2.4.5 have until June 1, 2027, and 2.4.6 and 2.4.7 until June 1, 2028. A typical lifecycle policy would stop at withdrawing support, while Adobe suspends inbound traffic and can go on to terminate cloud services and permanently delete every instance, environment, and branch.
The driver is runtime compliance rather than commercial pressure. Adobe Commerce 2.4.7 runs on PHP 8.2, and PHP 8.2 support ends December 31, 2026, after which the PHP project ships no further security patches. A payment-handling store on an end-of-life runtime is a Payment Card Industry (PCI) problem, and Adobe owns PCI compliance for infrastructure it hosts. Self-hosted stores keep running past these dates but carry that exposure alone.
Copy link to headingThe OCAPI deprecation sets a harder clock than Salesforce pricing
The Open Commerce API (OCAPI) was deprecated in April 2026, its documentation now carries a deprecated label on every page, and new platform features land exclusively in the Salesforce Commerce API. Salesforce is also directing storefront investment toward Composable Storefront rather than the Storefront Reference Architecture (SFRA), so for a retailer still on SiteGenesis, another cycle spent on SFRA buys little runway.
Pricing compounds the timing. Salesforce Commerce Cloud has historically used gross-merchandise-value pricing, which turns every growth milestone into a pricing event, and third-party estimates put implementation cost between $200,000 and $500,000. Salesforce doesn't publish official figures, so treat any specific number as an estimate rather than a quote.
Copy link to headingThe Shopify Scripts deadline has already passed
Rebuilding custom Ruby discount logic as Shopify Functions is unavoidable work, so the only open question is whether it lands inside a broader migration or as a standalone patch. Editing and publishing Scripts stopped on April 15, 2026, and all Scripts ceased executing on June 30, 2026, which puts affected Shopify Plus merchants past both dates. The April date carried the operational risk rather than the June one, because between them every running Script was frozen code with no repair path.
Copy link to headingCore Web Vitals point at the frontend rather than the platform
A slow store is the weakest evidence for replacing a commerce backend. The spread comes from Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS). On desktop, Shopify origins record good LCP on 92% of pages against 59% for Adobe Commerce and 45% for WooCommerce, and on mobile the same ordering holds at 86%, 52%, and 39%. Overall desktop pass rates land at 76%, 36%, and 33%.
Both LCP and CLS are functions of what the presentation tier ships, how it loads, and how it reserves space before render. Client-side personalization is the mechanism behind much of it, because it forces every page load to pay for duplicate downloads and deferred rendering, a documented failure mode in Salesforce Commerce Cloud migrations. None of this argues that backend constraints are imaginary. It argues that page speed alone won't tell you where the constraint sits.
Copy link to headingThe ecommerce replatforming fork between suite replacement and frontend decoupling
The answer to one question sets the scope of everything that follows. A constraint in the commerce backend makes this a suite replacement, while a constraint in the presentation tier makes it a storefront project over a backend that stays put. Choosing the storefront project doesn't foreclose the other one, since replacing the backend later still requires API adapter work but not a second full rebuild.
Copy link to headingFrontend decoupling keeps the commerce layer in place
The pattern has two published precedents. Ruggable kept Shopify as its commerce backbone, replaced only the frontend, and recorded a 75% improvement in search rankings, 40% faster site speed, and a 300% increase in unbranded search clicks. Whop ran the same play against a Ruby on Rails monolith, splitting the stack so Next.js served the frontend while the existing Rails API handled the backend. The migration took three months and lifted the share of URLs with good Core Web Vitals from 13% to 47%.
Decoupling carries a real cost. Two systems run in parallel for the duration, which means two deployment pipelines, two sets of monitoring, and a stretch of paying for both.
Copy link to headingAdobe's managed path still requires a new frontend
Staying with the incumbent vendor doesn't sidestep the fork. Adobe Commerce as a Cloud Service doesn't support Luma storefronts, and its Commerce Storefront runs on Edge Delivery Services as a fully headless layer over a GraphQL API, so teams taking Adobe's fully managed path still run a frontend project.
Copy link to headingThe routing layer is production infrastructure from day one
The sequencing pattern underneath these migrations is the strangler fig pattern, where a routing layer hands each request to whichever system owns that path until the legacy system serves nothing. Planning documents tend to treat that layer as temporary scaffolding, then discover it owns every request in the system, including checkout. It needs the same monitoring, rollback, and on-call coverage as the storefront itself, which is how Vercel adopted microfrontends internally.
Copy link to headingWhere ecommerce replatforming estimates go wrong
Most estimates cover the license and the build, then omit integration work, data migration, and search engine optimization (SEO) recovery. The platform license is typically 20% to 40% of total spend, which means the majority of the budget sits in line items that rarely appear in the initial proposal. Among digital commerce leaders surveyed in 2023, timeline overruns affected 77% of projects.
Copy link to headingThe feature-parity trap adds timeline before it adds cost
Parity gets scoped against the feature list rather than against usage, so the team rebuilds functionality that has no active users. Industry estimates put the share of unused existing features at 30% to 50% and the added timeline at four to six months. Parity scope has to come down before the estimate is signed, because renegotiating after the timeline slips means cutting features the team has already partially built.
Copy link to headingPublished cost ranges disagree enough to be read as bands
Estimates vary by market and by agency, so the figures below are order-of-magnitude rather than quotes:
Only the last of these changes risk rather than cost, because it puts working software in production while the rest of the program is still in flight. The instructive failure at the far end of the scale is Lidl's SAP program, abandoned after seven years and an estimated €500 million, with the company reverting to its legacy system. Lidl's program was enterprise resource planning rather than commerce, but the mechanism transfers directly, since a big-bang project accumulates all of its risk at a single moment while an incremental migration contains errors to individual routes.
Copy link to headingData and URL failures in an ecommerce replatforming
Data migration alone consumes 30% to 40% of a replatforming budget and timeline. Customer records and URL structures are where that time goes, and both fail in ways that only show up after cutover.
Copy link to headingPassword hashes don't transfer between platforms
Adobe Commerce and Shopify use incompatible password hashing schemes, SHA-256 and bcrypt respectively, and Shopify blocks imported hashes from Adobe Commerce, WooCommerce, and custom builds. Names, email addresses, shipping and billing addresses, order references, and account creation dates all transfer. Credentials never do.
Two approaches handle the gap, and they fail differently. Branded account activation emails go out 24 to 48 hours after cutover rather than at go-live, which keeps password resets out of the launch-day support queue. The cost is an explicit reset step for every shopper. Lazy migration instead imports the legacy hashes and upgrades each password on first successful login, verifying against the old scheme once. Shoppers notice nothing, but the target platform has to support running the legacy hash function, which rules the approach out on most software-as-a-service platforms.
Copy link to headingOrder history and product options hit hard platform limits
Shopify has no native order import for spreadsheets, so historical orders move through the Admin API or a third-party tool, and imported orders carry functional limits because they can't trigger fulfillment, print labels, or process refunds through Shopify Payments. The Admin GraphQL API adds a scoping constraint on top of that. By default, only the last 60 days of orders are accessible from the Order object. Reading further back requires the read_all_orders scope, which Shopify grants based on demonstrated need, so that request goes in before the migration window rather than during it. A practical scope is to migrate only orders still inside the return window and push older records to a reporting system, since those records need to be queryable rather than operable.
Product structure carries its own ceiling. Shopify raised the variant cap to 2,048 per product for all merchants, but the separate cap on options per product is what breaks catalogs, and it is exposed as maxProductOptions rather than fixed across every store. Query that limit against the destination store before migration starts, because apparel, footwear, and configurable goods routinely carry more option dimensions than it allows. Promotions and discount logic have no automated transfer path at all, so discount rules get rebuilt every time.
Copy link to headingRedirect coverage decides how fast rankings recover
The map gets built during planning rather than during launch week, and it has to cover every product, category, and content management system page whose address changes, ordered by traffic and ranking contribution rather than by page count. Every URL left unmapped at cutover starts shedding the rankings it had.
URL-changing site moves have documented mechanics, including keeping redirects live for at least a year. Both 301 and 308 count as permanent, and both sitemaps go up at once, one for old URLs and one for new. Reports and warnings referencing old URLs persist until Google recrawls them, which is normal rather than a signal that something broke.
Recovery timelines vary enough that any single number misleads, since they depend on domain authority, implementation quality, and how recovery gets measured. Well-executed migrations recover in 30 to 60 days, while poorly managed ones can cost 20% to 40% of organic traffic, and redirect completeness and crawl capacity at launch separate the two outcomes.
Copy link to headingHow Vercel supports the frontend layer in an ecommerce replatforming
A decoupled storefront needs somewhere to run that can also route traffic between old and new. The commerce backend stays wherever it already is. Next.js is first-party here, though Nuxt, SvelteKit, Astro, and other frameworks deploy through the same workflow.
Copy link to headingRoute traffic path by path instead of by cutover date
In an incremental migration, Vercel becomes the entry point for production traffic while everything initially rewrites to the legacy origin, and as each path migrates, its rewrite is removed so Vercel serves that path directly. Rewrites are limited to 2,048 routes per deployment, and beyond that, the routing table moves into custom Routing Middleware. Storing the routing rules in Global Config rather than in the deployment means rewrite changes ship without a redeploy, and a broken path can be routed back to the legacy origin from the dashboard.
Helly Hansen migrated this way from an Adobe Commerce progressive web app, starting with checkout, and finished global rollout in under six months with zero downtime and Black Friday Cyber Monday up 80% year over year. A global sportswear retailer leaving Salesforce Commerce Cloud began with its homepage as an isolated test, accelerated once A/B testing against the incumbent came back positive, and added product detail and listing pages within two months, closing the holiday weekend at $48 million against $38 million the year before.
Copy link to headingKeep a large catalog fresh without full rebuilds
Product and content pages change constantly on a large catalog, which rules out a full rebuild per edit. Incremental Static Regeneration (ISR) refreshes those pages in the background while the cached version keeps serving, and the tuning cost is deciding how stale each route is allowed to get. During Black Friday Cyber Monday 2025, ISR processed more than 1.8 billion reads and 1.5 billion writes across Vercel's network, which handled 115.8 billion total requests at 33.6% year-over-year growth.
Catalogs too large to prerender at build time have a second option in Next.js 16. Partial Prerendering, now enabled through the cacheComponents configuration, serves a static shell while streaming dynamic portions in the same request, and the Cache Components guide covers how URLs omitted from generateStaticParams still serve an instant shell to the first visitor. For a catalog where prerendering every product page is impractical, that removes the tradeoff between build time and first-visit speed.
Copy link to headingShip storefront sections independently once teams multiply
A single deployable storefront eventually drags every contributing team down to the slowest release cadence, which is the coordination cost that shows up once a migration succeeds and more teams start shipping into it. Microfrontends, generally available since October 2025, split one application into independently deployable units that render as one storefront, with Vercel handling routing across its network. A companion guide covers using them as the migration mechanism itself.
Copy link to headingPreserve analytics and attribution through the cutover
Analytics continuity is an underestimated line item in a headless migration, because the storefront moves while checkout doesn't. A headless Shopify storefront runs on your own domain while Shopify continues to control checkout and other Shopify-managed pages, which splits the session across two properties. Restoring headless Shopify analytics means emitting your own page-view and add-to-cart events and forwarding Shopify's cookies on cart mutations.
Performance measurement needs the same treatment, since the LCP and CLS numbers that justified the migration have to be observable afterward to prove it worked. Speed Insights reports Core Web Vitals from real user devices and lets you filter by route, so a path-by-path migration gets measured the same way. Pairing that with deployment checks validates each slice before its traffic shifts.
Copy link to headingLocate the constraint before you replace the platform
The expensive version of this project replaces a commerce backend to fix pages that render slowly. Nine months go into migrating customer records, order history, and URL structures, and the rendering path that made the store slow is still there at the end of it. Locating the constraint before selecting a vendor keeps this a scoped migration instead of a multi-year program.
Where the constraint sits in the backend, through data model limits, checkout logic, or licensing, a suite migration is the correct call. Where it's rendering, personalization, or content velocity, the answer is a new presentation layer over the backend already running.
For the frontend half of that decision, Vercel provides the delivery layer:
Incremental migration: Move one path at a time with the legacy system live behind Vercel, so no single date carries the whole migration.
Routing Middleware and Global Config: Change routing without shipping a deployment, and reverse a bad path from the dashboard.
Incremental Static Regeneration: Keep catalog pages current without rebuilding the site for every edit.
Microfrontends: Let each team release on its own cadence under one domain.
Speed Insights: Confirm from real user devices that the migration did what it was scoped to do.
Start a new project to stand up the routing layer and migrate your first path, or browse vercel.com/templates for a commerce storefront foundation to build from.
Copy link to headingFrequently asked questions about ecommerce replatforming
Copy link to headingHow long does ecommerce replatforming take?
It depends on scope. The median mid-market replatform runs 5 to 10 months all in, enterprise B2B migrations with enterprise resource planning and order management dependencies run 6 to 12 months or more, and a headless storefront refresh runs 3 to 6 months when the first release stays narrow.
Copy link to headingCan I keep my Salesforce Commerce Cloud or Adobe Commerce backend when going headless?
Yes, and it's the more common route. Ruggable did it on Shopify and Whop did it over an existing Rails API, both keeping the commerce layer untouched. What the backend has to offer is a usable API, which is where older SiteGenesis and Luma installs need work before a storefront project can start.
Copy link to headingWhat happens to SEO rankings during a replatform?
Rankings dip and then recover, with the depth of the dip set by redirect coverage rather than by the platform chosen. Expect several weeks of fluctuation while Google recrawls, and treat old-URL warnings in Search Console as normal during that window rather than as a fault to chase.
Copy link to headingDo customer passwords transfer to the new platform?
No. Credentials are the one record type that never survives a platform move, though names, addresses, and order references do. Decide early whether shoppers get an activation email or a silent upgrade on next login, because that choice changes launch-day support load and has to be built before cutover.