Magento to Shopify Migration: What Transfers, What Breaks, and the Cutover Order

Why Magento stores are moving right now: the support clock

Most replatforming decisions in 2026 are not driven by a feature wish-list. They are driven by a date.

Adobe runs two support tiers, and the gap between them is the whole story. Adobe Commerce customers can get a no-cost one-year extension on some lines. The Magento Open Source code base is explicitly excluded from that extension — so Open Source merchants lose patches at the earlier date, with nothing to buy their way out of.

Dates are from Adobe's Commerce software lifecycle policy, which is the only version of this table worth trusting — third-party EOL trackers routinely show the Commerce extended date next to an Open Source store and make the runway look longer than it is.

There is a second clock that catches people out: PHP. Magento 2.4.6 runs on PHP 8.1 and 8.2, and PHP 8.2 reaches its own end of life on 31 December 2026. Adobe's extended support does not extend support for third-party dependencies. An Adobe Commerce merchant with patches into 2027 can still fail a PCI assessment at the end of 2026 because the language runtime underneath is dead. Check both clocks before you decide you have time.

Confirm which edition you are actually on before anything else — composer.json requiring magento/product-community-edition means Open Source and the earlier dates; magento/product-enterprise-edition means Commerce.

Should you upgrade Magento or move to Shopify?

A Magento 2.4.6 to 2.4.9 upgrade is not free. On a store with a dozen third-party extensions it is a two-to-three month project with its own regression risk, and it buys you about three years before the same conversation happens again. Replatforming is usually comparable in effort and resets the maintenance burden to near zero. So the question is not which is cheaper this quarter — it is where your differentiation actually lives.

The honest version: if you cannot name three platform behaviours Shopify would take away from you, the platform is not where your moat is.

What actually transfers from Magento to Shopify — and what doesn't

Every migration tool markets on the first column of this table. The projects that go wrong go wrong in the second one.

Mapping Magento configurable products to Shopify variants

Magento has six product types. Shopify has one, with options hanging off it. That mismatch is the real data-modelling work.

On limits: Shopify's GraphQL Admin API handles up to 2,048 variants on a single product, and returns a maximum of 250 items per page on everything else, per Shopify's products and collections documentation. The practical consequence for a migration script: variants on one product come back in a single request, but your product loop has to be cursor-paginated, and a 40,000-SKU catalog should go through bulk operations rather than per-product mutations unless you enjoy rate-limit backoff.

The piece most teams skip: Magento attribute sets do not have a Shopify home by default. Material, warranty, voltage, compatibility — anything that was a filterable attribute in layered navigation — has to be re-created as metafields, and metafields must exist before the import runs or those values are silently dropped. Define the metafield definitions first, map attribute codes to metafield keys in a spreadsheet, and treat that spreadsheet as a deliverable. If filtering on those attributes matters for navigation, connect them to Search and Discovery at the same time, not as a phase two that never happens.

The redirect map: how to keep your rankings

Shopify will not reproduce your Magento URLs. Products live at /products/{handle}, collections at /collections/{handle}, pages at /pages/{handle}, articles at /blogs/{blog}/{handle}. Magento's category-path URLs with a .html suffix have no equivalent. Every indexed URL on the store changes, which means a 301 map is not an optimisation — it is the migration.

Build the source list from the database, not only from a crawler. Magento keeps every live and historical URL in url_rewrite, including rewrites a crawl of your current navigation will never surface:

SELECT request_path, target_path, entity_type, entity_id
FROM url_rewrite
WHERE store_id = 1
  AND redirect_type = 0;

Then union that with three more sources: the Search Console performance export (everything that actually earns impressions), the top landing pages in analytics for the last 12 months, and your backlink export. A URL with external links pointing at it is worth more than a URL in your sitemap.

Shopify takes the finished map as a CSV in the admin, with exactly two columns:

Redirect from,Redirect to
/mens/shoes/trail-runner-x.html,/products/trail-runner-x
/mens/shoes.html,/collections/mens-shoes
/catalog/product/view/id/4471,/products/trail-runner-x

Rules that save you a traffic drop:

