Magento to Shopify migration: what actually breaks

Most replatforming articles are written by agencies that sell replatforming, which is worth saying out loud because we sell it too. So this one starts with the case for not doing it, then covers the part that actually costs money when you do.

The deadlines, which are the reason this is on your desk

Adobe runs a three-year standard support window from each version's general availability date. The important asymmetry for anyone on the free edition is this: extended support is for paying Adobe Commerce customers only. For Magento Open Source, the end of standard support is the end of patches. There is no paid extension to buy.

Where the versions stand as of October 2026:

Version	Standard support	Open Source after that
2.4.4, 2.4.5	Ended	No patches
2.4.6	Ended 11 August 2026	No patches
2.4.7	Ends 9 April 2027	No patches
2.4.8, 2.4.9	Into 2028 and 2029	Supported for now

Two more dates belong on the same calendar. PHP 8.2 security support ends on 31 December 2026, and from 1 June 2027 Adobe stops maintaining Cloud environments running unsupported Commerce versions.

Check your own version against Adobe's lifecycle policy rather than against any agency's table, this one included. The dates move.

If you are on Open Source 2.4.6 or older, you have been running unpatched since August. That is the actual situation, and it is a PCI and insurance conversation before it is a platform strategy conversation.

Upgrade or replatform

Being unpatched creates urgency. It does not by itself tell you which way to go, and a replatform chosen in a panic is how projects end up costing double.

Upgrade to a supported 2.4.x if your catalogue logic is genuinely complex in ways Magento models natively: deep configurable products, customer-group pricing, multi-warehouse inventory, B2B quoting and approval flows. Also if you have ERP or PIM integrations that were expensive to build and work, or a team that knows the stack. An upgrade is a smaller project than a replatform and a lot of "we must leave Magento" conversations are really "nobody has upgraded this in three years" conversations.

Replatform to Shopify if your total cost of ownership is dominated by keeping the thing alive rather than improving it. The signal is a merchant who cannot change a landing page without a developer, who pays for hosting, a maintenance retainer and a pile of extensions, and whose roadmap is entirely upgrades. Shopify takes the hosting, PCI scope, checkout and platform upgrades off your plate permanently. That is the trade: less control over the stack, far less of it to maintain.

Do not replatform if the honest reason is that the current site looks dated. A redesign is cheaper than a migration and you can do it where you are.

What breaks, in order of how much it costs

Organic traffic, which is most of it

This is where replatforms lose real money, and it is almost always underscoped. Every URL on the site changes, because Shopify's URL structure is not Magento's and is not fully configurable. /products/ and /collections/ are fixed prefixes.

What this needs:

• A complete URL inventory before anything else. Export every indexed URL from Search Console and your server logs, not just what the sitemap claims. Old category pages, filtered URLs that earned links, retired products with backlinks, blog posts, CMS pages.
• A one-to-one redirect map. Every old URL to its closest new equivalent, with a real page at the end. Mapping a thousand product URLs to the homepage is the single most common way to lose a replatform's worth of traffic.
• Faceted and filtered URLs decided deliberately. On Magento these often accumulated links and rankings. Shopify handles filtering differently, so decide which of those are worth recreating as real collections and which get redirected to the parent.
• Structured data rebuilt, not assumed. Product, Offer, AggregateRating and BreadcrumbList all have to come back, and themes vary wildly in what they emit.
• Internationalisation preserved. If you run hreflang across country stores, Shopify Markets models this differently to Magento store views. Get this wrong and you merge or orphan whole country versions.

Expect a dip regardless. A well-executed migration recovers in weeks. A careless one does not fully recover, because the redirect map was wrong and nobody has the old URL list any more.

Data, which is fiddly rather than hard

Products, categories, customers and orders all move, with caveats worth knowing before someone promises you a clean import.

Configurable products become variants, and Shopify's limits apply. If you have products with many option dimensions, this is a modelling exercise, not an export. Some Magento catalogues simply do not map one to one.

