Migration: Magento to Shopify, Step by Step for Plus Teams

Migration: Magento to Shopify, done properly, is a data-mapping project before it is a design project, because four entity types — customers, orders, configurable products and URLs — do not move one-to-one between the two platforms. Customers arrive without passwords. Completed orders land as historical records Shopify won’t let you fulfil or refund normally. Magento’s configurable products have to be squeezed into Shopify’s three-option variant model. And every URL Google has indexed needs a deliberate 301 redirect, built from Magento’s own url_rewrite table, or the store loses the organic rankings it migrated to keep. This walks through each of those four mappings, which Magento extensions have a Shopify app equivalent and which don’t, and the redirect step that most teams get wrong.

What Do You Need Before You Start a Magento to Shopify Migration?

Before any data moves, four things need to exist. First, a full Magento database export or admin-level access to run product, customer and order exports — not just storefront access. Second, a current export of every indexed URL Magento serves, pulled from the url_rewrite table directly and cross-checked against Google Search Console’s indexed-pages list, since Search Console shows what Google actually crawled, which is not always identical to what’s in Magento’s own table. Third, a decision on which Magento extensions are load-bearing — the ones handling pricing rules, B2B logic or custom checkout fields — versus which are cosmetic, because that list decides how much of the “migration” is actually a rebuild. Fourth, a freeze window: a period where Magento stops accepting new orders while Shopify is populated and tested, because running both platforms live and accepting orders on each at once creates inventory and order-numbering conflicts neither system can reconcile automatically.

Most Plus-scale Magento catalogues are large enough, and carry enough configurable products and custom options, that a manual product-by-product move isn’t realistic. A migration app — Matrixify, LitExtension and Cart2Cart are the three most commonly used for this specific pair of platforms — handles the bulk of the product, customer and order transfer against a CSV or direct API connection. None of them handles the redirect map or the extension-to-app audit automatically; those stay manual work, covered in Steps 4 and 5.

Step 1: How Do Magento Customers Map to Shopify Customers?

Magento and Shopify hash customer passwords with different, incompatible algorithms, and no migration tool, including Matrixify, LitExtension or Cart2Cart, can reverse a password hash to recreate a plaintext password it can re-hash into Shopify’s format. Every migrated customer account moves without its password, full stop. The practical fix is not technical; it’s a communication step: import customers first, then trigger Shopify’s own reset-password email as part of go-live, ideally paired with an email explaining why, sent from whichever email platform the store already uses.

The mapping that does carry real structure is Magento’s customer groups. A Magento store typically runs several groups — General, Wholesale, a retailer tier, a VIP tier — each tied to its own price rules. Shopify has no identical concept for a standard plan; a Magento customer group commonly becomes either a Shopify customer tag, which segments customers for marketing and manual discounting but carries no automatic pricing logic, or, on Shopify B2B, a company with its own catalogue and price list, which is the closer structural match for a genuine wholesale tier. Which one is right depends on whether the group exists for pricing (needs B2B) or for segmentation and reporting (a tag is enough) — map each group individually rather than defaulting every group to the same treatment.

Address books and guest-checkout order history move differently. A registered Magento customer’s saved addresses import cleanly as Shopify customer addresses through the same migration app. A guest checkout in Magento — an order placed with no account — has no customer record to migrate at all; it becomes a Shopify order with a matching email but no linked customer profile, unless the store explicitly wants to create Shopify accounts retroactively from guest order emails, which is a separate, optional step most teams skip.

Step 2: How Do Magento Orders Land in Shopify?

Shopify has a specific mechanism for this exact situation: the historical order, sometimes called an imported order. A historical order carries the original order number, date, line items, customer and totals for record-keeping, but Shopify deliberately blocks it from the normal fulfilment, payment-capture and refund flows a live order goes through — there’s no live payment to capture, since the transaction already happened on Magento’s original payment gateway. Importing completed Magento orders as historical orders, not live ones, is what keeps Shopify’s own order reporting accurate; importing them as live orders instead is a common early mistake that inflates Shopify’s sales figures with revenue that was never actually processed through Shopify.

