Three buckets. Every custom attribute in your Magento catalogue ends up as a Shopify variant option, a metafield, or nothing at all, and the split is decided by one question: does the attribute change price, SKU or stock? If yes, it is a variant option, and you get three of them. If it only describes or filters the product, it becomes a metafield. If it exists to make Magento's admin work, it dies on the way over. Most of the pain in a Magento custom attributes Shopify migration comes from teams discovering the third bucket after go-live instead of before the export.
Here is how we sort a catalogue before any data moves.
Run an attribute census before you write a mapping file
Open your Magento database and count actual usage, not attribute definitions. Join eav_attribute to catalog_eav_attribute, then count non-null values per attribute code against products that are enabled and visible. A store that has been running since Magento 1 will typically have several hundred attribute codes and a long tail with values on a handful of discontinued SKUs.
That census is the single most useful artefact of the whole project. It tells you which attributes the merchandising team believes are important and which ones the data says are important, and those two lists are never the same. In every Magento migration we have run, a meaningful chunk of attributes turn out to be empty, duplicated (colour, color, colour_family) or filled with values nobody has read since 2019.
Kill those first. Migrating an attribute costs you a metafield definition, a theme edit, an import column and a permanent maintenance burden. Shopify caps metafield definitions per resource type (200 for products at the time of writing), so a 400-attribute Magento catalogue physically cannot come across intact even if you wanted it to.
Which Magento attributes become Shopify variants
Only the ones used as configurable axes, and only three of them. Magento lets a configurable product have four or five global dropdown attributes: size, colour, width, inseam, finish. Shopify gives you three option names per product, 100 variants by default, and up to 2,048 on the newer product model where your theme and apps support it. Assume 100 until you have tested otherwise, because plenty of third-party apps still choke above it.
When a product needs four axes, you have four honest choices:
- Merge two axes into one option value. Waist and inseam become "32/34". Ugly in a swatch, fine in a dropdown, and it keeps inventory accurate per combination.
- Split into separate products. One product per finish, linked by a metafield or a shared tag. Better for SEO on high-intent terms like "brushed brass tap", worse for the PDP experience.
- Combined Listings. Shopify's app groups separate products into one PDP with a shared switcher. It solves the four-axis problem properly, and it is Plus-only. If this is the deciding factor in a plan upgrade, talk it through with a Shopify Plus agency before you commit to the annual contract, because it rarely justifies the price on its own.
- Line item properties. A dropdown or text field on the PDP that writes onto the order, with no inventory or price of its own. This is the correct home for Magento's per-product custom options, which are not attributes at all: engraving text, gift message, upload-your-artwork. Do not try to force them into variants.
One thing that carries across cleanly: option values themselves. Magento's admin swatch and text swatch attributes map onto Shopify's colour and button swatches, and since Shopify added native swatch metaobjects you no longer need a theme hack to show a fabric image on the option selector.
Which attributes become metafields, and what type to pick
Everything descriptive. The mapping is mostly mechanical once you know Magento's frontend input types:
- Dropdown becomes single_line_text_field with a choices validation, so merchandisers cannot invent a fourth value for "Sleeve Length" at 11pm.
- Multiple Select becomes list.single_line_text_field. This is the one that matters most for filtering later.
- Yes/No becomes boolean.
- Date becomes date, not text. Text dates will break sorting in every app that touches them.
- Price attributes become number_decimal. Shopify will not attach a currency to it, so name the definition accordingly.
- Text Field becomes single_line_text_field, and Text Editor becomes multi_line_text_field or rich_text.
That last one is where migrations quietly go wrong. Magento's WYSIWYG attributes hold raw HTML. Shopify's rich_text metafield stores a JSON document with its own schema, so you cannot paste HTML into it: you need a converter in the import pipeline. The shortcut is to store the HTML in a multi_line_text_field and output it directly in Liquid, which works because Liquid does not escape by default. The cost is that your team sees raw tags in the admin. For an attribute like Care Instructions that gets edited weekly, spend the effort on proper rich text. For a legacy spec blob nobody touches, the shortcut is fine.
Two settings to get right at definition time rather than later. Tick storefront access or the theme cannot read the value. Tick translatable if the Magento attribute had store-view scope and you intend to run Shopify Markets, because retrofitting translations onto a definition that was not marked translatable means recreating it and re-importing every value.
Variant-level attributes need variant metafields
In Magento, every simple product under a configurable is a full product with its own attribute values: its own barcode, its own country of manufacture, its own weight. Shopify variants are thinner. They carry price, SKU, barcode, weight, HS code, country of origin and inventory, and that is it.
Anything else that differs per variant has to go into a variant metafield. They work, they are readable in Liquid via variant.metafields, and the admin experience for editing them in bulk is poor. If you have 4,000 variants each with six variant-level attributes, plan on managing that data through Matrixify or the API permanently, not through the Shopify admin.
When a metafield is not enough: metaobjects
Some Magento attributes are really references to an entity. Brand is the obvious one: you have a brand attribute with 90 options, plus a brand logo, plus a brand description page built with a third-party extension. Flattening that into a text metafield throws away the logo and the description.
Build a metaobject instead. Define brand with fields for name, logo, description and handle, create one entry per brand, and point a product metafield of type metaobject_reference at it. Same pattern for materials, certifications, collections-in-the-fashion-sense and size charts. Size charts especially: a metaobject per chart, referenced from the product, beats a metafield holding a table of HTML that someone has to maintain product by product.
Which custom attributes to drop before the migration
Say the unwelcome part out loud in the kick-off meeting, because these have no Shopify equivalent and pretending otherwise wastes weeks:
- attribute_set_id and the attribute sets themselves. Shopify has no attribute sets. Product type plus a metafield definition scoped by type is the nearest thing, and it is not enforced.
- Tier prices and customer group prices. These need B2B catalogs on Plus, or a wholesale app. They are not a product field.
- special_price with from/to dates. Compare-at price plus a scheduled discount covers the common case. Per-SKU scheduled price changes across thousands of products need an app or a script.
- Fixed Product Tax, tax_class_id, WEEE. Shopify handles tax by store and collection overrides, not per attribute.
- Visibility "Search only" / "Catalog only". Shopify products are published to a channel or not. The workaround is a hidden collection and template logic, and it is worse than what you had.
- Minimum and maximum qty allowed in cart, qty increments. Cart validation on Shopify means Functions, which means Plus, or an app that runs on the cart page and can be bypassed.
- Media image roles. Magento's base, small, thumbnail and swatch roles collapse into one ordered image list. Position one is the featured image. Carry your alt text across; it is the only image metadata Shopify keeps.
Keep the Magento entity_id in a hidden metafield, though. When the ERP or the returns platform needs to reconcile old orders against new products six months later, you will be very glad it is there.
Filtering breaks unless you plan for it
Layered navigation is the feature Magento merchants miss most in the first month after switching. In Magento, ticking "Use in Layered Navigation" on an attribute was enough. On Shopify, only metafields of certain types can be turned into storefront filters, list-type metafields behave differently from single-value ones, and Shopify's own Search & Discovery app caps how many filters you can publish.
For a catalogue with 30 filterable Magento attributes, native filters will not get you there. That is the point at which you either accept a shorter filter set or install something built for it. Our own FilterPro reads metafield values as filters and adds AI search on top, which is usually the cheapest way to keep the faceted navigation your customers were used to.
Decide this before the import, not after. Which metafields drive filters determines their type, and changing a definition's type after 8,000 products carry values means a full re-import.
The India-specific attributes people forget
Indian Magento stores carry a set of attributes that no generic migration tool knows about. HSN code and GST rate belong in product metafields with fixed handles, because your invoicing app will read them by handle and silently produce wrong invoices if the handle changes. FSSAI licence number, veg or non-veg mark, net quantity and best-before belong in metafields rendered on the PDP, since the legal metrology requirements do not go away because you changed platforms.
COD eligibility is the awkward one. A per-product "COD not allowed" flag is trivial in Magento. On Shopify, storing the flag as a metafield is easy; acting on it at checkout means a payment customization function, which is Plus, or a COD app with its own trade-offs. If a large share of your revenue is cash on delivery and you block it on specific SKUs, price that constraint into the migration plan rather than discovering it in UAT.
Sequence that actually works
Census first. Then agree the three buckets with merchandising in writing, attribute by attribute, and get someone to sign off the drop list. Then create every metafield definition and metaobject in Shopify manually, with the right types and validations, before a single product is imported. Then import products and variants. Then import metafield values as a separate pass, so a bad value in one column does not fail the whole product record.
Redirects are a separate workstream. Magento URL keys will not survive as Shopify handles, and layered navigation URLs with query parameters have earned links you would rather keep. Map them before DNS changes, not after traffic drops.
If you want a second opinion on your attribute list before committing to a build, send us the census output and the frontend of your current store and we will tell you which attributes are worth carrying. Our Magento to Shopify migration page covers the wider scope, and a free audit is the quickest way to find out whether the catalogue fits Shopify's data model as it stands or needs restructuring first.