A Magento to Shopify migration is two projects wearing one name. The first is a data project: catalog, customers, orders and content moved without loss. The second is a search project: every URL that earns traffic today still resolving to the right page tomorrow. Teams that treat it as one project almost always underestimate the second, and the traffic dip that follows is the most expensive part of the whole exercise.
This guide is the sequence we use on real replatforms, plus the SEO checklist we will not launch without. It is deliberately platform-honest: there are stores that should not move off Magento, and we say where. If you would rather have someone own the risk end to end, that is our e-commerce replatforming service.
First, decide whether you should move at all
Shopify wins on operational cost. You stop paying for infrastructure, patching, PCI scope and the upgrade treadmill, and your team spends its time on merchandising instead of maintenance. For most mid-market DTC brands that trade is straightforwardly worth it.
It is a worse trade when your store depends on things Magento does natively and Shopify does not:
- Deep B2B mechanics — contract pricing per customer with approval hierarchies and quote negotiation. Shopify B2B has closed much of this gap, but complex quote-to-cash still fits Magento better.
- Very large or highly variant catalogs — hundreds of thousands of SKUs, or products with variant counts beyond Shopify's limits, need a rethink rather than a mapping.
- Multi-source inventory across many warehouses with allocation rules Magento models directly.
- Heavy customization you actually use — if the business logic in your Magento modules is genuinely differentiating, moving it into apps and Functions is a rebuild, not a migration.
If two or more of those describe you, read Magento development and Hyvä theme development first — a Hyvä frontend and a version upgrade often deliver the speed and cost win people expect from a replatform, at a fraction of the risk.
Take an inventory before you touch anything
The migration scope is whatever exists, not whatever the brief remembers. Export and count:
- Catalog — products, variants, categories, attributes and attribute sets, media, downloadable and bundle products, related and cross-sell links.
- Customers — accounts, addresses, customer groups, store credit, loyalty balances, subscription contracts.
- Orders — historical orders, invoices, shipments, credit memos. Decide early how much history moves into Shopify versus stays queryable in an archive.
- Content — CMS pages, blocks, blog posts, and every static page that ranks or is linked from email.
- URLs — the full URL set, joined to Search Console and analytics data so you know which ones actually earn.
- Integrations — ERP, PIM, OMS, WMS, tax, payment, email, reviews, search. For each: what it reads, what it writes, and what breaks if it stops for an hour.
- Redirects you already have — the 301s from your last migration. They chain, and chains break.
The migration sequence, step by step
- Set up Shopify properly first. Markets, currencies, tax regions, shipping profiles and payment gateways. Getting markets wrong later means re-doing URLs.
- Model the catalog in Shopify terms. Magento attribute sets become metafields and metaobjects; configurable products become variants; categories become collections, manual or automated. This mapping decision is the one that constrains everything after it — spend real time on it.
- Migrate the catalog into a development store. Automated where the mapping is clean, scripted where it is not. Reconcile counts by category, not in total: a matching grand total hides two errors cancelling out.
- Migrate customers. Accounts and addresses transfer; Magento password hashes do not, so plan the reset communication as a marketing task, not an afterthought.
- Migrate order history. Import as historical orders so support and returns keep working. Be explicit about how much history you carry, and archive the rest somewhere queryable.
- Build the theme, or the Hydrogen storefront. Rebuild the templates that matter — home, PLP, PDP, cart, checkout, account — rather than recreating every legacy page. Hold a performance budget from day one; a slower store after replatforming is a real and common outcome.
- Rebuild the integrations. ERP, PIM and OMS connections against Shopify's Admin API, with idempotent writes and a replay path. Test the failure modes: timeouts, duplicate webhooks, partial writes, stale inventory.
- Build the URL map. Old URL to new URL, every row reviewed. This is the step teams rush, and it is the step that decides whether traffic holds. Details in the next section.
- Run both stores in parallel. Shopify on a staging domain with real data, reconciled against Magento daily, while your team does real merchandising and support work in it.
- Cut over on a quiet day. Freeze the catalog, run the final delta migration, flip DNS, deploy redirects, submit sitemaps, then watch. Not on a Friday, and not in peak season.
- Hypercare for two weeks. A named team watching orders, errors, crawl stats and rankings daily, with a documented rollback path for the first 48 hours.
SEO preservation: the checklist we will not launch without
Rankings are lost in the gap between the old URL set and the new one. Everything below is mechanical — which is why skipping it is unforgivable rather than unlucky.
1. Build the URL map from data, not from the sitemap
Join a full crawl of the old site to Search Console impressions, analytics sessions and backlink data. Sort by value. Every URL with traffic, rankings or external links needs an explicit destination reviewed by a person. Bulk pattern rules cover the long tail; they are not enough for the head.
2. One 301, no chains, no loops
Each old URL redirects once, straight to its final destination — not through two prior migrations' worth of hops. Watch the details that generate near-duplicates: trailing slashes, uppercase paths, tracking parameters, and Magento's .html suffix, which Shopify does not use. Shopify also imposes its own path prefixes (/products/, /collections/, /pages/, /blogs/), so almost nothing keeps its old shape.
3. Redirect to relevance, and never to the homepage in bulk
A retired product goes to its category or to its closest replacement, not to /. Mass redirects to the homepage are treated as soft 404s and lose the equity you were trying to keep.
4. Keep the on-page signals
- Titles and meta descriptions transferred deliberately — this is a good moment to improve them, but do it as a decision, not by accident of template defaults.
- One
<h1>per page, carrying the same topic as before. - Canonical tags self-referencing, and pointing at the canonical variant for filtered and paginated collection URLs.
- Structured data rebuilt:
Productwith offers and availability,BreadcrumbList,Articleon blog posts,Organizationsite-wide. Validate with the Rich Results test before launch, not after. - Image alt text carried across — it is part of what image search ranks on.
hreflangcorrect for every market pair if you sell internationally, including thex-default.
5. Do not accidentally block the crawl
Shopify development stores are password-protected and noindex. Removing that protection at launch, and checking robots.txt and every template's robots meta tag on the live domain, belongs on the cutover checklist. A store that launches noindex can lose weeks.
6. Preserve internal linking
Internal links are a ranking signal, and rebuilt navigation quietly drops them. Compare internal link counts to your top pages before and after; where a page lost its links, put them back in navigation, collections or body copy.
7. Submit and monitor
- New XML sitemap submitted in Search Console on cutover day; old sitemap left reachable for a few weeks so Google recrawls the redirecting URLs.
- Use the Change of Address tool only if the domain changes — not for a platform change on the same domain.
- Watch crawl stats, coverage and 404s daily for two weeks, then weekly for a quarter.
- Expect and budget for a dip. A well-run replatform typically sees a modest, short-lived drop that recovers within four to eight weeks. A flat line is a bonus, not the plan — and anyone promising you zero movement is selling.
What Shopify will not do the way Magento did
Set expectations with your team before launch, not during it:
- Checkout customization is bounded. Plus gives you Checkout Extensibility and Functions, which is real power inside safe limits.
checkout.liquidhacks are gone, and that is a feature. - No SQL access. Reporting that used to be a database query becomes an API integration or a BI connector.
- Apps replace modules, with a monthly cost. Add the app subscriptions to your total cost of ownership before you compare it to Magento hosting.
- Variant and API limits are real. Check yours against the current Shopify limits early, because working around them late is expensive.
Timeline, cost and team
A single-market DTC store with a clean catalog and two or three integrations is typically eight to twelve weeks. Multi-market, B2B, or an ERP-integrated catalog runs sixteen to twenty-four. The variables that actually move the number are catalog complexity, integration count and how much order history you insist on carrying.
The team is a lead engineer, a Shopify developer, a data/integration engineer, a QA engineer and a merchandiser from your side who owns the catalog decisions. That last role is the one most often left unfilled, and its absence is what makes migrations slip.
The first 30 days after launch
- Daily: order volume against forecast, payment failures, 404s, error rates, Core Web Vitals on real traffic.
- Weekly: Search Console coverage and impressions by page group, rankings for your head terms, redirect hit rates.
- Once stable: delete the dead weight — unused apps, orphaned collections, redirect rules that never fire.
We run this as a fixed-scope engagement, with the URL map and the SEO checklist as named deliverables rather than good intentions: e-commerce replatforming and migration services. If you would rather keep it in-house, you can also hire Shopify developers to sit inside your own team for the build.
Start a project