Development
The Magento features that have no Shopify equivalent
Quick summary — Magento to Shopify Migration: What Actually Breaks
- Author:
- Misha Gavura
- Published:
- Reading time:
- 11 min
- Views:
- 0
- Likes:
- 0
- Summary
- A Magento to Shopify migration breaks on category trees, configurable products and customer groups. What maps, what does not, and who should not move.
Table of contents
Why the Magento exits are clustered right now
Adobe's released-versions page puts the end of support for Adobe Commerce 2.4.5 and 2.4.6 at 11 August 2026. The 2.4.7 line runs to 9 April 2027 and 2.4.8 to 11 April 2028. Adobe's no-cost one-year extension covered 2.4.4 and 2.4.5 and was offered to Adobe Commerce customers, so read your own licence terms before assuming it applies to you.
The licence was never the expensive part anyway. The upgrade cycle is. A minor release means retesting every third-party module against a new PHP version and a new Composer tree, revalidating the search engine, and doing it on infrastructure you are responsible for. A store with twenty extensions pays that bill roughly twice a year, forever, and the bill grows because module vendors drop old versions faster than Adobe does.
Shopify makes an explicit trade. You stop paying for upgrades and start paying rent, and you give up the right to change anything below the theme and the app layer. For a lot of Magento merchants that is a good trade. For some it is a bad one. Most of this article is about telling those two groups apart, because the parts of Magento that do not map are load-bearing more often than the sales deck admits.
Shopify plan pricing, accurate as of 12 August 2026. Shopify's Canadian pricing page lists Basic at CA$49 per month, Grow at CA$132 and Advanced at CA$517 on monthly billing, dropping to CA$37, CA$99 and CA$389 on annual billing. Plus is listed as from CA$3,400 per month. Plus is a negotiated contract, so treat the published number as a floor rather than a price.
Where the catalogue actually breaks
The category tree does not become a URL hierarchy
Magento gives you an arbitrarily deep category tree, and it lets you decide in configuration whether the category path appears inside product URLs and whether pages carry a .html suffix. Shopify gives you collections. A collection is a list. Every collection sits at /collections/handle and every product sits at /products/handle, no matter where either one appears in your navigation, and those prefixes are not editable.
This did improve in June 2026, in Admin API version 2026-07. The new Shopify collections model lets a collection use another collection as a source, so a parent stays in sync when its child changes. Read the limits before you plan around it. Sub-collection sources are capped at a nesting depth of one, a shop can have 50 collections that contain another collection, a single collection can combine at most 10 sources, and only 5 collections can exclude another collection. Deep nesting still does not exist, and none of it changes the URL.
So a six-level Magento tree becomes two separate things on Shopify: a navigation menu, which can nest, and a flat set of collections behind it. Decide that mapping on paper before anyone touches an export. Doing it during the data import is how stores launch with 900 collections and no navigation logic.
Configurable, bundle and grouped products
Shopify raised the variant ceiling to 2,048 per product on 15 October 2025, on every plan. The option ceiling did not move with it. Shopify exposes that ceiling as a shop resource limit, Shop.resourceLimits.maxProductOptions in the Admin API, and it has sat at three options per product. Query it on your own shop rather than trusting a blog post, this one included.
Configurable products map cleanly when they use three or fewer variation attributes, which Magento already requires to be global scope with required values. Above three axes you either split one product into several, or you collapse an axis into a metafield and give up selling that combination as its own stock-keeping unit. Count yours before scoping. Export your products by attribute set with the number of variation attributes on each, and the count of products above three axes tells you in an afternoon whether this is a mapping exercise or a catalogue rebuild.
Bundle and grouped products have no native equivalent at all. A Magento bundle prices itself from whatever the customer selects and decrements each child SKU. On Shopify you either sell the bundle as a fixed product with its own SKU and reconcile stock some other way, or you install a bundles app and inherit its constraints. Grouped products, the ones that put several SKUs behind a single add-to-cart panel, come across as a collection or a custom product template.
Custom options with price deltas are the quiet failure. Shopify prices per variant. Free-text personalisation arrives as a line item property, and a line item property does not change price. That used to be a job for Shopify Scripts. Scripts stopped running on 30 June 2026, so it is a Shopify Function or an app now, and that is a build line, not a checkbox.
What maps, what bends and what you lose
The useful version of this table is the third column. Everything in Magento has something on Shopify you can point at. The question is what falls off in the translation, and whether the thing that falls off is one you sell with.
| Magento 2 concept | Shopify equivalent | What you lose |
|---|---|---|
| Category tree, arbitrary depth | Collections plus navigation menus | Path-based URLs. Collections nest one level as sources, and only 50 per shop can contain another collection. |
| Configurable product | Product with options and variants | A fourth option axis. Shopify allows 2,048 variants per product but the option ceiling has stayed at three. |
| Bundle product | Fixed bundle SKU or a bundles app | Dynamic pricing from selected items and per-child stock decrement, unless an app rebuilds both. |
| Grouped product | Collection or custom product template | The single panel that adds several different SKUs to the cart in one action. |
| Customer group with tier prices | B2B companies, locations and catalogs | Group logic outside B2B. Basic, Grow and Advanced allow 3 active catalogs; Plus allows an unlimited number. |
| Catalog price rules | Automatic discounts and Shopify Functions | Rules that rewrite the displayed catalogue price. Shopify discounts apply to the cart, not the price label. |
| CMS blocks and widgets | Theme sections, pages and metaobjects | Rule-based placement by page type and store view. None of it imports, all of it gets rebuilt. |
| Websites, stores and store views | Markets, plus expansion stores on Plus | Shared admin across brands. A Plus contract includes ten stores, one main and nine expansion. |
| EAV attributes and attribute sets | Metafields and metaobjects | Attribute sets as a concept. Definitions cap at 256 per owner type for the merchant, with a further 256 per installed app, and attributes must be converted before import. |
| Custom PHP modules | Apps, Functions and theme code | Direct database and core class access. Nothing on Shopify overrides platform behaviour the way a module does. |
Customer groups, tier pricing and B2B
Magento customer groups are a storefront primitive. A group changes tax class, tier prices, which catalog price rules fire and in some builds what a customer can see at all. Shopify has no equivalent primitive. It has B2B: companies, company locations, and catalogs that carry fixed prices, volume pricing and quantity rules including minimums, maximums and order increments.
Plan choice follows directly from your tier count. Shopify's documentation states that Basic, Grow and Advanced allow up to 3 active catalogs across all B2B markets, and that Plus allows an unlimited number with direct assignment to companies and locations. Four price tiers means Plus, or it means consolidating tiers. That decision belongs in the scoping call, not in month three.
The second half is catalog price rules. Magento rewrites the price a shopper sees. Shopify automatic discounts apply in the cart, so the product page keeps showing list price unless the theme is doing extra work. B2B catalogs do give genuine per-company displayed prices, which is why tier pricing and B2B are one conversation on Shopify rather than two.
One firm opinion. If your prices arrive from an ERP as per-customer files covering tens of thousands of SKUs with daily updates, do not accept anyone assuring you it will be fine. Build that single integration against a development store first and watch it run for a week. It is the cheapest way to find out whether this project is a migration or a rewrite.
CMS blocks, widgets and multi-store
Magento CMS blocks and widgets are a small content system: a block of markup, placed by rule into a page type, a category or a store view. None of it exports. The Shopify equivalents are theme sections, pages and metaobjects, and placement happens in the theme editor rather than through admin rules. Content gets rebuilt by hand. Budget it as build work, because calling it migration work is how the estimate goes wrong.
Multi-store is the larger question. The Magento hierarchy is websites, then stores, then store views, with configuration scope resolving at each level, so one installation can run several brands with different catalogues, currencies and legal entities. Shopify splits that in two. Markets handles currencies, languages, market-specific pricing and B2B catalog assignment inside one store. Separate stores handle the cases where the brands and catalogues genuinely are different businesses.
A Shopify Plus contract includes a maximum of ten stores at no additional cost, one main store plus nine expansion stores, with staging stores excluded from the count. Anything beyond ten is billed as an additional expansion store, published at CA$450 per month each. Ten covers most merchants comfortably. If you are running thirty store views that each need their own catalogue and their own admin, count them against that number before you go any further.
Redirect mapping is mandatory, and it is not a rewrite rule
Two Magento stores can have completely different URL shapes. The suffix is a setting, .html or nothing. Whether the category path appears inside a product URL is another setting. Shopify has exactly one shape and the /products/ and /collections/ prefixes cannot be changed. There is no regular expression that converts one into the other, which is why replatform SEO advice about rewrite rules does not apply here. You need an exported list of every indexed Magento URL and a decided target for each one.
Two ceilings worth knowing before you build the map. Shopify allows a maximum of 100,000 URL redirects on standard plans and 20,000,000 on Plus. Shopify also blocks redirects from a set of fixed paths, including /products, /collections, /collections/all, and anything beginning with /cart, /orders, /apps or /services. Check your export for collisions early.
Then decide what not to redirect. Magento layered navigation generates an enormous number of parameterised URLs, and on most stores a large share of them should never have been crawlable in the first place. Mapping those one to one moves an old crawl budget problem onto a clean site. Redirect the URLs that hold links and rankings, let the rest 404, and say so in the plan so nobody panics at the crawl report in week two.
Size this before you commit to a launch date, because the redirect map is usually the longest single task in the project. Count the rows in your own export that need a decided target, not the number of products, and put that number in front of whoever is setting the date.
Magento setups that should not move to Shopify
Every vendor on this search result claims everything migrates. It does not. These are the cases where we would tell a merchant to stay on Magento, or at least to run a paid discovery before signing anything.
- Products that need more than three option axes and cannot be split. Made-to-measure and configure-to-order catalogues run into the option ceiling immediately, and the workarounds all cost you either the SKU or the merchandising.
- Order lifecycle logic written as PHP modules. Custom split fulfilment, warehouse allocation rules, credit memo handling and invoice sequencing sit below the line Shopify lets you modify. Some of it is reachable through Functions and apps. Some of it is not reachable at all.
- More than ten distinct storefronts that each need a separate catalogue and admin. The Plus contract includes ten. Going beyond that is possible but it is a commercial negotiation, and it changes the total cost you are comparing against.
- Checkout that must hard-block on a business rule, such as licence or age verification tied to the payment step. Plus can extend checkout meaningfully, lower plans much less so. Validate the exact rule against Checkout Extensibility before you assume it.
- A store whose real problem is merchandising rather than platform. If the current site is slow, the product pages are thin and nothing is tested, Shopify will host those same problems faster. Our audit of 5,410 live Shopify stores found only 4.9 percent free of the eight most common conversion mistakes, and 74.8 percent had the add-to-cart button below the fold on mobile. The platform is not what fixes that.
The honest framing is that Shopify removes infrastructure work and adds constraint. If your complexity lives in the catalogue and the front end, the trade is good. If your complexity lives in the order pipeline and the pricing engine, look hard before you jump.
The order the work actually goes in
The sequence below puts every decision that can kill the project in the first three steps, on purpose. Data import is deliberately late, because importing before the model is agreed produces a catalogue you have to import twice.
- Audit the Magento catalogue. Count configurable attributes per product, bundles, grouped products, custom options with price deltas, customer groups and active catalog price rules. This is the document that decides plan and budget.
- Model the target. Decide collections and navigation, which attributes become metafields and metaobjects, and which products split. Convert attributes before the import, not after.
- Prove the two hardest integrations against a development store: whatever feeds pricing, and whatever feeds inventory or orders. If either fails, you want to know now.
- Export every indexed URL from Magento, Google Search Console and your log files, then build the redirect map with a decided target per URL.
- Build the theme and rebuild the content that used to live in CMS blocks and widgets.
- Dry run the full import into the development store, then reconcile counts: products, variants, customers, historical orders.
- Cut over, load the redirects, submit the new sitemap, and keep the Magento instance readable for long enough to answer questions.
- Watch Search Console coverage and the 404 report daily for the first month, and treat the theme as the start of conversion work rather than the end of the project.
Two things that always surprise people. Customer passwords cannot come across in a usable form, on any platform pair, because they are stored as one-way hashes. Plan account activation emails as part of launch communications rather than as a support incident. And historical orders import as records, not as live orders, so anything your team does with order state in Magento needs a new home before cutover.
Timelines depend almost entirely on step one and step three. A clean catalogue with no bundles and standard pricing moves quickly. A catalogue with ERP-driven per-customer prices and 4,000 bundles does not. When an agency gives you a date, ask which of those two catalogues they think yours is and what in your export told them.
Common questions
Will I lose Google rankings when I migrate from Magento to Shopify?
You will see movement for a few weeks, and the size of it depends almost entirely on redirect quality. Shopify forces /products/ and /collections/ prefixes, so every indexed Magento URL needs an explicitly mapped 301 target rather than a rewrite rule. Stores that map every ranking URL, keep title and content parity, and submit a new sitemap on cutover day usually recover within one to two months.
Can I migrate Magento customer accounts and passwords to Shopify?
Accounts yes, passwords no. Passwords are stored as one-way hashes, so they cannot be moved into a usable state on any platform. The standard approach is importing customer records with their order history, then sending account activation invitations at launch. Write that email before cutover day and warn your support team, because it generates the biggest single spike in tickets.
Do I need Shopify Plus to migrate from Magento 2?
Not always. The usual triggers are B2B and checkout. Basic, Grow and Advanced allow up to 3 active B2B catalogs, while Plus allows an unlimited number with direct assignment to companies and locations, so more than three price tiers points to Plus. Deeper checkout customisation, more than one storefront, and higher redirect ceilings are the other common reasons.
What happens to my Magento extensions?
They do not transfer. Every extension has to be re-solved as a Shopify app, a Shopify Function, theme code, or a decision to drop the feature. Audit the list early and mark each one as replaceable, rebuildable or blocking. The blocking ones, usually order pipeline and pricing engine logic, are what decide whether this migration is a good idea at all.
Does Shopify still limit products to 100 variants?
No. Shopify raised the limit to 2,048 variants per product on 15 October 2025, across all plans. The option ceiling is separate and did not change, and has remained at three options per product, exposed in the Admin API as a shop resource limit. So 16 colours by 8 sizes by 16 lengths fits in one product, and a fourth option axis still does not.