Magento to Shopify migration

The usual trigger is running cost, not features. A Magento store needs hosting, PHP and Magento security patching, extension updates that break after upgrades, and PCI scope for a self-hosted checkout. Magento 1 stores have a harder deadline: Adobe ended Magento 1 software support on 30 June 2020, so anything still running it depends on community patches or a fork such as OpenMage.

Shopify is not the right target for every Magento store. If your business depends on deep B2B logic (shared catalogs, negotiated quotes, requisition lists), heavily customised checkout steps, complex multi-website pricing, or an ERP that writes directly into the Magento database, the assessment has to show how each of those works on Shopify before you commit. Sometimes the honest answer is a Magento 2 upgrade or BigCommerce.

The source version changes how data comes out. Magento 1 stores are usually extracted directly from the database, because the old SOAP/REST APIs are slow and incomplete, and the schema often carries years of abandoned extension tables. Magento 2 and Magento Open Source offer the native import/export and REST API, but we still read the database for attribute sets, URL rewrites and extension data that exports leave out.

Adobe Commerce adds features that have no one-to-one Shopify field: content staging (which versions EAV rows by row_id rather than entity_id, so a naive query can return scheduled future values), customer segments, reward points, store credit, gift card accounts and the B2B module. Each gets an explicit decision in the mapping sheet: migrate to an app, rebuild, or retire.

Magento stores product data across EAV tables, with attribute sets per product type and values that can differ per store view. Shopify has fixed core product fields, up to three option dimensions for variants, and metafields and metaobjects for everything else. We do not convert every Magento attribute automatically. We first measure which attributes are actually filled, shown on the storefront, used in layered navigation or sent to feeds, then design a metafield scheme with defined types, and drop or archive the rest.

Configurable products become Shopify products with variants: the configurable attributes become options and each simple child becomes a variant with its own SKU, price, weight, stock and image. A configurable product with more than three configurable attributes has to be restructured, usually by splitting it or by moving one attribute into a metafield. Simple children that were also sold individually need a decision too, because a Shopify variant is not also a standalone product page.

Bundle products, with selectable components and dynamic pricing, have no native equivalent in the Shopify product model; they are rebuilt with Shopify's bundle functionality or a bundle app, depending on how the bundle is priced and fulfilled. Grouped products usually become a collection or a product with linked complementary items. Magento custom options (text fields, file uploads, per-option price surcharges) move to a product options app. Tier prices and customer group prices move to Shopify B2B price lists where your plan includes it, or to an app.

A Magento category tree with anchor categories and layered navigation becomes Shopify collections plus menus and storefront filters. Collections are either manual or automated by rules such as tag, type or metafield value, and they are not nested; the hierarchy lives in the navigation menu. We rebuild the tree as collections, decide which categories really need their own landing page, and turn filterable attributes into metafield-based filters. Magento filter URLs with query parameters generally get no Shopify equivalent.

Customers, addresses, newsletter consent and customer group membership (as tags or B2B companies) migrate. Passwords do not: Magento stores salted hashes, and Shopify does not accept imported password hashes, so every customer sets a new password through an account invitation or on first login. We plan that invitation email with you.

Order history is imported as historical orders linked to customers by email and to products by SKU, which is why products are imported first. Historical orders keep dates, totals, tax lines and statuses for reference, but they do not re-trigger payments, fulfilment or notifications. Invoices and credit memos are summarised onto the order or archived.

Magento URLs come from the url_rewrite table (core_url_rewrite on Magento 1): product URL keys, often with a .html suffix, sometimes with the category path in the product URL, and different keys per store view. Shopify uses fixed paths: /products/{handle}, /collections/{handle}, /pages/{handle} and /blogs/{blog}/{handle}. Almost every Magento URL therefore changes, so the redirect map is a core deliverable, not an add-on.

We build the map from four inputs: the Magento rewrite table, a full crawl of the live site, Search Console pages with impressions, and URLs that have external backlinks. Every indexable URL gets a destination: the matching product or collection, a parent collection, or a deliberate decision to let it 404. The redirects are imported into Shopify's URL redirects before launch. Shopify only applies a redirect when the old path no longer loads a page, and filtered or parameterised URLs behave differently from plain paths, so both are checked in the trial.

After launch we crawl the old URL list against the live store, check status codes and destinations, resubmit the sitemap in Search Console and watch coverage and 404 reports. That reduces avoidable SEO loss; no migration can promise unchanged rankings.

Magento separates websites, stores and store views, and teams use them for languages, countries, currencies and sometimes separate brands. On Shopify, languages, currencies and country-specific settings are handled by Shopify Markets in one store, with translations stored per field and managed through Translate & Adapt, a translation app or CSV import. Store-view product names, descriptions and URL keys become translated fields and localised handles.

Separate Magento websites with their own catalog, prices or brand usually become separate Shopify stores, or on Plus a set of stores managed together. Hreflang is checked after launch.

Themes and extensions do not migrate. We list every active extension and custom module from the codebase and database, then classify each one: replaced by a Shopify feature, replaced by an app, rebuilt as a custom app, or retired. Data stored by extensions (reviews, loyalty balances, blog posts, gift card accounts) is exported and imported into the chosen app where it provides an import path.

Checkout customisation on Shopify is deliberately limited; on Plus it uses Checkout Extensibility and Shopify Functions for discounts, payment and delivery rules. Cart price rules become Shopify discounts or Functions, and some multi-condition Magento rules need simplification. Stored payment tokens are never moved silently; whether they can move depends on the gateway and its PCI transfer process. The Magento theme is rebuilt as a Shopify theme.

The sequence is audit, mapping, trial migration, sign-off, freeze and delta migration, launch and post-launch QA. The audit covers data volume, attribute usage, extensions, integrations and indexed URLs. The mapping sheet records where every Magento field and entity goes on Shopify. The trial migration loads a full or representative dataset into a development store, and you check products, prices, variants and redirects before anything is final. Automated comparison flags differences; a person decides what is correct.

At launch we agree a short content freeze on Magento, migrate new orders, customers and stock changes since the trial (the delta), switch DNS, activate redirects and run the post-launch QA checklist.