Most Magento to Shopify migration estimates get built around catalog size. SKU count is the one variable migration tooling already handles well, which makes it close to the least useful number in the scope.
The two workstreams that actually set the timeline don't scale with catalog size at all. Custom PHP modules can't run on Shopify at all, and a decade of Magento URLs has nowhere clean to land. Both tend to get a single bullet.
This guide covers what maps cleanly, what has to be rebuilt against Shopify's extension surface, and when staying on Adobe Commerce is the correct call.
Key takeaways:
Custom extensions decide the timeline, not catalog size. Magento modules run as PHP inside the application itself, and Shopify's extension model has nowhere to run them, so every module gets rebuilt, swapped for an app, or retired.
Remapping Magento's custom product attributes is usually the longest task in the project. Magento holds them in an entity-attribute-value (EAV) model with no practical ceiling, and each one needs a matching Shopify metafield chosen by hand.
Shopify's import limits change what the migrated store can represent. A product supports only three options, such as size and color; customer passwords can't be imported at all, and historical orders arrive read-only and can't be refunded.
Redirect gaps are the most commonly documented cause of lost organic traffic after a migration. Shopify matches redirects by path only and hard-codes its URL prefixes, so a mature Magento store's filter and category URLs have no valid target to point at.
Rebuilding the storefront is a separate project from moving the commerce backend, and it belongs second. The case for a headless frontend is experiment throughput rather than page speed, since a well-built Shopify theme already performs well.
Copy link to headingWhat is a Magento to Shopify migration?
A Magento to Shopify migration is the replatforming of a Magento Open Source or Adobe Commerce store onto Shopify or Shopify Plus. It moves catalog, customer, and order data onto a hosted platform, and it rebuilds every customization that previously lived inside Magento's PHP application layer.
Rebuilding those customizations is the part that makes this different from changing themes. Magento is a self-hosted PHP that a team can modify anywhere in the request path, so business logic ends up spread across plugins, observers, and overrides. Shopify runs custom logic only through a fixed set of sandboxed extension points, so every Magento customization needs a decision about where it goes rather than a straight port. That sandbox is the deliberate trade, and it's what lets Shopify own the hosting, patching, and PCI scope that a Magento team currently carries itself.
Copy link to headingMagento hands you the whole application, Shopify hands you fixed surfaces
Those extension points come with published limits, and the size of a migration depends on how many of them the current Magento store already exceeds. The dimensions that decide most estimates:
The scope of a migration is the list of Shopify limits that the current store already exceeds. Everything on that list is rebuild work rather than data movement.
Copy link to headingWho should migrate from Magento to Shopify
Two groups are migrating on someone else's schedule rather than by choice, and they're on very different clocks. The first is Magento 1, which Adobe stopped patching in June 2020. Stores still running it take card payments on software that receives no security fixes, and Payment Card Industry (PCI) rules require vendor security patches to be installed, so those stores are leaning on compensating controls rather than on the platform itself. For them, the question is when, not whether.
Adobe Commerce merchants face a slower squeeze from three directions. Regular support for 2.4.4 ended in April 2025 and for 2.4.5 in August 2025, with extended and security-only windows closing between 2026 and 2028. MySQL 8.0 reached the end of support on April 30, 2026, which pushes on-premises merchants running 2.4.4 through 2.4.7 into a database migration, whichever platform they land on. And Adobe Commerce as a Cloud Service, Adobe's own hosted successor, is multi-tenant software as a service with no PHP inside the application, so moving there means rebuilding in-process customizations too. Once that rebuild is on the table, the platform question is open again.
Copy link to headingCustom extensions are the largest cost in a Magento to Shopify migration
Extensions are how a Magento store becomes what the business actually needs. Anything the core platform doesn't do gets added as a module, and because Magento is self-hosted PHP, those modules run inside the application rather than alongside it. A module can intercept a price calculation, rewrite a checkout step, or add its own database tables. Shopify offers bounded equivalents for some of that, but only through its sandboxed extension model, never as code running inside the platform.
A store that's been live for a decade carries dozens of them, built on plugins, event observers, and dependency injection. Some have a direct replacement in the Shopify App Store. The rest get rebuilt against Shopify's extension surface or retired, and working out which is which is discovery work that has to finish before a timeline means anything.
Copy link to headingEvery Magento mechanism maps to a Shopify equivalent with a limit attached
The limits come in two kinds: a hard technical cap or a Shopify Plus requirement, and the second kind is the one that reshapes budgets:
Any plan can install public App Store apps built on Functions. Replacing bespoke Magento logic usually means building a custom Function app instead, and that needs Shopify Plus.
Copy link to headingCustom product attributes take the longest to remap
Magento's EAV model lets a merchant add attributes indefinitely, and stores that have run for a decade have usually done so. Those attributes carry into Shopify as metafields and metaobjects, which means deciding the target type, namespace, and key for each one, then rewriting anything that reads the old attribute.
Estimates that fold this into the product import are the ones that overrun, because the work scales with attribute count rather than product count. A small catalog carrying a decade of custom attributes is a bigger job than a large catalog with few.
Copy link to headingDiscount and pricing rules become developer work
Magento's cart and catalog price rules are admin configuration. A merchandiser builds a promotion in the backend without involving engineering. On Shopify, the same logic runs as Shopify Functions, written in languages that compile to WebAssembly, such as Rust, which moves promotions from a configuration task to a code change with a deploy behind it.
There's no lighter path to fall back on, since Shopify retired its older Scripts system in 2026. Order Discount Functions also operate on original prices only, so a stacked B2B pricing matrix that Magento evaluated as a chain has to be reimplemented as a single function.
Copy link to headingMagento to Shopify data migration for catalog, customers, and orders
With extension triage settled, the data move is the automated part of the project. Shopify's required import order puts Products first and Customers second, with historical Orders last, and each entity carries limits that shape what the target store can represent.
Copy link to headingProducts import cleanly until one needs a fourth option
Shopify's variant ceiling is generous. The option cap is three per product, and that's the one that breaks catalogs. A configurable product built on four or more attributes can't land as a single Shopify product. The options are a reduced attribute set, a split into linked products, or a third-party options app. Field mapping itself is mechanical for the core attributes:
Beyond those, Matrixify creates collections and category-URL redirects during product import, which is worth configuring before the run rather than rebuilding after it. CSV imports cap at 15 MB, so large catalogs get split or moved through the GraphQL Bulk Operations application programming interface (API).
Copy link to headingCustomer passwords don't transfer, and no longer need to
Shopify's customer import can't accept credentials encrypted outside the platform, which historically forced a reset on every account before anyone could log in.
The current account model removes that problem. Shopify deprecated legacy accounts in February 2026, and stores now sign customers in with a one-time email code rather than a stored password, so a store migrating today has nothing to reset. Stores still running legacy accounts should bulk-send activation emails immediately after import rather than letting customers discover the change at checkout.
Copy link to headingOrders import read-only, which decides what's worth bringing
Shopify admin has no native bulk order CSV import. Historical orders come in through a migration app or the GraphQL orderCreate mutation, and the original created_at timestamp can't be preserved, so migration tools store it in processed_at instead. Imported orders land read-only and can't be re-fulfilled or refunded through standard flows. Before running the import, turn off automatic fulfillment under Settings → General → Order processing, or every historical order fires a fulfillment notification.
Those two constraints settle the bring-versus-archive question. Orders worth importing are the ones that give an account page its history and feed cohort analytics. Orders imported so support can refund against them aren't worth it, because that path doesn't exist on the target platform.
Copy link to headingMagento to Shopify migrations lose organic traffic to redirect gaps
Products, customers, and orders can all land correctly and the project can still fail on organic traffic. Across a study of 171 migrations, average recovery to pre-migration traffic took 229 days, and 42% never returned to their previous levels. Redirect gaps are the most commonly documented cause.
Copy link to headingShopify hard-codes the URL prefixes Magento let you configure
Magento allows configurable suffixes such as .html and full URL rewrite management, so a mature store's indexed URL space reflects a decade of decisions. Shopify hard-codes the /products/, /collections/, /blogs/blog-name/, and /pages/ prefixes with no .htaccess or rewrite access to change the URL structure. Every indexed Magento URL needs a 301 to a path shape it was never designed for.
Redirect capacity is 100,000 on standard plans and 20 million on Plus, which covers most catalogs. Capacity isn't the constraint. Some Magento URLs have no valid target at any volume.
Copy link to headingSome Magento URLs have no valid redirect target
Three categories resist mapping entirely, and each one is common on a mature Magento storefront:
Query-string filter URLs: Paths like
?color=red&size=Mcan't be cleanly redirected, because Shopify matches redirects by path only and passes query parameters through untouched.Layered navigation paths: Magento URLs, such as
/women-tops/l/brand:nike/color:black.htmlencode facet state in the path itself, and Shopify has no structural equivalent to receive them.Collection tag URLs: Shopify will not redirect
/collections/collection-name/tag-namepaths, including in cases where that pattern is the destination a team wants.
These need triage rather than mapping, since no Shopify destination preserves what the URL was doing. The decision for each one is whether it carries enough traffic to justify building a collection specifically to receive it.
Copy link to headingShopify canonicalizes duplicate product URLs, but redirects fire only after a 404
Every product in a collection is reachable at two URLs, /products/product-name and /collections/collection-name/products/product-name. Shopify resolves this on its own, injecting a canonical tag that points the collection-aware path back to the clean product URL. The risk during a migration is internal links, since anything pointing at the collection-aware path is signaling a page Shopify has already told search engines to ignore.
A Shopify redirect also fires only when the source URL returns a 404, so the old collection or product has to be deleted before its redirect does anything. Redirects staged ahead of deletion sit inert until the source is removed, which is a failure mode that only shows up in logs after launch.
Copy link to headingThe redirect map has to come from a crawl, not the sitemap
A sitemap lists what a store intends to expose. A crawl lists what search engines actually indexed, including the filter and facet URLs that carry rankings and never appear in a sitemap. Priority follows organic revenue; low-value filter URLs can stay unmapped on non-Plus plans, and the map needs a single owner.
Done in that order, a post-launch dip recovers within a quarter instead of landing in the 42%.
Copy link to headingWhen not to migrate from Magento to Shopify
Shopify's ceilings are published, which makes this a threshold test rather than a judgment call. For a store sitting above the limits below, the honest answer is to stay on Adobe Commerce, or at a minimum to price the full rebuild before committing to a date. A migration that ships less functionality than the store had is a failed migration, even when every record lands correctly.
Copy link to headingQuote negotiation workflows don't survive the move
Shopify Plus handles company profiles, per-company catalogs, and payment terms natively, which covers most of what a wholesale operation needs. Negotiation is the gap. Adobe Commerce ships negotiable quotes and requisition lists as native B2B features, where Shopify's request-for-quote flow runs through draft orders, a manual path with no versioning and no negotiation history.
Basic, Grow, and Advanced stores can use companies, net terms, quantity rules, volume pricing, quick-order lists, and up to three active B2B market catalogs. Shopify Plus adds unlimited catalogs, direct company-level catalog assignment, deposits, and partial payments.
Copy link to headingMulti-store operations past ten storefronts lose the single-codebase advantage
Adobe Commerce nests websites, stores, and store views with no documented ceiling, all carrying per-scope configuration overrides inside one codebase. The Shopify Plus expansion-store model tops out at ten included stores, with any beyond that added individually.
Past that ceiling, configurations that live in one Magento codebase become configurations maintained separately per store, and the divergence compounds with every market added. A retailer running well beyond ten storefronts with materially different setups per market should stay put, because that cost lands on the team every day rather than once during the migration.
Copy link to headingStacked promotional rules hit the Functions output cap
Checkout UI extensions for the Information, Shipping, and Payment steps are Plus-only. The function type for modifying carts is limited to one per store, so promotional rules Magento evaluated together have to be consolidated into a single function.
The 20 kB output cap has produced OutputTooLargeError at roughly 125 line items, which rules out bulk price changes across large carts. A Magento checkout that regularly handles carts near that size, or that depends on promotional rules evaluated as a stack, will ship degraded on Shopify. That's a reason not to move rather than a line item to scope.
Copy link to headingHow Vercel supports a Magento to Shopify migration at the storefront layer
The storefront question sits after the commerce backend is stable. Going headless in the same cutover doubles the variable count while redirects and data parity still need undivided attention, and it makes post-launch traffic changes impossible to attribute.
Copy link to headingMigrate route by route, and justify it on test velocity
Well-built Liquid storefronts perform competitively on Core Web Vitals, so page speed on its own is a weak justification for a frontend rebuild. Experimentation throughput is the case that holds up, and proving it works better in stages than in one cutover.
Helly Hansen moved off an Adobe Commerce progressive web app with an incremental migration that started at checkout rather than the homepage, reaching global rollout in under six months. They went from one A/B test per month to five or six per sprint after adopting server-side testing with feature flags. After PAIGE consolidated onto Shopify, Next.js, and Vercel, the company grew Black Friday revenue 22% and increased conversion rates 76%.
Copy link to headingServe product pages from cache and assign variants before render
Catalog data changes constantly, which pushes teams toward rendering every product page on request and paying the latency. Client-side testing then adds layout shift on exactly the pages where conversion is most sensitive.
A Next.js storefront fetches through the Shopify Storefront API over GraphQL and revalidates Incremental Static Regeneration caches on demand from webhooks such as products/update, so pages serve from the CDN until Shopify says the data changed. Partial Prerendering, stable in Next.js 16 through the cacheComponents config, streams the static shell while personalized content resolves and variants are assigned before render. Our guide to deploying a headless Shopify storefront covers the wiring.
Copy link to headingBuild on Hydrogen without runtime lock-in
Committing to a headless framework has historically meant committing to its runtime, which is a real objection for a team that has already been burned by platform lock-in on Magento.
On June 30, 2026, we announced with Shopify that we are rebuilding Hydrogen as open source and runtime-agnostic, so it runs anywhere JavaScript does. Teams can build with Next.js, Nuxt, Svelte, or a custom framework, and the core, client, and server layers ship as shared packages rather than as a proprietary stack.
Copy link to headingStabilize the backend first, then rebuild the storefront
Replatform failures trace to implementation rather than to platform limitations. Redirect planning and extension discovery decide the outcome, and both are workstreams that need an owner and a schedule before the catalog line item gets its budget. Stabilize the commerce backend first and the storefront becomes a separate engineering conversation about testing velocity and frontend autonomy, measured against a baseline that hasn't moved underneath you.
Here's how Vercel supports the storefront layer once the backend move is complete:
Incremental migration paths: Route-by-route adoption lets a team prove value on checkout or product pages first, rather than staking the replatform on one cutover.
Cached product pages with server-side experimentation: Incremental Static Regeneration refreshes from Shopify webhooks, and Vercel Flags assigns variants before render rather than in the browser.
Hydrogen, rebuilt open source and runtime-agnostic: Shared core, client, and server layers work with Next.js, Nuxt, Svelte, or a custom framework, without committing the storefront to a single runtime.
Start a new project at vercel.com/new, or browse vercel.com/templates for Shopify storefront starters already wired to the Storefront API.
Copy link to headingFrequently asked questions about Magento to Shopify migration
Copy link to headingHow long does a Magento to Shopify migration take?
A Shopify Plus migration typically takes 3 to 4 months, and attribute remapping dominates that window. B2B builds with complex pricing logic or enterprise resource planning (ERP) integrations run 8 to 14 months. Overruns usually trace to extension discovery that started after the timeline was already committed.
Copy link to headingCan customer passwords be migrated from Magento to Shopify?
No. Shopify can't accept passwords encrypted outside its system. A store migrating today lands on the current account model, which signs customers in with a one-time email code, so there's nothing to reset. Stores still running legacy accounts face a sunset date Shopify will announce during 2026, which makes the import a sensible moment to move.
Copy link to headingWhat replaces Magento's cart price rules and catalog price rules on Shopify?
Shopify Functions, which are compiled code rather than admin configuration. The bigger shift is organizational. A promotion a merchandiser used to build alone now needs a developer and a deploy, so promotional calendars have to be planned further ahead than they were on Magento.
Copy link to headingShould historical orders be migrated or archived?
Bring them when account pages need order history or cohort analytics that depend on it, and archive otherwise. Original order dates land in processed_at rather than created_at, so any reporting keyed to creation date will show the whole archive dated to the day of the import.