Magento to Shopify migration: what moves, what breaks

Your Magento store still takes orders, but most of your engineering budget now goes on patches, upgrades and hosting instead of selling. You need to know whether to keep paying that bill or move.

Adobe backs each Adobe Commerce release for three years. Standard support for 2.4.6 ended on 11 August 2026. On Adobe Commerce Cloud the next deadline has teeth: stores still on 2.4.4 or 2.4.5 have inbound traffic suspended from 1 June 2027. Those dates, not a feature list, are why most teams start this conversation.

Which one, for whom. Leave Magento when the upgrade treadmill costs more than the store earns. Do not leave because Shopify looks simpler. Stay when a product needs a fourth option. Stay when several domains run different catalogues. Stay when the checkout logic is the product. Budget 12 to 20 weeks for a mid-market move.

Who this is for. Founders and operators on Magento 2 or Adobe Commerce, pricing a move or checking a proposal.

Who this is not for. Stores whose edge is custom checkout code, and teams with funded Adobe Commerce engineering.

You get a list of what moves and what is rebuilt before anyone quotes a project. A move done for the wrong reason costs you months of engineering time and search traffic you spent years earning. Autonomous Technologies is an engineering firm. We build and run the systems behind Shopify stores, for founders and operators who own the store after launch. We plan and run Shopify migrations and replatforming, so weigh the bias. Facts checked 21 September 2026. For the steps common to any move, use the Shopify migration checklist. This piece covers the Magento-specific parts.

Everyone else trades unused control for work they no longer staff.

Adobe’s own dates are the real reason teams leave

The pressure is written down. “Adobe offers a three-year standard support window from the General Availability (GA) date for each version” (Adobe Commerce lifecycle policy). So a store is never finished upgrading. Each upgrade is a project, not a patch, because every paid add-on has to move with it.

On Cloud the wording is blunt. Adobe says environments that miss the security deadlines “will have inbound traffic suspended, taking the storefront offline” (version upgrade enforcement policy). Staying put is not a neutral choice.

You may run past end of support, but the risk moves to you. Adobe says it “will no longer create further product changes for that version”, including security and PCI ones. The store owner stays “responsible for PCI compliance re-certification” (end of support FAQ). PCI is the card industry rule set every store taking card details has to meet.

That treadmill is the cost a move removes. On work we run ourselves, the platform needed no backend work for 18 months, then for 10 more, between October 2023 and July 2026, while the site stayed live. Adobe does not publish licence prices. Get your own renewal quote in writing first.

What maps cleanly, and what needs a decision from you

Simple products, orders and customers move. Bundles, a fourth product choice and your category tree need a decision first. Most Magento records have a Shopify match. The work sits in the ones shaped differently.

Variants are where most Magento catalogues hit the wall. A variant is one buyable version of a product, such as the blue one in medium. Shopify’s changelog of 15 October 2025 says merchants can now “create products with up to 2,048 variants in Shopify, exceeding our historical variant limit of 100” (Shopify developer changelog). The option count did not move: “Each product can have up to three options” (Shopify variant documentation). And apps on Shopify’s older product interface may misbehave above 100 variants.

The mapping itself is mechanical. Adobe says each variation of a configurable product “is a separate simple product with its own SKU” (Adobe documentation). A SKU is the stock code for one buyable item. Those child SKUs become Shopify variants. What does not survive is the logic above them.

Attribute sets have a good home. Metafields are the extra data fields you add to a Shopify record (Shopify metafields documentation). Matrixify says your “exported Magento Custom fields for the Products will be created as Metafields” (Matrixify tutorial). The choice is editorial. Which fields need a name, a filter and a spot on the page?

Order history is the reliable surprise. Magento is not on Shopify’s guided migration list (Shopify migration documentation). So orders move through an app such as Matrixify or Cart2Cart, or through the Admin API. Import products first, then customers, then orders. Once they land, “You can’t edit any orders that are imported into your Shopify admin” (order editing considerations). Turn off order emails before the import.

Customer passwords do not come across either. “Because passwords are encrypted, only customer records are imported to Shopify” (Shopify migration checklist). Plan the email that asks people to set a new one as a campaign.

The redirect map is where migrations lose money