• Never chain. Map every old URL to its final destination. A redirect that lands on another redirect bleeds crawl budget and sometimes bleeds the ranking signal with it.
• Collapse layered navigation parameters. Magento filter URLs like /mens/shoes.html?color=black&size=42 can run into the thousands. Point the whole family at the base collection; do not generate a redirect per combination.
• Handle the suffix and case variants. Both the .html and non-.html forms, and any uppercase legacy paths, need entries. They are separate URLs to a crawler.
• Check Shopify's own duplicate paths. Shopify also serves a product inside a collection at /collections/x/products/y. Confirm your theme canonicalises to the bare /products/{handle} before launch.
• Keep the old Search Console property. Do not delete it. It is how you prove the redirects were picked up.

Mapping a catalog of a few hundred products is an afternoon in a spreadsheet. Mapping 20,000 URLs with historical rewrites, discontinued SKUs and parameter families is a scripted job with a verification pass — which is the shape of most of the ecommerce data migration and replatforming work we take on.

The cutover order that avoids downtime

The sequence matters more than any individual step. This is the order we run it in:

1. Drop DNS TTL to 300 seconds, at least 48 hours before launch day. Do this first because it is the one step you cannot accelerate later.
2. Build on the myshopify.com domain with password protection on. Shopify blocks indexing of password-protected stores, so you cannot accidentally index the staging build.
3. Run a full dry-run import of the real catalog — not a sample. Then diff it: product count, variant count, sum of prices, count of products with zero images, count of SKUs present in Magento and missing in Shopify. Automate the diff; eyeballing a catalog does not scale.
4. Load the redirect map into the staging store and test it as a list, not by clicking. A script that requests every old path and asserts a 301 to the expected target takes an hour to write and catches the mistakes that cost rankings.
5. Configure payments, taxes and shipping, then run one real low-value transaction end to end and refund it. Test mode does not prove your live gateway credentials work.
6. Set up email authentication before launch. SPF, DKIM and your sending domain on Shopify have to be in place, or the first wave of order confirmations lands in spam — on the day you have the least slack to notice.
7. Freeze catalog and content edits, then run the final delta import of products, customers and orders. Announce the freeze window to whoever edits the store; it is usually broken by someone who never saw the email.
8. Switch DNS. Keep Magento alive on a subdomain such as legacy.yourdomain.com, read-only, for finance and support history. Do not let it keep answering on the primary domain.
9. Publish redirects on the live domain immediately, then submit the new sitemap in Search Console and leave the old property in place.
10. Watch 404s daily for 14 days and add redirects as real traffic finds the gaps your map missed. It always misses some.

Two things to keep off launch day: a theme redesign, and a catalog restructure. Both are legitimate projects. Running either at the same time as a replatform means that when traffic drops you have no idea which change caused it.

What to watch in the first 30 days after migration

A migration looks successful for about a week. The signals that matter are lagging ones.

What a Magento to Shopify migration costs and how long it takes

Catalog size is the number everyone quotes and the weakest predictor of effort. These are the drivers that actually move a quote:

• Attribute axes per configurable product. Two axes is automation. Four is data modelling with human decisions on every family.
• Number of indexed URLs, not number of products. A 2,000-product store with ten years of layered navigation indexed can have a larger redirect job than a 20,000-product store launched last year.
• Custom checkout and pricing logic. The most expensive thing in any Magento migration, every time.
• Integrations. ERP, 3PL, marketplace feeds and accounting all need rebuilding against Shopify's APIs, and each one has its own test cycle.
• Content built in Page Builder. It does not export. Budget per page, manually.

Rough shape for a mid-market Open Source store with a conventional catalog and a handful of integrations: four to eight weeks from kickoff to cutover, with the redirect map and integration rebuilds consuming more of that than the product import does. Anything promising a two-day migration is quoting the data copy and leaving you the rest.

If you are on 2.4.6 or earlier, the decision has already been made for you by the calendar — what is left is choosing whether to spend the budget on another Magento upgrade cycle or on the last platform migration you do for a while. If you want that scoped against your actual catalog and URL footprint rather than against a generic checklist, tell us what you are running and we will come back with a plan.