Customer passwords do not transfer. They are hashed with a scheme Shopify cannot import. Customers get a password reset on first login, and that email needs planning because it lands in every inbox at once.

Order history imports as records, not as live orders. Historical orders come across for reference and reporting. They are not refundable or editable the way native orders are.

Custom attributes need a home. Everything you kept in Magento EAV attributes becomes metafields and metaobjects on Shopify. That is a better structure in most cases, but it is a design decision per attribute, and it is where migrations quietly lose product data.

B2B pricing and customer groups. Shopify models this, but differently. If customer-group pricing is core to your business, scope it specifically rather than assuming parity.

The things Shopify does differently on purpose

Checkout is not yours. You extend it through Checkout Extensibility, with UI extensions and Shopify Functions. Anything that relied on arbitrary PHP in the checkout flow gets redesigned, not ported. Budget for that as a feature, not a translation.

Extensions become apps, and the economics change. Count your Magento extensions, find the Shopify equivalents, and price the monthly subscriptions. For some merchants the app bill is a pleasant surprise against a maintenance retainer, and for others it is the thing nobody added up.

Theme work is sections, not templates. On Online Store 2.0 every template is JSON and the merchant composes pages without a developer. That is most of the operational win, and it is worth building for deliberately rather than porting your old page structure across. We covered what that involves in migrating a Shopify store to Online Store 2.0.

BigCommerce is a different conversation

There is no deadline forcing anything. BigCommerce stores move for other reasons: the app and theme ecosystem is smaller, finding developers is harder, and merchants often want Shopify's checkout conversion and POS.

The migration itself is easier than Magento's, because the data model is closer and there is less custom PHP to unpick. The URL and redirect work is exactly the same amount of work, and it is still the part that decides whether the project pays for itself. If the only driver is dissatisfaction rather than a constraint you can name, that is worth testing before you spend the budget.

A sequence that works

1. Audit before deciding. What is actually custom, which extensions are load-bearing, what the integrations do, what the URL inventory looks like. This is also what tells you whether upgrading is the cheaper answer.
2. Model the catalogue on paper first. Attributes to metafields, configurables to variants. Find the products that do not map before anyone writes an importer.
3. Build the theme as sections, with the storefront paths meeting WCAG 2.1 AA and a Core Web Vitals budget agreed up front. In the US, the accessibility part is not optional any more, and the filing data says Shopify stores are the most named.
4. Import, reconcile, import again. Count SKUs, variants, customers and orders on both sides and explain every difference.
5. Redirects tested before launch, every one of them, with a crawl of the old URL list against the new site on a staging domain.
6. Launch, then watch Search Console daily for a month. Coverage errors and 404s in the first fortnight are normal and fixable. Finding them in month three is not.

Where to start

Find your version and the date attached to it. If it is 2.4.6 or older, the security conversation is now and it is separate from the platform decision.

Export your URL inventory this week. It costs nothing, and it is the asset that decides whether a future migration keeps your traffic. It is also the thing nobody can recreate after the old site is gone.

Get the real total cost of ownership on both sides. Hosting, maintenance, extensions and developer time where you are, against Shopify subscription, apps and build. Most of these decisions are made on gut feel and the numbers usually say something more specific.

---

This is the work we do. Smart-UI builds and supports Shopify stores, and the part of a replatform we take most seriously is the redirect map, because that is the part that decides whether the project pays back. On Completedworks the theme rebuild, the redesign and the accessibility work shipped together, for the same reason: the templates were being rewritten anyway.

If you are weighing an upgrade against a replatform, the fixed-price audit covers what is custom, what the integrations do and what the URL inventory looks like, and it is useful whichever way you then go. For the migration itself, the Shopify work is quoted within 48 hours of a brief.

Tell us what you are on and we will tell you honestly whether moving is worth it.