Attribute sets, configurable and bundle products, store views, customer groups and price rules all have to be reconsidered rather than transferred.
Magento exports everything, including the structures Shopify does not have.
Magento and Adobe Commerce stores generally have complete, well-structured data and direct database access. The difficulty is not extraction. It is that a decade of configuration has to be reviewed rather than transferred.
Magento models products through attribute sets, so a store commonly carries dozens of attributes per product type, many of them used for filtering, some for display, and a proportion for nothing at all since a project three years ago. Shopify has options, variants and metafields. Mapping between the two is a catalogue design exercise, and doing it faithfully rather than thoughtfully reproduces every abandoned attribute in a new system.
Configurable, bundle, grouped and virtual products are the second theme. Configurable products usually translate to Shopify variants. Bundles and grouped products do not have a direct equivalent, and the right answer depends on whether the bundle is a merchandising device, a pricing device or an inventory device.
Then there are the structures Magento is chosen for in the first place: multiple websites and store views, customer groups with tier pricing, catalogue and cart price rules, and the integrations behind them. Those are the parts of the project that decide whether Shopify, Shopify Plus with B2B, or a different destination is the honest recommendation.
Confirmed against your instance, not assumed from this table.
| Entity | Normally transfers | Where a decision is needed |
|---|---|---|
| Simple and configurable products | Yes, with configurables mapping onto Shopify variants | Which attributes become options, which become metafields, and which are retired |
| Bundle and grouped products | Not directly | Whether each is really a bundle, a kit or a merchandising grouping, and what replaces it |
| Attribute sets | As metafield definitions, once reviewed | Which attributes are still used for filtering, display or nothing |
| Categories | Yes, as collections | Deep category trees flatten, so hierarchy moves into navigation and internal linking |
| Customers | Yes, without passwords | How customer groups are represented on the destination plan |
| Orders | Usually, as historical records | How many years to carry, given the volume most Magento stores hold |
| CMS pages and blocks | Content transfers, layout does not | Which blocks were structural and now belong in theme sections |
| Price and cart rules | Not directly | Which rules are still active, and how each is reproduced on Shopify |
Magento stores frequently carry more historical order data than the business needs in the storefront. Archiving rather than importing is a legitimate answer, and it changes the price.
These decide the destination plan, so they are settled early.
Magento’s multi-site hierarchy is often used for languages, regions, brands or trade and retail at once. On Shopify that becomes markets, expansion stores or a single store with careful catalogue rules, and the three have materially different costs.
Group-based catalogue pricing is native to Magento and is not native to standard Shopify. Reproducing it depends on the plan and on how the trade relationships actually work, and it should be scoped before anyone promises a like-for-like move.
Years of promotional rules accumulate, and many are inactive. The live ones are reproduced with Shopify discounts, scripts or functions depending on the plan. The rest are documented and retired rather than carried forward.
Magento stores usually sit behind an ERP, a PIM or a middleware layer. Those connections are the reason the platform was chosen, and rebuilding them is frequently the largest single line in the project.
Decide what the complexity was buying before deciding how to replace it.
Magento URL structures are configurable, so the map has to be read, not assumed.
A Magento store’s routes come from its rewrite table and its URL settings, both of which vary between instances. The map is built from the live site and the rewrite data rather than from a template.
Magento instances frequently carry redirects from a previous platform. Chaining a new redirect on top produces multi-hop routes, so the map is rebuilt to point at the final destination directly.
On a Magento replatform, the systems work usually outweighs the storefront work.
Swipe the parts
Design
Magento storefronts are often heavily customised, and the temptation is to reproduce them. A replatform is a better moment to simplify: implement a solid theme and spend the difference on catalogue structure and the integrations.
Systems
ERP, PIM, tax, despatch and any middleware in front of them. Each connection is inventoried, and each is either replaced, rebuilt or retired with a named owner.
Proof
Large catalogues are validated in stages: a sample, then a segment, then the full run, with counts reconciled per entity against the source database at each stage.
Switch
A delta run, a planned switch at a low-traffic hour, and the Magento instance kept running read-only until the new store is proven in trading conditions.
Magento projects are priced from structure and systems, not SKU count.
These are the factors that separate a straightforward Magento move from a long one.
Magento migrations with B2B pricing, multi-store structures or ERP-driven catalogues route to manual scoping rather than an estimator band, because the range would be too wide to be useful.
Published starting figures in GBP and USD, excluding VAT.
Scoped after source review
Data only
From £1,000From $1,300
Products, customers, orders and content mapped into a Shopify store that already exists or is priced separately. Fixed once source access and a sample migration are reviewed.
Starting price · scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Multi-store, B2B and ERP-driven Magento migrations are scoped after discovery. A published figure before the attribute sets and integrations have been reviewed would be a guess.
For most catalogues, yes, and for some configurations the honest answer is that it depends on the plan. Multi-market structures, customer-group pricing and complex B2B rules need Shopify Plus or a rethink of the requirement. We would rather establish that in discovery than during a build.
They are reviewed rather than transferred. How they are reproduced depends on your destination plan and on what the groups are really doing: trade pricing, access control, tax treatment or a mixture. Each of those has a different Shopify answer.
No, and often you should not. Historical orders can be archived outside the storefront while a recent window is imported. That decision is worth making early, because order volume is one of the larger cost drivers.
It can be approximated, but reproducing a heavily customised storefront on a different platform is usually the most expensive way to spend a replatform budget. We normally recommend a restrained implementation and putting the difference into catalogue structure.
Those two, plus the store-view structure, size a Magento replatform faster than a catalogue count.