Order numbering itself doesn’t carry across as Shopify’s live sequence. Shopify assigns its own incrementing order number starting from a number set in checkout settings, so a migrated Magento order keeps its original number as a reference field — visible in the order but not driving Shopify’s own count — while new Shopify orders start from whatever starting number was chosen at go-live. Set that number deliberately rather than accepting Shopify’s default; a store with years of Magento order history often wants Shopify’s numbering to start high enough that the two sequences don’t visually collide in support conversations.

Orders still open at the moment of freeze — placed on Magento but not yet fulfilled — are the edge case worth planning for explicitly: fulfil them on Magento before the export runs, or fulfil them manually on Shopify after import with a clear internal note, but decide which before the freeze window starts, not while a customer is asking where their order is.

Step 3: How Do Magento’s Configurable Products Become Shopify Variants?

Magento’s configurable product is built on its EAV (entity-attribute-value) data model: a parent product references a set of child simple products, each combination of attribute values — colour, size, and so on — a separate SKU under the same parent. Shopify’s product-variant model looks similar on the surface but caps out at three options per product, with each option having its own set of values that generate the full variant matrix.

That cap is where most Magento catalogues meet friction. A configurable product using two or three attributes maps cleanly: colour and size become Shopify’s Option 1 and Option 2, and each Magento child SKU becomes one Shopify variant with the matching SKU carried across. A configurable product using four attributes — colour, size, material and fit is a common real combination — does not fit as-is, and needs a decision made before the import runs: fold the least commercially important attribute into the product title or description text, or split the product into two separate Shopify listings divided by that attribute. Making this decision per-product during the import, rather than deciding the rule in advance and applying it consistently, is how a catalogue ends up with an inconsistent variant structure across otherwise-similar products.

Magento’s custom options are a separate mechanism from configurable products and deserve separate handling. A custom option — a monogram text field, a gift-wrap checkbox, a dropdown with a price add-on — has no exact Shopify equivalent. A custom option that behaves like a fixed choice with its own SKU and inventory usually becomes an additional Shopify variant. A custom option closer to free text or a price modifier with no separate inventory usually becomes a line item property, captured through a Shopify app at checkout rather than through the core variant system, since Shopify’s native checkout has no built-in custom-field mechanism of its own.

Bundle products — a Magento product assembled from other products, each with its own options — are the case worth flagging rather than mapping mechanically: Shopify has no native bundle-product type, and a Magento bundle typically becomes either a Shopify bundling app, which composites existing products at checkout, or a set of new fixed-SKU products created specifically to represent each bundle combination. Which is right depends on how many bundle combinations exist and whether inventory needs to track the bundle’s components individually — worth resolving before the SKU count in the new store balloons past what the catalogue actually needs.

Step 4: Which Magento Extensions Have a Shopify App Equivalent?

Audit every installed Magento extension by what it actually does, not by its marketplace category, because the honest answer for a meaningful share of them is that no Shopify app does the same thing the same way. A PIM extension syncing to Magento’s own attribute sets, covered in more depth in what Magento PIM actually does and what survives once you leave Magento, is a case in point: an extension-based Magento PIM built on Magento’s EAV model doesn’t carry across as data at all, since the attribute structure it depends on no longer exists once Magento is gone — only a standalone PIM connected to Magento, rather than built into it, moves cleanly to a new Shopify connector.

Layered-navigation and faceted-search extensions, common on larger Magento catalogues, map reasonably well to Shopify’s Search & Discovery app or a third-party filtering app, though the exact filter logic — which attributes are filterable, how ranges display — has to be rebuilt in the new tool’s settings rather than imported. Custom pricing-rule extensions — tiered discounts, customer-group-specific pricing, cart-level promotional logic written as custom Magento PHP — are the extensions most likely to have no direct Shopify equivalent, because that logic was often built to Magento’s specific rule engine and needs re-implementation against Shopify’s own discount and Shopify Functions APIs, not a reinstall of something with a similar name.

The audit itself is a table, not a checklist: extension name, what it actually does, the closest Shopify app or native feature, and a rebuild-or-replace verdict for anything with no clean match. A team that skips this and assumes “there’s probably a Shopify app for that” finds out mid-migration, usually while a merchandiser is asking why a pricing rule that worked yesterday no longer applies.

Step 5: How Do You Redirect Magento URLs to Shopify URLs Without Losing Rankings?

