Magento to Shopify Product Migration, Mapped

A Magento to Shopify product migration is not a copy job — it is a translation between two different ways of modelling a catalogue. Magento builds a sellable product from attributes grouped into attribute sets, with configurable parents assembled from simple child products. Shopify gives every product up to three options that generate its variants, and puts everything else into metafields. The records move easily; the model does not. Decide, attribute by attribute, what becomes an option, what becomes a metafield and what gets restructured, before anything is exported, and the import is the easy part.

Get the mapping wrong and the import still “succeeds”. Products appear, prices are right, and then nobody can filter by fabric, the size chart has gone missing and half the range has quietly been split into duplicates. This guide covers how each piece of a Magento catalogue lands in Shopify, the platform limits that force restructuring, and the order we work in.

Two catalogue models, side by side

In Magento, a T-shirt sold in five colours and four sizes is typically a configurable product: a parent record that holds the shared content, linked to twenty simple products — one per colour-size combination, each with its own SKU, stock and, potentially, its own price and images. Colour and size are configurable attributes, and the parent’s attribute set decides which other attributes (material, fit, care instructions) the product carries at all.

In Shopify, the same T-shirt is one product with two options, Colour and Size, generating twenty variants. Each variant has its own SKU, price, stock and image. Material, fit and care live in metafields — typed custom fields on the product or variant — or in metaobjects when the same structured content (a fabric with its own description and care rules) is shared across many products.

So the simple children do not migrate as products. They become variants of their parent. That is the first and most important translation, and it is where automated exports go wrong most often: a tool that reads Magento’s flat product table without the parent-child links will happily create twenty separate Shopify products called “T-shirt”.

Mapping Magento product types to Shopify

Magento ships several product types, and only two of them have a direct Shopify equivalent. Here is how each one usually lands:

Magento product type	Lands in Shopify as	What to watch
Simple	Product with a single default variant	Clean mapping. Check that weight and SKU come across.
Configurable	One product; configurable attributes become options, simple children become variants	The three-option and 2,048-variant limits below.
Virtual	Product with “requires shipping” switched off	Services, warranties, appointments — check fulfilment logic.
Downloadable	Product delivered through a digital-downloads app	Files and download limits move to the app, not the product record.
Bundle	A bundle built with Shopify’s bundles tooling or a Cart Transform function	Inventory has to be decremented from the components, not a phantom bundle SKU.
Grouped	No native equivalent — usually separate products shown together on one page	Decide how the “buy these together” page is rebuilt in the theme.

Bundles deserve their own planning. Whether a bundle is a fixed set, a pick-your-own box or a multipack changes the data model entirely — we compare the three approaches in our guide to building a box builder on Shopify, and the same reasoning applies to Magento bundle products on their way across.

Configurable attributes: options, metafields or line item properties

Every Magento attribute on a product needs one of four destinations. The question that decides it is not “what is this attribute called” but “what does it do”.

Does it create a separate SKU? Make it an option

If choosing a value changes what is picked off the shelf — size, colour, capacity — it is a variant dimension and becomes a Shopify option. Shopify allows up to three options per product and, since the limit was raised in 2025, up to 2,048 variants per product on every plan.

Do shoppers filter by it? Make it a typed metafield

Magento lets you tick “Use in Layered Navigation” on almost any attribute. Shopify’s equivalent is the Search & Discovery app, which can filter on product options, standard fields (price, availability, vendor, product type, tags, category) and product or variant metafields. Only certain metafield types are filterable — single line text, lists of single line text, integers, decimals, true/false and metaobject references — so a material attribute imported as a rich-text blob will never become a filter. Shopify also caps a store at 25 filters in total, which forces a useful conversation about which of Magento’s dozen layered-navigation attributes customers actually use.

Is it shared, structured content? Make it a metaobject

When many products point at the same thing — a fabric, a designer, an ingredient with its own description and image — store it once as a metaobject and reference it from each product. Edit the fabric once and every product updates. This is often a cleaner model than the Magento original, where the same care text was copied into hundreds of product descriptions.

Is it a personalisation, not a product? Make it a line item property

