Of all the platforms I've moved stores off, Magento is the one that worries me most. Not because it's badly built. Because a Magento store that's been running a decade has a URL history you can't see by looking at the site, and that's exactly where the traffic goes.
The generic problems apply here too: redirects left until after launch, architecture redesigned in the same release as the platform change, blog archives quietly binned. Those are all in the Shopify migration mistakes that cost you organic traffic. This is the other half, the bits that belong to Magento.
Magento's URL history is a database table, not a crawl
Crawl the live site and you get the URLs Magento is serving right now. Pull the url_rewrite table and you get every URL Magento has ever served and still honours.
Those are very different lists. Ten or fifteen years of product renames, category moves, seasonal landing pages and, very often, an old Magento 1 to Magento 2 migration all leave entries behind. Those paths still resolve, still 301 to something, and still have external links pointing at them.
So if your plan starts and ends with a crawl, you'll map the current set correctly and silently drop everything sitting behind it. Every link pointing at those old URLs stops passing anything the day Magento gets switched off.
The inventory on a Magento site is three sources, not one: the crawl, twelve months of Search Console, and a url_rewrite export. Then flatten it. If an old URL currently chains through two Magento rewrites to get where it's going, point it straight at its Shopify URL in the new map. Don't carry the chain across.
The .html suffix means every URL changes, even the ones that look identical
Magento ships with .html as the default suffix on category and product URLs, so you've got /womens/knitwear.html and /womens/knitwear/aran-jumper.html. Shopify has no equivalent setting and no concept of a suffix.
Sounds trivial. It causes a scoping error nearly every time. Someone exports a list of slugs, sees the handles carrying over more or less unchanged, and decides the redirect job is smaller than it is. It isn't. Not one URL on that site is staying the same, because the suffix guarantees a change even where the slug is identical.
Decide the suffix rule once, apply it across the whole map, and make sure whoever's scoping the redirect work knows that the answer to "how many URLs are changing?" is "all of them".
The same product on three different URLs
Magento has a setting called Use Categories Path for Product URLs. Switch it on and a product sitting in three categories is reachable at three category paths plus its bare product path. Canonicalisation is a separate setting, it's frequently inconsistent, and on older stores it's often just wrong.
Which means you can't tell from the URL structure which version of a product page earned the traffic. The canonical tag tells you what the store intended. Search Console tells you which URL Google actually ranked and sent clicks to, and on a badly canonicalised Magento store those are regularly not the same page.
All those variants need a redirect to the single Shopify /products/ URL. Pick the destination from the performance data, not from the configuration.
Layered navigation is where the ranking pages hide
This is the Magento trap that costs the most and gets spotted the latest.
Plenty of Magento stores have deliberately opened part of their layered navigation to indexing: colour, size, brand, material. On a big catalogue a handful of those filtered pages can be earning serious money. "Womens black waterproof jackets" is a real query with real intent, and on Magento it might be a faceted URL rather than a category.
Shopify's nearest equivalent is /collections/<handle>/<tag>, and it isn't the same thing. It's built from product tags rather than attributes, the URL format's different, and plenty of themes noindex it by default. So a filtered Magento page that ranks might have no natural Shopify destination at all.
Where the page is genuinely earning, build it a proper collection and point the redirect there. What you can't do is assume the tag URL inherits the ranking, because in most themes it isn't even indexable.
Find these before the collection structure gets signed off. Once the build team's finished the navigation, twenty new collections is a change request rather than a decision.
Store views become Markets, and hreflang starts again
If you're running store views with codes in the path, like /uk/, /en/ or /de/, that structure doesn't carry across. Shopify Markets does international with subfolders, subdomains or separate domains, the mapping isn't one-to-one, and the hreflang cluster has to be rebuilt from scratch rather than translated.
If you've got meaningful international organic traffic, this is where it goes, and it goes quietly. Give it its own workstream and its own before-and-after measurement, rather than burying it in the redirect map.
CMS pages have arbitrary paths, and Shopify pages don't
Magento CMS pages live wherever you put them. /size-guide, /about/our-mill, /brands/some-brand, /how-to-measure. On a store with a long history there are usually more of them than anyone remembers, and some are buying guides that rank well and convert.
Shopify puts every page at /pages/<handle>, with no nesting. So an information architecture that lived in the path structure becomes a flat set of pages, held together only by internal links somebody now has to add on purpose.
Two jobs, then. Map the paths, and rebuild the linking the paths used to do for you.
Shopify's redirect tool won't do what a Magento site needs
This is the one that gets discovered in launch week, which is exactly the wrong time.
Shopify's built-in URL redirects are literal and one-to-one. No native regex, no wildcard, no pattern rule. That's fine for a small store. It isn't fine for a Magento site with tens of thousands of entries in url_rewrite, where most of the map is the same transformation over and over: strip the suffix, drop the category path, move the prefix.
So decide early how the rules actually get delivered. Bulk CSV import, an app that does pattern matching, or a proxy or CDN layer sitting in front of Shopify. Make that call during the build, because it changes what you're allowed to do with the URL structure.
Leave it and you get the predictable outcome. A team that finds out in launch week that every rule has to be hand-written will start hunting for reasons to send big groups of URLs to a category page. That's how a dip becomes a drop.
What this means for how you scope the work
On Magento, what you're protecting is the category tree and the URL history sitting behind it. The bulk of the SEO effort lands early, before the collection structure and the URL rules are locked. And the inventory work is bigger than it looks, because a crawl on its own doesn't cover it.
That isn't the shape of every migration. A WooCommerce to Shopify migration has a different centre of gravity: the blog archive is usually carrying more organic traffic than the product categories are. Protect the wrong half and you'll lose traffic whilst doing a lot of careful work.
A Magento-specific pre-launch checklist
Assume the generic ones from the mistakes article are covered. On top of those:
- A
url_rewriteexport taken and reconciled against the crawl and Search Console, with chains flattened to a single destination. - The
.htmlsuffix rule decided once and applied across the entire map. - Category-path product duplicates collapsed, with the destination picked from performance data rather than from the canonical tag.
- Indexed layered-navigation URLs identified, and each one either given a proper Shopify collection or knowingly written off.
- Store views mapped to Markets, with the hreflang cluster rebuilt and tested rather than assumed.
- CMS page paths mapped, and the internal linking the old path structure used to imply rebuilt explicitly.
- The redirect delivery mechanism chosen, built and tested at full volume before launch week rather than during it.
None of it's difficult. All of it takes longer than a week, which is the actual reason it gets skipped.
If you're planning a move off Magento, or you've already made one and the numbers haven't come back, here's how I work on Shopify migrations.