The redirect map is the step most teams get wrong, and the mistake is consistent: a team builds it by listing Shopify’s new URLs and guessing which old page each one replaces, instead of starting from a complete export of every URL Magento actually serves and has indexed.

Magento stores every canonical URL it generates in its own url_rewrite table, commonly with a path-based structure ending in .html, and a store running layered navigation or faceted search can have generated thousands of additional indexed URL variants for filtered category views — a colour-and-size filter combination on a category page, each with its own indexed URL — well beyond the product and category count alone would suggest. Shopify’s URL structure is fixed and different: /products/ and /collections/ paths, no .html suffix, and no native faceted-filter URL generation the way Magento’s does. The redirect map’s job isn’t to preserve the old URL string; it’s to send every one of those old, indexed URLs to whichever Shopify URL now serves the closest matching content, so the ranking signal a search engine already associated with that URL transfers to its replacement.

The right build order is: export the url_rewrite table directly from Magento’s database or admin, cross-check it against Google Search Console’s indexed-URL list for anything Magento’s own table might have missed or since removed, then map each entry to its live Shopify equivalent — product to product, category to collection, and any filtered or faceted URL either mapped individually or, more commonly at volume, consolidated to redirect to its parent unfiltered category page rather than recreated one-for-one on Shopify. Shopify’s admin, under Online Store → Navigation → URL redirects, accepts that finished map as a bulk CSV import, so the redirect logic gets decided against Magento’s real data before any redirect actually goes live — not worked out reactively from a 404 report after cutover, by which point the ranking damage from an unredirected page has usually already started.

Which Step Do Most Teams Get Wrong?

The redirect map, specifically the order it gets built in. A team under time pressure commonly starts from Shopify’s finished site map — here are our new product and collection URLs — and works backwards, guessing which old Magento page each one used to be. That approach catches the obvious cases, the top-selling products and main categories, and misses everything else: the filtered category URLs Google indexed on its own, the discontinued product still receiving search traffic, the blog or CMS page nobody remembered existed. Every one of those becomes a 404 the moment Magento goes offline, and a 404 on a page that used to rank doesn’t just fail to redirect — it tells Google the content is gone, which is a slower, harder-to-reverse signal than a page that simply changed its URL.

Starting from Magento’s own url_rewrite export inverts the risk: every URL Magento was actually serving gets a redirect decision made deliberately, including “redirect this filtered URL to its parent category” as a conscious choice, rather than “we forgot this URL existed.” The extra work is real — a large Magento catalogue’s indexed-URL count is routinely several times its product count once filtered and category variants are counted — but it’s the only version of this step that doesn’t rely on remembering everything the old site did.

How Do You Verify the Magento to Shopify Migration Worked?

Verify in this order. First, spot-check a sample of migrated customer records against Magento’s original data — email, address, customer group — rather than trusting the migration app’s own completion report, since a mismatched customer group silently breaks pricing for that customer on their first Shopify order. Second, place a real test order against a low-stock or discontinued product to confirm inventory, tax and any custom checkout fields behave correctly, not just a normal in-stock product. Third, run the finished redirect map against the original url_rewrite export, URL by URL, confirming each entry resolves to a 200 response on Shopify rather than a redirect chain or a 404 — a spreadsheet formula comparing the two lists catches gaps faster than clicking through them manually. Fourth, once live, watch Search Console’s coverage report for a spike in 404s or “page with redirect” warnings in the weeks after cutover — an incomplete redirect map shows up there first, before it shows up as an organic-traffic drop in analytics.

A migration: Magento to Shopify move that skips verification and goes straight from import to launch is the most common way a team discovers a mapping error from a customer complaint instead of from their own checklist — after the freeze window has closed and Magento is no longer the easy place to check the original record.

None of the four mappings in this article — customers, orders, products, URLs — is difficult in isolation. What makes a Magento to Shopify migration an operations problem rather than a weekend task is that all four have to be sequenced, verified and cut over together, on a timeline where Magento eventually goes offline for good. That sequencing, the extension-to-app audit, and the redirect map built from real data rather than guesswork are exactly the kind of cross-system coordination the ops automation service is built to run for scaling brands moving off a platform they’ve outgrown.