July 2, 2026 by Alex Massaad · 8 min read
Magento to Shopify Migration: What Actually Breaks

Magento to Shopify is the hardest of the common migrations. Not because the data won’t move, it will, but because Magento stores tend to be older and bigger, carrying more custom logic than the average WooCommerce or BigCommerce install. A Magento store that’s been running since the Magento 1 days has usually accumulated a decade of attributes and extensions, plus store-view quirks that nobody fully documents. That’s the real work: not the export, the untangling.
We’ve moved stores off both Magento 1 (end-of-life since June 2020) and Magento 2 / Adobe Commerce. This guide covers the places the migration genuinely breaks, the ones specific to Magento rather than the generic advice every migration post repeats.
The Honest Reason Most Merchants Move
The pattern is consistent, and it’s about cost of ownership rather than features:
- Licensing and hosting. Adobe Commerce licensing runs into six figures a year for larger merchants, and even open-source Magento carries real hosting and security overhead, patching included. Shopify folds all of that into the plan fee.
- Developer scarcity and cost. Specialist Magento developers are expensive and getting harder to find. Every version upgrade is a project. On Shopify the developer pool is deeper and the platform handles its own upgrades.
Magento is genuinely powerful, and for a handful of enormous, deeply custom catalogs it’s still the right tool. But most mid-market merchants are paying for flexibility they stopped using years ago. If you’ve made the decision, here’s what the move actually involves.
What Translates Cleanly
These come across without much drama:
- Simple and configurable products (configurables become products with variants)
- Customer records (minus passwords, same as every migration)
- Order history (as reference data for support and analytics)
- CMS pages (about, FAQ, policies)
- Categories (as a flat mapping to collections, with the hierarchy caveat below)
- Cart price rules (most map to Shopify discounts; some complex stacking logic does not)
- Tax and shipping concepts (the model maps; registrations and rates are re-entered)
For these, the path is an export, a transform, and an import. Tools like Matrixify handle the bulk of it. The trouble starts with everything Magento models more richly than Shopify does.
What Actually Breaks
1. Product Types Beyond Simple and Configurable
Magento has six product types. Shopify effectively has one, with variants. The mapping:
- Simple to a Shopify product.
- Configurable to a product with variants. Clean, as long as you’re within Shopify’s option limits.
- Bundle to a bundle app, a metafield-driven grouping, or Shopify’s native bundles, depending on whether the components need independent inventory.
- Grouped to a collection or a custom “buy the set” pattern, since Shopify has no native grouped-product concept.
- Virtual and downloadable to a digital-product app, since Shopify treats these as products with shipping switched off plus a delivery app.
Configurables are fine. Bundles and grouped products are where you make architectural decisions, and the right answer depends on how they’re actually merchandised and stocked. Settle this in the audit, not mid-build.
2. The EAV Attribute Model
This is the Magento-specific one most guides miss. Magento stores product data in an EAV (entity-attribute-value) model, which means a store can have hundreds of custom attributes organised into attribute sets. Shopify has a fixed set of product fields plus metafields.
Every custom Magento attribute needs a decision: does it become a Shopify variant option, a metafield, a tag, or does it get dropped because nothing actually uses it? Large Magento catalogs routinely carry attributes that were added for a campaign in 2018 and never removed. The migration is a good moment to audit them, but that audit takes time, and skipping it means either losing data or importing a mess of metafields nobody reads.
3. URL Rewrites and the .html Suffix
Magento product URLs often carry a .html suffix and sit at the domain root (/blue-widget.html), and category URLs can be deeply nested (/furniture/living-room/sofas.html). Shopify forces /products/ and /collections/ prefixes and doesn’t use .html.
| Content type | Magento URL | Shopify URL |
|---|---|---|
| Product | /blue-widget.html | /products/blue-widget |
| Category | /furniture/living-room/sofas.html | /collections/sofas |
| CMS page | /about-us | /pages/about-us |
| Blog (if using a blog extension) | varies by extension | /blogs/news/post-title |
Every one of those changes needs a 301. Magento’s own url_rewrite table is the source of truth for what’s actually indexed, including the historical rewrites Magento generated automatically every time a product’s URL key changed. Export that table, don’t just crawl the live site, or you’ll miss redirects for URLs Google still has in its index. This is the single most common cause of a post-migration traffic drop from Magento.
4. The Store / Website / Store-View Hierarchy
Magento’s website/store/store-view structure lets one installation run multiple storefronts, currencies, and languages. Shopify has no direct equivalent, and deciding what it maps to is one of the biggest architecture calls in the project:
- Language and currency variations of one brand map to Shopify Markets with Translate & Adapt.
- Genuinely distinct storefronts (different catalogs, different fulfillment) map to Shopify Plus expansion stores.
- A single catalog served regionally usually collapses into one store with Markets, and the merchant discovers they were carrying multi-store complexity they no longer need.
More often than not it’s that last case. Settle it early, because it determines your pricing tier, app stack, and theme architecture.
5. Layered Navigation
Magento’s layered (faceted) navigation is powerful and often SEO-indexed, with filterable attributes generating their own crawlable URLs. Shopify’s native filtering (Search & Discovery) works differently and doesn’t generate the same indexable filter pages by default. If you’ve been earning traffic on filtered category pages, that traffic needs a plan: either a collection-per-facet strategy with proper canonicals, or a filtering app that handles indexable facets. Don’t assume it carries over.
6. Extensions Have No One-to-One Map
Most Magento installs run on a stack of third-party modules, and almost none map cleanly to a single Shopify app. Each one gets triaged: a native Shopify feature covers it, a Shopify app replaces it, or we build a small custom app or Shopify Function. The output of that triage is an extension-to-replacement map you sign off on before kickoff, so no piece of functionality goes missing during launch week. Budget real time for this on an enterprise install; it’s often the longest line in the audit.
7. Customer Passwords
Same constraint as every migration. Magento uses one-way password hashing, Shopify uses its own, and neither exposes the raw values. Every customer resets on first login. Plan the comms email and time the cutover so support is staffed for the “I can’t log in” wave in the first 48 hours.
8. B2B Is a Re-Modeling, Not a Move
Adobe Commerce B2B has company accounts, shared catalogs, tier pricing, requisition lists, and quote workflows. Shopify Plus native B2B now covers most of this, which makes these migrations far cleaner than they were two years ago, but the data model is different. Magento thinks in customer groups and tier prices; Shopify thinks in companies, locations, and catalogs. Moving a B2B store is re-modeling how your wholesale relationships are structured, not a CSV import. Give it a dedicated planning conversation.
The Migration Order We Run
- Audit the catalog and attributes. Product types, attribute sets, and which custom attributes actually drive anything.
- Export the url_rewrite table. This, not a site crawl, is your redirect source of truth.
- Decide the store architecture. One store with Markets, or expansion stores on Plus.
- Triage extensions. Native feature, app, or custom build, one decision per module.
- Model B2B if it’s in scope, before any data moves.
- Migrate data in order: products, customers, categories, CMS pages, redirects, then orders for reference.
- Build the storefront on Online Store 2.0, matched to brand and merchandising.
- Test in a development store with real data and real test orders.
- Cutover. DNS swap, watch checkout for 48 hours, monitor Search Console weekly for the first month.
The audits and the storefront rebuild are where the weeks go. The cutover itself is a couple of hours.
Realistic Timelines
| Store profile | Estimated timeline |
|---|---|
| Standard catalog, simple/configurable products, no B2B | 8 to 12 weeks |
| Large catalog with heavy custom attributes and extensions | 12 to 16 weeks |
| Enterprise Adobe Commerce with B2B and multi-store | 12 to 20 weeks |
Most of the variability comes from three places: attribute and extension cleanup, B2B re-modeling, and integrations with external systems (ERP, PIM, 3PL) that were wired into Magento directly.
Mistakes We See Most Often
- Crawling the live site for redirects instead of exporting url_rewrite. You miss the historical rewrites Google still has indexed, and rankings drop for URLs you didn’t know existed.
- Importing every attribute as a metafield. Audit first. Half of them aren’t used, and a wall of empty metafields helps nobody.
- Underestimating bundle and grouped products. They look simple in the admin and turn into a merchandising project.
- Treating B2B as a data move. Adobe Commerce B2B is a different project than a B2C catalog with a few wholesale accounts.
- Forgetting layered-navigation SEO. If filtered category pages earn traffic, they need a plan, not a shrug.
Do You Need Help?
A small Magento store with simple products and no B2B can be moved by a capable developer with the right tooling. The Shopify Help Center covers the basics of importing from Magento.
An enterprise Adobe Commerce install with a decade of attributes, custom modules, B2B, multi-store, and traffic you can’t afford to lose is not a DIY job. The cost of a botched Magento migration, lost rankings from missed redirects, missing customization data, a B2B model that doesn’t match how you actually sell, is far higher than the cost of working with a team that has done it before.
We’ve handled migrations from Magento, WooCommerce, BigCommerce, and custom platforms. If you’re weighing the move, our Magento to Shopify migration service covers how we scope and run these, and our BigCommerce and WooCommerce guides cover those paths. For what a rebuild costs after the move, see how much a custom Shopify store costs in 2026.
If you’d like to talk through your specific Magento setup, reach out for a free consultation. We’ll tell you straight what your migration would actually take.
