Magento to Shopify Migration: The 2026 Playbook for Merchants Facing End of Support
Migrating from Magento or Adobe Commerce to Shopify usually takes 8 to 14 weeks and succeeds or fails on three things: a complete URL redirect map built before anyone writes code, an honest decision about whether you are rebuilding the design or lifting it, and a parallel run before cutover instead of a big-bang switch. The platform cost saving is real, often 60 to 80 percent of total cost of ownership for merchants in the $1M to $15M band. The saving is not the reason to move. The reason to move is that your team stops spending its year on upgrades and starts spending it on revenue.
Something happened on Monday that most Magento merchants missed
On 11 August 2026, Adobe Commerce 2.4.6 reached end of support. If you are on Adobe Commerce, you may have an extended window. If you are on Magento Open Source, you do not. Adobe states plainly that extended support is available to Adobe Commerce customers only, not the Open Source codebase.
So a meaningful slice of the Magento install base woke up this week on a version that will never receive another security patch. Nothing broke. Nothing will break tomorrow. That is exactly what makes it dangerous. What actually happens is that every new vulnerability discovered from here forward gets fixed for 2.4.7, 2.4.8 and 2.4.9, and not for you. The gap compounds monthly. And your PCI posture quietly degrades while your site keeps taking orders as though nothing changed.
Here is the current lifecycle picture, straight from Adobe's published policy:
| Release line | End of support | Notes |
|---|---|---|
| 2.4.9 | May 2029 | Released 12 May 2026, longest runway |
| 2.4.8 | April 2028 | Currently supported |
| 2.4.7 | April 2027 | Currently supported, regular support ends sooner |
| 2.4.6 | 11 August 2026 | Just ended |
| 2.4.5 | August 2025 | Ended, Adobe Commerce only got the extension |
| 2.4.4 and below | Ended | Unsupported |
| Magento 1 | Long gone | Migrate immediately |
There is one more date worth writing down. From 1 June 2027, Adobe will no longer maintain Cloud environments running unsupported Commerce versions, and reserves the right to take action including suspending traffic to affected infrastructure. That is not a marketing deadline. That is a hosting provider telling you it may turn the lights off.
We are not writing this to scare you. Half the Magento content published this quarter is an hourglass graphic and a call to action. We would rather give you the actual decision.
Verify current dates against Adobe's published lifecycle policy before you budget. Adobe has revised these windows before.
Should you actually migrate? The honest version
We turn down migration work. Not often, but often enough that we want to say this before anything else.
Stay on Magento if:
- You have genuinely complex pricing logic that cannot be expressed as catalogs and rules. Formula-driven pricing, configure-to-order products, quote-first buying with engineering review. Magento's flexibility is real and Shopify will fight you.
- You have an in-house Magento team of three or more who are productive and not spending most of their time on maintenance.
- You just completed a 2.4.9 upgrade and a Hyvä frontend build. You have runway until 2029 and you spent real money getting there. Use it.
Migrate if any two of these are true:
- You are on 2.4.6 or below and the upgrade quote came back at $40k or more.
- Your last three Magento upgrades each broke something in production.
- The developer who knows your codebase has left, or is about to.
- You are paying more to keep the site alive than to grow it.
- Your marketing team has to file a ticket to change a homepage banner.
- Mobile LCP is above 4 seconds and every fix proposal starts with "well, first we would need to..."
- Your Adobe renewal is inside twelve months.
If you land in the middle, the tiebreaker is not technical. It is this: over the next three years, do you want to be in the business of maintaining commerce infrastructure, or in the business of selling your product? Magento is a platform you operate. Shopify is a platform that operates for you. Both are defensible answers. Only one of them is what most brands actually want.
What you are really paying for Magento right now
Merchants consistently underestimate this, because the licence is the only line item that looks like a cost. Adobe does not publish pricing, and figures floating around are third-party estimates, so treat the following as a framework rather than a quote.
Adobe Commerce, roughly $1M to $15M GMV:
| Line | Typical annual range |
|---|---|
| Adobe Commerce licence | $22,000 to $125,000+, scaled to GMV |
| Cloud hosting (if not bundled) | $10,000 to $40,000 |
| Agency retainer for maintenance and patching | $30,000 to $90,000 |
| Extension licences (10 to 30 modules) | $5,000 to $20,000 |
| Major version upgrade, amortised | $25,000 to $60,000 every 18 to 24 months |
| Realistic total | $90,000 to $300,000 |
Magento Open Source: no licence, which is the trap. You still carry hosting, patching, extension licences, upgrade cycles, and either a dev on payroll or an agency on retainer. We have audited Open Source stores costing more per year than an Adobe Commerce contract, because the merchant was paying two developers to do what Adobe would have automated.
Shopify equivalent for the same merchant: platform subscription, apps, and an agency retainer only when you want work done, not when something needs patching. For the brands we have moved, total cost typically lands 60 to 80 percent below where they were. The variance is almost entirely app choices.
The number that actually matters is not the delta. It is what your team does with the time. On Magento, roughly half of a technical roadmap goes to keeping the platform current. That half comes back.
What transfers, what does not, and what quietly changes shape
This is the section most guides get wrong, because they tell you data "migrates" as though it were a copy and paste. It is a translation between two different data models. Some of it is lossless. Some of it is not.
| Magento asset | Transfers? | What actually happens |
|---|---|---|
| Simple products | Yes, cleanly | Straight mapping |
| Configurable products | Mostly | Shopify's variant model is flatter than Magento's. Products built from many attributes often need restructuring, sometimes splitting |
| Bundle and grouped products | No native equivalent | Rebuilt as apps, bundled SKUs, or product sets. Plan for this specifically |
| Custom attributes and attribute sets | Yes, as metafields | This is the single most underestimated task. Attribute sets do not exist in Shopify. They become metafield definitions and often metaobjects |
| Categories | Yes | Become collections. Deep nesting flattens, and that is usually an improvement |
| Layered navigation | Rebuilt | Becomes Shopify filters via Search and Discovery or a filtering app. Attribute-to-filter mapping needs a deliberate pass |
| Customers | Yes | Profiles, addresses, groups |
| Customer passwords | No | Different hashing. Nobody can move these. Plan a re-authentication email at launch. Any agency that promises otherwise is guessing |
| Customer groups and tier pricing | Yes, reshaped | Become B2B companies and catalogs. See the B2B section below, this got much easier in 2026 |
| Order history | Yes | Imported as historical records. Older orders may lose some line-level metadata |
| CMS pages and blocks | Content yes, structure no | Static blocks become sections, metaobjects, or snippets. This is a rebuild, not an import |
| Blog posts | Depends | Magento has no native blog. Whatever extension you used determines the export path |
| Product reviews | Usually | Via Judge.me or Okendo import. Verify star ratings and photos survive |
| Extensions | No | Every one needs a Shopify app equivalent, a custom build, or a decision to drop it |
| Third-party integrations | Rebuilt | ERP, PIM, 3PL, tax. See below |
| SEO URLs | Redirected, not carried | The most important workstream in the project |
Two things to internalise:
Customer passwords cannot move. Ever. Between any two platforms. The migration is judged partly on how gracefully you handle the moment thousands of customers discover they need to reset. That is a communications plan, not a technical one, and it should be written six weeks before launch.
Attribute sets are the hidden iceberg. A Magento catalogue with forty attributes across six attribute sets is not a data export, it is an information architecture project. When a migration quote comes in suspiciously low, this is usually what was left out.
Your extensions have Shopify equivalents. Mostly.
| Magento extension category | Shopify path |
|---|---|
| Amasty layered nav, SEO toolkits | Search and Discovery, plus native SEO fields |
| Aheadworks / Mirasvit search | Native semantic search, Searchanise, or Algolia |
| Yotpo, Trustpilot, Bazaarvoice | Judge.me, Okendo, Yotpo has a Shopify app |
| Mageplaza one-step checkout | Native Shopify checkout. This is a straight win, do not rebuild it |
| B2B module (Adobe Commerce) | Native Shopify B2B, expanded in 2026 |
| ERP connectors | Rebuilt via app, middleware, or custom private app |
| Page Builder | Shopify sections and blocks, or a page builder app |
The pattern: about 70 percent of a typical Magento extension stack maps to an app or to native Shopify functionality. Roughly 20 percent gets dropped because it was solving a Magento problem that does not exist on Shopify. The remaining 10 percent needs a custom build, and that 10 percent is where migration budgets go wrong when nobody scoped it.
We inventory every extension in week one and put it in one of those three buckets before we quote. If your prospective agency has not asked for your composer.json or your module list, they are quoting blind.
The B2B question changed in 2026, and it matters most to Magento merchants
Magento's B2B suite was, for a long time, the strongest argument for staying. Company accounts, per-customer catalogues, quote workflows, net terms. Shopify's answer used to be "buy Plus."
On 2 April 2026 that changed. Shopify moved most B2B functionality onto every paid plan. Company accounts, up to three active catalogs, net payment terms including Net 30 through Net 90, purchase order numbers at checkout, self-serve buyer ordering and Flow automations now work on Basic, Grow and Advanced.
What is still Plus-only: unlimited catalogs, a dedicated B2B storefront on its own domain, deposit and partial payment workflows, vaulted cards for buyer accounts, and checkout customisation via Shopify Functions.
The practical read for a Magento merchant: if your wholesale operation runs on three or fewer distinct price levels, you no longer need a Plus contract to leave Magento. If every customer has a bespoke price list, you need Plus or you need to accept that your pricing was never as bespoke as your sales team believed. We have had that second conversation more than once, and it usually ends with a much simpler catalogue.
The three-catalog ceiling is the first wall most people hit, and it applies across all B2B markets combined, not per market. Worth knowing before you scope.
The SEO question, which is the one you are actually worried about
Every merchant asks this and every agency says "we preserve your SEO." Here is what that sentence should mean.
Magento URL structures that need explicit handling:
- The
.htmlsuffix. Magento appends it by default. Shopify does not use it. Every product and category URL needs mapping. - Category paths in product URLs. Magento can serve
/category/subcategory/product.html. Shopify serves/products/handle. Different shape entirely. - Layered navigation parameters.
?color=blue&size=largecombinations, often indexed, often thousands of them. - Store view prefixes if you run multi-store.
/en/,/us/, and so on. - Whatever custom rewrite rules accumulated over eight years in
url_rewrite. Export that table. All of it.
What a real redirect plan looks like:
- Full crawl of the live site. Screaming Frog or equivalent, every URL, no sampling.
- Export the
url_rewritetable directly from the database, because the crawl will miss orphaned URLs that still receive traffic. - Pull the last twelve months of Search Console data. Every URL that received a single impression goes on the list.
- Pull top landing pages from GA4, including ones that no longer link from anywhere.
- Reconcile all four into one master sheet. Old URL, new URL, status, priority.
- Build 301s for every row. Not patterns. Rows. Patterns miss the exceptions, and the exceptions are usually your best pages.
- Handle the layered nav parameters as a class: consolidate to the parent collection rather than creating thousands of redirects to nothing.
- Test the map on staging against a sample of 500 URLs before cutover.
- Re-crawl within 24 hours of launch and fix anything returning 404.
What to expect after launch, honestly. A well-executed migration typically sees a mild dip in weeks one to three as Google recrawls and reprocesses, then recovery, then usually growth because the new site is faster and better structured. Anyone who promises zero movement is describing an outcome nobody controls. What we control is that every dip is explainable and every 404 is fixed inside a day.
We build the redirect map before the design is finalised. It is the first deliverable, not the last checklist item. That ordering is the single biggest predictor of whether a migration keeps its traffic.
Same design, or start over? Read this before you decide
This is the question that decides your budget, your timeline, and how the project feels. Most merchants arrive with a vague sense of "well, we might as well refresh it while we're in there," which is how a twelve-week project becomes a thirty-week project.
There are three honest options.
Option A: Faithful rebuild
Recreate the current design in Liquid, near pixel for pixel.
Choose this when: your design is genuinely good and reasonably recent. You have a real brand system. You just rebranded. Your team has no bandwidth for design decisions. Or your priority is de-risking the platform move and nothing else.
Cost signal: lowest. Timeline: shortest. Risk: lowest.
The honest caveat: faithful rebuilds are not always cheaper than they look. A Magento theme built on complex layout XML and custom widgets can be harder to replicate exactly than to redesign properly. We will tell you when that is the case, because we would rather lose the "cheap" version of the project than deliver a bad one.
Option B: Structural redesign, same brand
Keep the logo, palette, and typography. Rethink navigation, PDP layout, collection filtering, cart and homepage hierarchy. Same brand, better machine.
Choose this when: the brand is fine but the site converts poorly. Your PDP is a wall of tabs. Your navigation has nine top-level items. Mobile feels like a desktop site squeezed. This is the right answer for roughly 60 percent of Magento merchants we speak to.
Cost signal: medium. Timeline: add 3 to 4 weeks. Risk: low, and it is the option with the best return.
Option C: Full redesign
New art direction, new everything.
Choose this when: the brand has genuinely moved on. You are repositioning. The current site is a decade old. Or, candidly, when you look at it and feel embarrassed. That feeling is data.
Cost signal: highest. Timeline: add 6 to 10 weeks. Risk: highest, because you are changing two variables at once and post-launch numbers become hard to attribute.
How we would actually advise you
If your conversion rate is healthy and the site simply costs too much to run: Option A. Move the platform, bank the saving, redesign next year as a separate project with clean before-and-after data.
If your conversion rate is the problem: Option B. Nearly always. It is where the money is.
If it is Option C, we would rather sequence it: migrate first on a clean, faithful build, then redesign in a second phase eight to twelve weeks later. You get an isolated migration you can measure, and a redesign you can measure. Two clean datasets instead of one muddy one.
Agencies rarely suggest this because one big project bills better than two smaller ones. We suggest it because we would rather you know what worked.
The Magento to Shopify migration checklist
Copy this. Use it whether you hire us or not.
Before you talk to anyone
- Record your exact Magento version and whether it is Open Source or Adobe Commerce
- Note your Adobe renewal date if applicable. This is your real deadline
- Export your module list or
composer.json - Count SKUs, variants, categories, and custom attributes
- List every third-party integration: ERP, PIM, 3PL, tax, email, reviews, search
- Pull twelve months of Search Console and GA4 data before anything changes
- Note your peak season. Do not launch inside it, and do not launch in the four weeks before it
Discovery, weeks 1 to 2
- Full site crawl and URL inventory
-
url_rewritetable export - Extension audit sorted into keep, replace, drop
- Attribute set mapping to metafields and metaobjects
- Product type audit: how many bundles, groups, configurables
- Customer group and tier pricing mapping to B2B catalogs
- Design decision made and written down: A, B or C
- Integration architecture agreed, including what talks to what
- Named technical lead on both sides
Build
- Redirect map complete before development starts
- Catalogue migrated to a staging store, verified against source counts
- Metafields structured and populated
- Theme built with a performance budget set on day one
- Filters rebuilt and tested against real catalogue data
- Integrations rebuilt and tested in staging with live-shaped data
- Checkout configured: payments, taxes, shipping profiles, duties
- Email and flows rebuilt in Klaviyo or equivalent
- Analytics rebuilt: GA4, server-side where relevant, ad platform pixels
- Legal pages, policies, structured data, sitemap
Pre-launch, two weeks out
- Redirect map tested on staging against a 500-URL sample
- Full QA across devices and browsers
- Order flow tested end to end with real payment methods
- Password reset communication drafted and scheduled
- Rollback plan documented, with a named decision-maker
- DNS TTL lowered
- Team trained on the new admin before launch, not after
Launch week
- Cut over during your lowest-traffic window
- Re-crawl within 24 hours, fix every 404 same day
- Submit new sitemap to Search Console
- Monitor Search Console coverage daily for 14 days
- Watch conversion rate hourly for 48 hours, then daily
- Send the password reset communication on schedule
- Keep the old environment alive and reachable for 30 days
After
- Thirty-day stabilisation window with a named owner
- Week-four SEO review against pre-migration baseline
- Core Web Vitals check on real user data, not just lab scores
- Post-mortem, written down, shared with you
How we run a Magento migration
Eight to fourteen weeks depending on catalogue complexity and design path. Here is the actual sequence.
Weeks 1 to 2, Audit. We crawl the site, export your rewrites, inventory every module, map your attribute sets, and count the things people forget to count. You get a written audit document at the end of it including anything we think should be dropped rather than moved. That document is yours whether you hire us for the build or not.
Week 2, The redirect map. Before a line of Liquid is written. Old URL to new URL, every row, reconciled from crawl, database, Search Console and GA4.
Weeks 2 to 4, Design decision and direction. A, B or C, decided in a conversation, not assumed. If it is B or C you get Figma by day three of this phase, not week six.
Weeks 3 to 8, Build. Catalogue into staging first so you can see real data early. Theme built against a performance budget from day one, because retrofitting speed is three times the work. Integrations rebuilt in parallel, not at the end.
Weeks 8 to 10, Parallel run. The new store runs against live-shaped data while the old one still takes orders. Your team places test orders. Your ops team runs a real fulfilment cycle. Nobody discovers on launch day that the 3PL feed drops a field.
Week 10 to 12, Cutover. Low-traffic window. Re-crawl within 24 hours. Old environment stays up for 30 days.
Weeks 12 to 16, Stabilisation. Thirty days with a named person on it. Not a support queue. A person.
What makes us different, stated plainly
We build the redirect map first. Most agencies treat it as a launch-week task. It is our week-two deliverable, and it is why our migrations do not lose traffic.
We run in parallel. We do not do big-bang cutovers. Two weeks of the new store operating on real data before anyone touches DNS. Migrations fail at the integration seams, and this is where those failures surface harmlessly.
The person who scopes your project builds it. No pitch team, no handoff to a junior in week three. You meet the technical lead in the first call and they stay through stabilisation.
We set a performance budget on day one. Every store we build targets 90+ Lighthouse. Not as a launch push. As a constraint we design inside from the first component.
We will tell you not to migrate. We have. Twice this year. If your Magento setup is working and the maths does not support a move, we would rather say so and stay someone you trust than take a project that should not exist.
We hand you a theme your team can actually edit. If your marketing lead needs a developer to change a homepage banner, we have failed. That is the whole point of leaving Magento.
Thirty-day stabilisation is in the contract. Not a support tier. Included.
We are a Shopify Select Partner with a 5.0 rating. We have migrated brands including Biogents, a European mosquito-science company scaling into the US market, where the post-migration numbers came in at +96 percent sales, +92 percent order volume, and +80 percent sessions. Harvard Sweet Boutique came off a Shopify version so old it predated half the platform's modern features, and posted +20 percent sessions post-migration.
Frequently asked questions
How long does a Magento to Shopify migration take? Eight to fourteen weeks for most merchants. A straightforward catalogue with a faithful design rebuild can ship in eight. A large catalogue with complex attributes, B2B requirements, and a full redesign runs closer to twenty. The catalogue drives the timeline more than the design does.
Will I lose my Google rankings? Not if the redirect work is done properly. Expect a mild dip in the first two to three weeks as Google recrawls, then recovery, then usually improvement because the new site is faster. The risk is not migration itself, it is incomplete redirect mapping. That is why we build the map before we build the site.
Can my customers keep their passwords? No. Passwords are hashed differently on every platform and cannot be transferred by anyone. Customer accounts, addresses and order history all move. Passwords need a reset. This is handled with a scheduled communication at launch, and done well it is a non-event.
What happens to my Magento extensions? About 70 percent map to a Shopify app or to native functionality. Around 20 percent get dropped because they solved a Magento-specific problem. The remaining 10 percent need custom development. We audit every module in week one and put each one in a bucket before quoting.
Is Shopify good enough for B2B after Magento? For most wholesale operations, yes, and this changed materially in April 2026 when Shopify moved company accounts, catalogs, net terms and self-serve ordering onto every paid plan. The ceiling is three active catalogs below Plus. If your pricing needs more than three distinct levels, you need Plus. If it does not, you no longer need a Plus contract to leave Magento.
Do I have to redesign at the same time? No, and often you should not. Migrating on a faithful rebuild and redesigning as a separate phase gives you two clean datasets instead of one confounded one. It is usually the better sequence, even though it is the one agencies suggest least.
What does a Magento to Shopify migration cost? It depends on catalogue complexity, integration count, and which design path you choose, so anyone quoting before seeing your module list is guessing. What we can say is that the audit is what makes a quote real, and we will do that audit and give you the document regardless of whether you build with us.
Should I move to Shopify or upgrade to 2.4.9? If you have an in-house team, complex pricing that Shopify cannot express, and recent investment in a Hyvä frontend, upgrade. You have runway to 2029. If your upgrade quote is $40k+, your last three upgrades broke production, and your team spends more time maintaining than shipping, migrate. The question is not which platform is better. It is which business you want to be in.
Where to go from here
If you are on 2.4.6 or below, you are now unpatched, and the honest first step is not a migration quote. It is knowing exactly what you have.
Send us your Magento version and your module list. We will run the audit and give you the written document: your URL inventory, your extension mapping, your attribute complexity, and a straight answer on whether migrating makes sense for you. That document is yours either way.
We take on one to two new partners a month and we reply within one business day.
Code2Commerce is a Shopify Select Partner studio. We build premium storefronts, run platform migrations, and stay on as the team behind the store. Chicago, remote-first, all timezones welcome.