One Magento product can live at several web addresses. Shopify will only redirect one that is already broken. In our own migration work the redirect map is the most under-counted line item, and the one that costs traffic when it is wrong.

Adobe’s own settings cause the first two. One applies “a suffix, such as html or htm” to product URLs. Another puts the category path inside the product address. Adobe warns this “can create multiple URLs pointing to the same page” (Adobe catalogue SEO settings).

Shopify’s redirect tool then catches people out. “You can redirect only from broken URLs” (Shopify URL redirect documentation). You cannot redirect a path that already works. So build the map against the new addresses, and test it after the switch.

Capacity is rarely the problem. Shopify allows “a maximum of 100,000 URL redirects unless your store is on the Plus plan, which has a maximum of 20,000,000”. The real work is the choice per address. Pull the list from a crawl, the Magento sitemap, Search Console and analytics together. Each one misses something the others catch.

The B2B path no longer starts at Plus

B2B means selling to trade buyers: shops, dealers and distributors rather than the public. Companies, company locations, quantity rules, price breaks and net payment terms all sit on Basic, Grow, Advanced and Plus. Net terms means the buyer pays 30 or 60 days after the invoice. So do saved cards, draft orders and PO numbers (Shopify B2B features by plan).

Two things still mark out Plus. Lower plans can “assign up to 3 active catalogs across all your B2B markets”. Plus gets unlimited catalogues and can point one straight at a company. Deposits and part payments are Plus only.

That lines up with Magento’s customer groups until you count catalogues. A store with eight agreed price lists does not fit into three. So your pricing model picks the plan, not your revenue. Requisition lists and built-in quoting have no direct Shopify match. The B2B and wholesale scope sets out what a store selling to both audiences has to prove before launch.

What we saw on a real replatform

The store we moved most recently was not on Magento. It ran a custom PHP pricing app bought years earlier, with no version control, no tests and no deploy pipeline. Its problems were the Magento problems: the pricing logic lived in the platform, nobody could change it safely, and the hours went on patches. Container One sells shipping containers on Shopify Plus. The delivered price depends on the product, the stock and the trip from one of 40 depots.

Two decisions carried it. A proxy sends each request to the old app or the new hub, so the cut-over was a routing change, not a launch day. And parity came before features: nothing new shipped until the new hub priced all 41 products the way the old one did. A Magento move with custom pricing or checkout logic needs the same two.

Where this breaks: the checkout you cannot rebuild

Your add-ons are the budget. Export the list and sort it into three piles. An app does this. Shopify does this already. This becomes custom work. The third pile is the number that matters.

Checkout surprises Magento teams most, and it can end a migration. In Magento the checkout is yours to edit. In Shopify it is not. checkout.liquid “is now unsupported for the Information, Shipping, and Payment checkout steps”. Extra scripts were sunset for the thank-you and order status pages on 28 August 2025. Script tags were sunset there for non-Plus stores on 26 August 2026 (Shopify checkout.liquid documentation). Custom checkout code must be rebuilt as a checkout extension or a Shopify Function, a small piece of code that runs on Shopify’s servers. Some of it will not fit. Test that in week one (Scripts to Functions guide).

Links to back-office systems are rebuilt, not ported. An ERP is the system that runs stock, orders and finance. A Magento link usually reads and writes the database. That does not work on Shopify. So you are specifying a new link, with a new rule about who owns each record (Shopify ERP integration guide).

Multi-store is the last big call. Shopify Markets handles currency, language, pricing and page content by country from one store (Shopify Markets documentation). That covers most store views that exist only for language and currency. Different catalogues on different domains usually become separate Shopify stores.

Timeline is set by system links, not by product count

On cost, be careful what you trust. No platform vendor publishes migration project prices. Use agency ranges to sanity-check a proposal, not to plan a budget (how much a Shopify store costs).

An estimate that holds is built backwards from four counts. System links to rebuild. Separate pricing or catalogue rules. Address patterns needing a redirect decision. And checkout behaviour Shopify does not do on its own. A proposal priced on product count has not read the catalogue.

What to bring to a scoping conversation

Four things make a Magento move possible to price. The add-on list, sorted into the three piles above. A crawl of live address patterns, with a count for each. The worst case in your catalogue for options and variants. And the system links, with the record each one owns. Product count is the least useful number here.