Articles · Platform & Pricing
How to migrate from Magento to Shopify
Published
Almost nobody arrives at this decision because they want a new platform. They arrive because something forced it: an end-of-life notice, a licence renewal, a security patch nobody can apply, or a quote for an upgrade that costs more than the store earns in a quarter.
Why this decision arrives when it does
Magento 1 reached end of life in 2020, and the stores still on it are running unsupported software that no longer receives security fixes. Magento 2 is supported, and the bill that comes with it is the more common trigger: hosting, a developer on retainer, extension licences and an upgrade cycle that has to be paid for whether or not it adds anything a customer would notice.
That is worth naming plainly, because it changes what the project is. This is rarely a technology decision. It is a decision about where the money goes, and the honest comparison is not Magento against Shopify as software. It is your annual platform and maintenance bill against what the same money buys if it is spent on the storefront instead.
What actually moves, and what quietly does not
A Magento to Shopify data migration covers more than people expect on the records and less than they expect on the behaviour. Products, variants, categories, customer accounts and order history all transfer. Reviews usually transfer, through whichever app you land on. Blog content transfers.
What does not: every extension, every custom module, and the theme. On a store that has been live for a decade, that is the substance of the project. Each piece of bolted-on Magento functionality has to be identified, and then one of three things happens to it. It is native on Shopify and disappears as a line item. It becomes an app. Or it gets built.
The useful surprise is how often a fourth answer applies: nobody can explain what it was for and nobody misses it. Going through that list honestly is the single biggest lever on what the migration costs, and it is work a merchant can start before choosing an agency.
The order to do it in
Treat this as a Magento to Shopify migration checklist rather than a schedule. The order matters more than the dates, because three of these steps are cheap now and expensive later.
- Audit the catalogue before anything else. Which products are still sold, which attributes are still meaningful, which categories exist only because somebody made them in 2016. Migrating a mess produces a mess with better hosting.
- List every extension and what it does. Then mark each one native, app, build or drop. This list is the scope.
- Export the full URL inventory. Every product, category and content page, with its traffic. You need it for the redirect map and you cannot reconstruct it after the switch.
- Map the integrations. ERP, accounting, warehouse, feeds, subscriptions. Each one is a project in miniature and they are routinely discovered late.
- Move the data into a development store. This is the part an app does well, and it should be rehearsed more than once rather than performed once on launch night.
- Build the front end. Longest phase, and the one the customer actually sees.
- Write the redirects, and test them against the inventory from step three.
- Freeze, final data sync, switch, and watch. Orders placed during the switch window are the thing to have a plan for.
URLs are where migrations actually fail
If one thing on this page is worth over-doing, it is this. Magento and Shopify build product and category URLs differently, and Shopify imposes structure that Magento does not. So essentially every address on the site changes, and every one of them needs a permanent redirect to the closest equivalent.
The failure is rarely total. It is partial, quiet and discovered late: the top hundred URLs get mapped carefully, the long tail is handled by a catch-all to the homepage, and three months later the pages that used to bring in traffic are gone from the index with nothing pointing at what replaced them. Map the tail as well, to category level where an exact match no longer exists.
What drives the cost
We are not going to put a number on this page, because the honest answer is that the Magento to Shopify migration cost is driven by four things and none of them is turnover.
- Catalogue and attribute mess. A clean catalogue of 40,000 products is a smaller job than a chaotic one of 400.
- Integrations. Each system that has to keep talking to the store is scoped separately and is where estimates move most.
- Custom functionality. Whatever came out of the extension audit as build rather than native.
- URL count. Mapping is not hard, it is long, and it scales with the size of the old site.
Any agency quoting before it has seen the catalogue and the extension list is quoting a shape, not your project. Ask what would make the number go up.
Do you need a migration app
For the data itself, usually. Tools built for this move records reliably and there is no prize for doing it by hand. We do not sell one and have no stake in which you pick.
The reason to be relaxed about that choice is that the app is the
easy half. No tool decides which products should still exist, what an
attribute called size2 was for, or which of your
categories a shopper would recognise. That is the half the project
lives or dies on, and it is done by people who know the business.
Thinking about the move?
We move Magento stores onto Shopify and run them afterwards. Send us your catalogue size and your extension list and we will tell you where the cost actually sits, before anybody quotes.
Stores we build and grow
Common questions
What moves across from Magento, and what does not?
Products, variants, categories, customers and order history all move. Extensions, custom modules and the theme do not, and that is the part people underestimate. Anything a developer bolted onto Magento is functionality you are re-buying or rebuilding, and about half of it usually turns out to be doing nothing anybody would miss.
How long does a migration take?
The moving of data is days. The project is usually two to four months, and almost none of that is the migration itself: it is deciding what the catalogue should be, agreeing what each Magento extension was actually for, and rebuilding the front end. A team that has already answered those questions moves much faster than one discovering them mid-build.
Will we lose our Google rankings?
Only if the URLs are handled badly, and that is the single highest-risk item in the whole project. Magento and Shopify structure product and category URLs differently, so every old address needs a permanent redirect to its closest new one, written before launch rather than after. A store that skips it takes a traffic drop it then spends six months explaining.
Do we need a migration app?
Usually yes for the data itself, and it matters less than people think. Tools like Matrixify or Cart2Cart move records reliably. What no app can do is decide which of your 12,000 products should still exist, or what an attribute called "size2" was for. The app is the easy half and it is not the half that goes wrong.
What drives the cost?
Four things, in roughly this order: how messy the catalogue and its attributes are, how many integrations have to be rebuilt, how many URLs need mapping, and how much custom Magento functionality has to be reproduced. Notably not the number of products on its own. A clean 40,000-product catalogue is a smaller job than a chaotic 400-product one.
Should we redesign at the same time?
It is the cheaper moment to do it, because the front end is being rebuilt either way, and it is also the moment you lose the ability to tell what caused what. If the numbers move after launch, a store that changed platform and design at once cannot separate the two. Worth doing together anyway for most, but decide it deliberately.
The service side of this, what we do and how a project runs, is on our Magento migration page. If you are still deciding between the platforms rather than planning the move, Shopify against Magento is the comparison, and migrations from other platforms follow the same shape.