Magento to Shopify Migration

WBD is a small e-commerce agency in Oxford. We design and build Shopify and Shopify Plus stores for independent brands, and a good share of that work starts on Magento. We're not obliged to agree that you should leave it — we ran a large Magento store of our own for a decade, we still build on Magento, and we say so on the pages where saying so costs us the job. But the reasons for leaving Magento tend to hold up better than most: a support window that closes on a schedule, a hosting and patching bill that never gets smaller, an extension stack nobody fully understands any more, and a developer you can't replace.

The move is the easy half to describe and the harder half to do well. Most of what goes wrong isn't the catalogue. It's everything that got built around the catalogue over a decade.

The platform-agnostic version of this chapter — the procedure, the risks, the questions to ask whoever you hire — is Shopify Migration Agency. This one is about Magento specifically.

Always Riding — the D2C cycling boutique we founded in 2008 and sold in 2018 — ran on Magento Community. Five languages, multiple currencies, a catalogue deep enough to use every attribute set it had. We weren't administering it from a distance either: we merchandised it, wrote it, argued about its category tree and paid its hosting bill. We sold two years before Magento 1's security patches stopped, so we missed the cliff edge itself, but the years before it taught us what a Magento store of that size costs to keep upright — and how much of that cost never appears in anyone's platform comparison.

The other half of it is our Magento developer, who has several hundred of these builds behind him and has been working with us for years. When a Magento question needs a real answer rather than a confident one, he's who we ask. That's also why we can be relaxed about telling a merchant to stay where they are: we aren't selling an escape from a platform we don't understand.

Magento is not a bad platform, and nothing here is a dig at it. It's a maintenance commitment, and the calendar is public. Magento 1 stopped receiving security patches on 30 June 2020, and stores are still trading on it. Each Magento Open Source 2.4 line carries three years of support from release, which means the dates keep landing: support for 2.4.6 ended on 11 August 2026, 2.4.7 runs to April 2027, 2.4.8 to April 2028, and 2.4.9 arrived in May 2026 with a 2029 date already attached. From this year Adobe's cadence is one major version each May with security patches in between. Meanwhile Adobe's own direction of travel is a cloud service, which is a reasonable place to be if you have an enterprise team to sit in it.

So the real question isn't whether Magento works. It's whether you want a permanent line in the budget for hosting, patching, extension licences and a specialist who knows your build — and whether what you get for that money is something your customers can feel. For a large operation with an internal team, often yes. For an independent brand of five people who just want to sell well and look like themselves, that money usually buys more when it's spent on the shop rather than on keeping the shop upright.

Most migration pages describe the process. The thing merchants actually want is the parts list — what each Magento concept becomes on the other side, and where the mapping is a judgement rather than a lookup.

A long-lived Magento store is a shop plus a set of decisions nobody wrote down: attribute sets that encode how you think about product, price rules that reflect how you actually trade, a category structure grown to fit the range, and extensions doing jobs the business now depends on. Move the products and leave that behind, and the new store works while quietly being a worse version of the old one. So the first fortnight is an audit rather than an export — what's on the site, what's used, what's used often, and what exists because someone installed it years ago and nobody dared remove it.

For a cycling retailer that audit usually lands on the same places: size and fit guidance, the bike-versus-parts distinction that keeps browsing sane, and whatever handles bundles, builds or made-to-order. Those are worth rebuilding properly. The rest is worth losing, and saying so early saves real money.

Where a bespoke Magento feature was doing brand work — a fit tool, a build configurator, a paint or spec selector — we'd rather rebuild it as a designed thing than approximate it with a plugin. It's the work we most enjoy. For Regroup in Tempe we built Regroup FIT, bespoke bike-fitting software for the fitter and the client, in the better part of one December. For Pegoretti we built the Color Wall, a drawer that gathers paint finishes as you browse toward a commission. A migration is often the only moment you'll get to redo those pieces with the whole picture in front of you.

An old Magento store carries years of accumulated search equity, spread across URLs that look nothing like Shopify's. The .html suffixes, the store-code prefixes, the layered-navigation parameters that got indexed while nobody was watching, the legacy catalog/product/view paths still being linked from somewhere. Shopify enforces its own patterns — /products/ and /collections/ — so the mapping isn't optional, and a move that skips it loses traffic that took a decade to earn.

The method isn't complicated, it's laborious: crawl the old site in full, pull the pages that actually earn sessions and links, map every one to its destination, and put the 301s in place before the DNS changes rather than after. Then watch it weekly for a month or two. What that watching is for, and how long the wobble normally lasts, is set out in the migration chapter — the short version being that even a clean move gets choppy seas, and the honest measure is three months rather than three days.

Products come across with variants, images and their attribute mappings, and that last part is where the manual thought goes. Customer accounts move as records; passwords don't travel between platforms, so returning customers activate on first sign-in — worth designing rather than tolerating, and we've built the generous version of it, holding hundreds of legacy Pegoretti owner records in abeyance until each owner signed in and found their bicycle already there.

Historic orders are the judgement call. Full history is useful for support and loyalty, and heavy to import cleanly; the sensible answer is usually a defined recent window inside Shopify with the archive kept accessible elsewhere. All of it lands in a staging store first, and none of it goes live on trust — counts reconciled, awkward products checked by hand, real orders placed through the real checkout before a customer does.

For a bespoke, design-led store, plan in months rather than weeks. The data move is the shortest part of the job; the audit, the feature rebuilds and the design work set the timeline. On cost, UK agency builds land in the £10,000–£50,000+ band with scope deciding where — the bands are broken down in Building a Shopify Website — and a Magento move with bespoke features to rebuild generally sits above the middle of it. The way to narrow that is a conversation about what your store actually does, which we'll have before quoting anything. If you'd rather start with a diagnosis than a project, we run bench days at £500.

Sometimes it isn't. The store is slow because of how it was built rather than what it was built on; the site looks tired because nobody has designed it since 2019; the checkout leaks because of the checkout, not the platform. We'll tell you that if we find it, and we'd rather tell you on a free call than in month three of a project. If the honest answer is a front-end rebuild on the Magento you already own, that's a smaller cheque and a better night's sleep than a migration you didn't need.