Magento’s customizable options — an engraving text field, a gift-message box, a file upload — do not create SKUs, and they should not become Shopify variants. They become line item properties captured on the product form, through the theme or an app, and carried through to the order. Price surcharges on those options need separate handling, because a line item property on its own does not change the price.

When a product breaks Shopify’s limits

Most catalogues fit comfortably. The ones that do not tend to be furniture, lighting, automotive parts and anything sold in made-to-measure combinations, where a Magento configurable product might carry four or five configurable attributes. There are three honest ways through, and the right one depends on the product, not on a blanket rule:

• Split by the most visible attribute. A sofa in three fabrics, three sizes, two leg finishes and a choice of cushion fill becomes one product per fabric, each with the remaining options. On Shopify Plus, Shopify’s Combined Listings app can then present those products as one listing with a shared selector — up to 60 products and 2,048 variants per combined listing — while each keeps its own URL and images.
• Demote a dimension that is not really stock. If cushion fill is assembled to order and never stocked separately, it does not need to be a variant. It can be a line item property with the surcharge handled at the cart.
• Use a product options app. For genuinely configurable goods, an app that renders extra choices outside Shopify’s variant model is often the cleanest option. Check how it writes the selection onto the order before relying on it for fulfilment.

Prices, images, store views and URLs

The product model is the centre of the job, but four other pieces of the catalogue regularly cause rework.

• Tier and customer-group pricing. Magento stores quantity tiers and per-customer-group prices on the product. Shopify has no field for them on a standard product. They move to Shopify’s B2B catalogs and price lists where your plan includes B2B, or to discount logic — a decision that belongs in scoping, not in the import script.
• Images per child. Magento simple products can each carry their own gallery. In Shopify, images belong to the product and each variant points at one of them. Import the children’s images onto the parent and assign them by variant, or the colour switcher will not change the photo.
• Store views. A Magento store with English and Arabic store views holds translated names, descriptions and attribute labels per view. On Shopify those become translations of the same product, managed through Translate & Adapt or a translation app — not duplicate products.
• URL keys. Magento URLs are built from the URL key, often with a category path and a .html suffix. Shopify serves every product at /products/<handle>. Set each handle from the URL key, then map every old product and child URL to its new home. Our guide to building a 301 redirect map that survives a replatform covers the method; the simple-product URLs that Magento sometimes left indexed need entries too.

The order we run a product migration in

1. Inventory the attribute sets. List every attribute in use, which products carry it, and whether it drives a SKU, a filter or nothing at all. Unused attributes are not migrated.
2. Design the Shopify model. Options, metafield definitions with the right types, metaobjects and any products that need splitting — agreed and signed off.
3. Migrate a representative sample. One product of every type and every awkward shape, checked on a real theme with real filters, before the full run.
4. Run the full import and reconcile. Counts of products, variants and SKUs against the Magento source, plus spot checks of prices, stock and images.
5. Redirect and verify. Every old product URL resolves in one hop.

This sits inside the wider sequence covered in our guide to what moves cleanly in an e-commerce data migration, and every step has a line in our free Shopify migration checklist. For the platform-level picture — timeline, extensions and what changes for your team — start with our overview of migrating from Magento to Shopify.

FAQ

Can Shopify handle products with more than three options?

Not natively. A Shopify product has at most three options and 2,048 variants. Products with more dimensions are split into several products (optionally grouped with Combined Listings on Plus), have non-stock choices moved to line item properties, or use a product options app.

Do Magento custom attributes survive the move?

Yes, if they are mapped deliberately. Each one becomes an option, a metafield, a metaobject reference or a line item property depending on what it does. Attributes imported without a defined, typed metafield usually end up as text that cannot be filtered or reused in the theme.

Should I use an automated migration app for the products?

Migration apps are good at moving records and poor at making modelling decisions. They are a sensible way to execute a mapping you have already designed — check that the tool preserves configurable parent-child links and writes to the metafield definitions you created, then validate with a sample before the full run.

If your catalogue has unusual product types, deep attribute sets or customer-group pricing, that is where the effort sits — and it is what we scope first on any Magento to Shopify migration. You can also see how catalogue complexity shows up in the budget in our breakdown of what a Shopify migration costs.