Magento to Shopify Migration

Content Staging is the first thing to check, because it is the one with no replacement anywhere. Scheduled, previewable campaigns spanning prices, catalogue, CMS content and promotions — Adobe’s own documentation calls it "an exclusive feature that is available only in Adobe Commerce". Shopify has nothing comparable: no campaign object holding a set of changes with a start date, an end date and a preview. A merchant running seasonal trading this way loses the workflow, not just the tooling, and the replacement is an app, a scripted change through the API, or somebody awake at midnight.

Then the checkout wall, which is where Magento migrations most often go sideways. Magento’s checkout is yours to rebuild — a layout you can extend arbitrarily. Shopify’s is not. Checkout UI extensions on the information, shipping and payment steps are Plus-only, and non-Plus stores in the US and Canada cannot customise credit card fields at all. Below Plus you get branding. Teams accustomed to unlimited checkout freedom discover this mid-project, at which point it has become a subscription decision rather than a development task.

Page Builder output — rows, columns, dynamic blocks — has no import path into JSON templates and Liquid sections. Every Page Builder page is rebuilt. Same for the admin habits around it: the people who assemble campaign pages today are learning a different tool, and that retraining is real project time.

Magento’s EAV attribute sets support effectively unlimited custom attributes, and a configurable product can differentiate on as many of them as the merchandiser wants. Shopify allows 3 options per product and 2,048 variants. The variant headroom is rarely the problem; the option ceiling always is. Any configurable product differentiating on more than three attributes cannot be a single Shopify product — the excess attributes move into metafields, where they stop driving price and inventory, or the product splits and is reassembled with Combined Listings.

Customer groups in Magento do two jobs at once. Adobe’s documentation is explicit that they "determine which discounts are available and the tax class that is associated with the group". Shopify has no single object that does both. The group matrix decomposes into two separate configurations — segments and discounts on one side, tax settings on the other — and wherever a group was quietly doing both jobs, someone has to decide which one it was really for.

Tax is the sharpest mismatch in the family. Magento tax rules are a genuine three-axis matrix: product tax class by customer tax class by rate, with overlapping rules that add or compound according to priority. Shopify Tax has no compounding model. A store relying on compounded rules is not remapping a table — it is re-deriving what the correct effective rate actually is for each combination, and then finding a way to express that answer in a system that cannot compound. Do that with the finance team in the room, not the developers.

Multi-Source Inventory models Sources, Stocks, and the assignment of Stocks to sales channels, with a salable quantity computed after reservations. Shopify has multi-location inventory, which sounds equivalent and is not: there is no Stock object aggregating Sources for a channel, and no reservation layer of that kind. It is re-modelled rather than mapped, and a store using MSI seriously should treat that as its own workstream.

Magento URLs are uniform, with one binary toggle that changes all of them. URL keys auto-generate from the product name, the .html suffix is a separate system-configuration setting, and "Use Categories Path for Product URLs" is off by default. Off, Adobe’s own worked example is /helena-hooded-fleece.html. On, the same product is /women/tops-women/helena-hooded-fleece.html. Category URLs always carry their full nested path either way.

So find that toggle before scoping anything. With it on, every product URL loses a category prefix and an .html suffix on the way to /products/{handle}, and every nested category URL collapses to a flat /collections/{handle}. That is a structural collapse rather than a search and replace, and because Magento category paths carry depth that Shopify collection URLs cannot express, parts of the redirect map are many-to-one.

The .html suffix deserves its own line, because it is the detail that survives a careless migration and then turns up as 404s weeks later: it exists on every product URL, it has no Shopify counterpart, and it is invisible in a spreadsheet of handles.