Magento Open Source End of Support: A Complete Guide to the Decision You Need to Make in 2026

In recent weeks LinkedIn has filled up with infographics showing sand pouring through an hourglass and the headline “End of support risk.” It sounds alarmist, so it’s worth separating what’s true from the marketing shortcut — and showing the concrete options a store owner actually has.

I work mostly with Laravel and modern JavaScript, but Magento has a status in European e-commerce that you can’t ignore. Dozens of projects I’ve encountered are running 2.4.x today. Writing this piece started with a question from one client: “Do I actually have to do anything about this, or is it typical agency FUD?” Short answer: yes, you do — but not necessarily what they’re trying to sell you.

This article is long deliberately. The decision you have to make costs anywhere from tens to hundreds of thousands of dollars and has five-year consequences. Marketing shortcuts don’t help.

A short history: how we got to “the end of Magento”

To understand what’s happening now, it’s worth going back a few years — because decisions made over a decade ago still shape today’s landscape.

2008 — Roy Rubin and Yoav Kutner release Magento 1 as open source. Within a few years it becomes the dominant e-commerce platform for mid-market and enterprise stores. eBay buys Magento in 2011, sells it to Permira in 2015.

2015 — work begins on Magento 2. Completely new core, incompatible with 1.x. Marketing calls it “modernization”; engineers know it’s effectively a new platform.

2018 — Adobe acquires Magento for $1.68B. The pivot point. Magento becomes the centerpiece of Adobe Experience Cloud, alongside Marketo and AEM. The strategic intent is clear: build an enterprise stack for the Fortune 500.

2020 — end of support for Magento 1. Hundreds of thousands of stores are left on a platform that no longer receives patches. This moment shaped today’s market paranoia — many companies still remember what the 1 → 2 migration cost.

2021 — community members publish an open letter and announce Mage-OS, an independent community-driven fork. A reaction to Adobe’s increasingly clear pivot toward enterprise and the fear that Open Source would get “legacy” status.

2022–2024 — Adobe redefines the stack: PWA Studio enters maintenance mode, Edge Delivery Services, Commerce Drop-ins, and App Builder appear. All of these run only on Adobe Commerce / Cloud. Magento Open Source still gets releases, but real development shifts toward paid components.

2025–2026 — regular support ends for 2.4.4 and 2.4.5. Magento 2.4.8 is the last release with planned long-term support. In the background, Mage-OS picks up speed: 2.0 in October 2025, 3.0 planned for May 2026.

This isn’t the story of “Adobe shutting down Magento.” It’s the story of a slow split into two paths: a commercial one (where investment goes) and an open-source one (which the community maintains independently). The hourglass on the infographics is real, but not literal.

What Adobe actually announced — the official timeline

Adobe never published a single “end of Magento Open Source” announcement. There’s no project sunset date. What exists is a lifecycle policy — and that’s what generates all the noise.

Official end-of-regular-support dates by release line:

Magento 2.4.8 is currently the last release with planned long-term support. Anything beyond that date is unknown — Adobe signals that Magento 2.4.9 will arrive around May 2026, but there is no Magento 3 on the roadmap.

This is not “the end of Magento tomorrow.” This is the slow shrinking of the window during which your store gets official security patches.

The nuance the infographics don’t show: Open Source has it worse than Adobe Commerce

This is the trap half of today’s published material misses.

The Extended support column above applies only to Adobe Commerce. Adobe states this explicitly in the documentation:

Extended support is available to Adobe Commerce customers only. It is not available for the Magento Open Source code base.

The same goes for additional security patches for 2.4.4 and 2.4.5 — only paying Adobe Commerce customers received security fixes after the end of regular support. For Magento Open Source, the end of regular support equals the real end of patches from Adobe.

In other words: if you’re running Magento Open Source 2.4.6, you don’t get a “soft landing” in the form of a year of extended support. On August 11, 2026, official patches disappear.

This changes the entire framing. Adobe’s marketing suggests the discussion is between “upgrade to Magento 2.4.8” and “switch to Adobe Commerce.” In reality, for most Open Source merchants, the question is: “what do I do when nobody officially ships a patch for my version anymore?”

A second, less visible nuance: not every Magento Open Source feature shares code with Adobe Commerce. Some modules — B2B, the full version of Page Builder, advanced reporting, Live Search, Product Recommendations — are commercial-only. A store trying to “move from Open Source to Adobe Commerce” doesn’t just buy the license — it often has to rewrite its own custom modules or replace them with Adobe Commerce’s commercial features.

Nobody measures the scale of the problem consistently

The “88,000 Magento stores” number floating around LinkedIn is significantly understated. Three independent trackers report different numbers depending on methodology:

• StoreLeads: ~119,000 actively maintained stores
• W3Techs: ~130,000 live websites
• BuiltWith: ~162,000 installations (including dev/staging)

The trend is unambiguously downward. Magento is losing stores at low double-digit percentages annually:

• −3.8% quarter-over-quarter in Q3 2025
• −11% year-over-year in Q3 2025
• −15% year-over-year in Q1 2026

BuiltWith alone shows that Shopify absorbed over 500 ex-Magento stores in a single 90-day window. This isn’t “Magento dies next year” — this is “Magento loses an eighth of its base every year, and the rate is accelerating.”

The European mid-market is a representative slice of this global trend. Magento dominated mid-market e-commerce in much of Europe through the first half of the previous decade. Today, migrations to Shopify Plus, BigCommerce, and headless are conversations I’m having every month.

What actually happens under the hood when you stay on an unsupported version

This is where the technical perspective matters, because that’s what determines real risk. The store doesn’t break on the day support ends — it slowly rots from the inside.

Security

Magento is an attractive attack target. Magecart, skimmers, RCE in extensions, deserialization issues — these aren’t hypothetical threats, they’re history every year. Every new CVE in PHP, in libraries (Symfony, Laminas, Composer dependencies), in the platform itself no longer gets an official patch for your version. You’ll backport some fixes from community patches by integrators, but those are half-measures — no quality guarantee, no regression tests, no support in case of an incident.

Adobe introduced a new release model in 2025: monthly security patches plus two large patch bundles per year (May and November). It sounds good — provided you’re on a supported line. After the end of regular support, you don’t even get that.

PCI DSS and compliance

PCI DSS doesn’t ask whether your store “works.” Requirement 6.2 explicitly says: “all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.” Lack of a supported version = automatic red flag in an audit. For card-processing merchants, this is a concrete legal-financial problem: higher acquirer fees, risk of losing the merchant account, in extreme cases frozen payouts.

On top of that comes GDPR. A store storing personal data on an outdated platform — in case of a breach — will have a much harder conversation with the data protection authority. Article 32 GDPR requires “appropriate technical measures” to safeguard data. An out-of-support e-commerce platform is exactly what Article 32 disallows.

Payment and shipping integrations

Every market has its own payment landscape, and the gap between supported and unsupported platforms shows up here first. In the European market alone:

• Stripe — increasingly the default for cross-border
• Klarna — pay-later dominant in DACH and Nordics
• PayPal — still ubiquitous baseline
• Adyen — enterprise-grade in EU
• Local schemes — BLIK in Poland, iDEAL in the Netherlands, Bancontact in Belgium, Swish in Sweden, MB WAY in Portugal

Each of these regularly updates its API, signature formats, TLS requirements. Every change on the operator’s side requires a module update on the store’s side. Magento without support means either backporting changes manually or waiting for an integration to stop working.

Shipping is the same story. DHL, DPD, GLS, FedEx, UPS, plus regional players: InPost, Hermes, Chronopost, GLS, Bring. Every carrier has its own API, its own Magento modules, its own update cycles.

In practice: every store uses 5–10 external modules that regularly need updates. On an unsupported platform, some of them will start drifting within 6–18 months.

E-invoicing and tax automation

Across the EU, mandatory e-invoicing rollouts are happening on different timelines: Italy already mandatory, France phasing in, Poland (KSeF) live, Germany on the schedule. Each of these requires platform integration with a national tax authority API. These integrations typically run through ERP systems (SAP, Microsoft Dynamics, regional players like Comarch in Poland or DATEV in Germany). Every change in compliance requirements means an update to the bridge module. Outdated platform + outdated tax module = the risk that a year from now you can’t legally issue invoices.

PHP, MySQL, and infrastructure

Magento 2.4.6 supports PHP 8.2/8.3. PHP 8.2 reaches EOL in December 2026. MySQL 8.0 has its own support horizon. Every runtime component has its own lifecycle, independent of Magento. After a while, you start swimming in a mix of “old Magento + old PHP + old MySQL” where no layer is officially supported anymore.

On top of that come the core dependencies: Elasticsearch / OpenSearch, RabbitMQ, Redis, Varnish. Each has its own support cycle. A store sitting on this infrastructure layer for 5 years without updates, at some point, becomes un-migratable — not because of Magento, but because the entire surrounding infrastructure has rotted.

Growing technical debt

Every module, every override, every change in core — over months, the upgrade gets harder to estimate. Each additional year of neglect raises the cost of leaving the platform by tens of percent.

This isn’t “the store will stop working on August 11, 2026.” This is “from a certain point onward every change will hurt twice as much, and in case of an incident you have no official point of contact.”

Hosting and maintenance — what the platform itself doesn’t cost

One of the things “free” in “Magento Open Source” doesn’t include is the real cost of operations. Magento is architecturally heavy. The minimum production stack for a mid-sized store (50–200 orders/day) looks like this:

• Web server (Nginx + PHP-FPM 8.x), minimum 4 vCPU / 16 GB RAM
• Database (MySQL 8 / MariaDB), minimum 2 vCPU / 8 GB RAM, NVMe SSD
• Cache (Redis), minimum 1 vCPU / 4 GB RAM
• Search (Elasticsearch / OpenSearch), minimum 2 vCPU / 8 GB RAM
• Message queue (RabbitMQ), optional but often necessary
• Reverse proxy / FPC (Varnish), practically mandatory in production
• CDN + WAF (Cloudflare, Bunny, AWS CloudFront)

Real infrastructure cost for a mid-sized Magento store: $700–1,500/mo self-hosted (Hetzner / OVH / own DC), $1,500–4,500/mo on AWS / GCP, $4,000–15,000+/mo on Adobe Commerce Cloud.

For comparison:

• Shopify Plus: hosting included, platform fee $6,000–20,000/mo + transaction fee 0.15–0.40%
• BigCommerce Enterprise: $10,000–30,000/year + hosting included
• Mage-OS on your own infrastructure: same as self-hosted Magento
• Medusa / Saleor self-hosted: $250–900/mo (much lighter stack — Node/Python vs. PHP-Magento)

You’re not just buying a platform. You’re buying a monthly bill that never goes away.

Four real paths — from a cost and operations perspective

Most articles about the end of Magento Open Source show three options: upgrade, Adobe ecosystem, migration. That’s an incomplete picture. There are four real paths, and the most interesting one isn’t on the infographics.

Path 1: Upgrade within Magento Open Source (to 2.4.8)

The cheapest move in the short term and the most obvious. You stay on the same code, the same modules, the same business logic. Adobe still publishes OS releases, so you get support through the end of 2.4.8 regular support (May 2028).

What’s actually involved in upgrading Magento 2.4.x → 2.4.8:

• updating Composer and all dependencies (often a chain of conflicts)
• updating custom modules (every setup.xml, every db_schema.xml)
• updating third-party modules (some may not have a 2.4.8 release)
• migrating deprecated APIs (every new Magento version removes part of the API)
• theme updates (including a possible migration to Hyvä)
• updating PHP to 8.3, compatibility checks
• a full regression cycle

When it makes sense:

• Your store has 50–500 modules, heavy core customization
• You have a tight team that knows the code
• You’re buying yourself 2 years of breathing room to plan the next move

Real costs (2025–2026 benchmark):

• Small store, ~15 extensions: $3,500–8,500
• Mid-sized, 50–100 modules: $10,000–30,000
• Large, heavily customized: $35,000–125,000+

What you don’t get for that price: performance improvements, frontend modernization, technical debt reduction. This is an “as-is” migration — a refurbished cage. After the upgrade you get exactly the same Magento, just newer.

Important nuance: upgrading 2.4.4 to 2.4.8 isn’t a single step. You usually have to go through at least one intermediate version (2.4.6 or 2.4.7) so extensions and custom modules can apply their migrations. Plan it in phases.

Path 2: Adobe Commerce (the paid ecosystem)

Adobe is pushing the entire ecosystem toward cloud and AI: Edge Delivery Services, Commerce Drop-ins, App Builder, Live Search, Product Recommendations (AI-driven). These tools are available only to Adobe Commerce customers, most often Adobe Commerce Cloud.

When it makes sense:

• Annual revenue can absorb the Adobe Commerce license (starts at ~$22,000/year for the smallest plans, runs into hundreds of thousands for enterprise; pricing usually scales with GMV)
• You need B2B accounts, advanced personalization, multi-source inventory, AI search out-of-the-box
• You have an internal DevOps team and enterprise infrastructure
• You’re already in the Adobe stack (AEM, Marketo, Target) and integrations are a real argument

Real costs:

• license: from ~$22,000/year up (scales with GMV)
• implementation / migration: $50,000–375,000
• hosting (Adobe Commerce Cloud): $4,000–15,000+/mo
• maintenance: $2,000–10,000/mo

For most mid-market stores, this is disproportionately expensive.

The vendor lock-in trap: Edge Delivery Services sounds impressive (Lighthouse 100, edge nodes, content authoring in Google Docs), but it’s tight lock-in into Adobe Cloud. Leaving this path a few years from now will be more expensive than leaving today’s Magento Open Source. App Builder runs only on Adobe IO Runtime. Commerce Drop-ins are written for specific Adobe Commerce APIs. The deeper you go, the harder it is to leave.

That doesn’t make it the wrong call — for some stores, Adobe Commerce is exactly what they need. But it’s a strategic 7–10 year decision, not a tactical one.

Path 3: Migration to another platform

This is where most of the market motion is. Five main directions:

Shopify / Shopify Plus — the largest stream of migrations from Magento. Pros: SaaS, zero infrastructure maintenance, the best app ecosystem (>10,000 in the App Store), an excellent checkout out-of-the-box, the most polished mobile experience. Cons: the “platform fee + transaction fee” model, API limits (call limits, storage), limited backend control, harder complex pricing logic. Liquid as a templating language is opinionated.

In a European context: Shopify handles regional payment schemes (BLIK, iDEAL, Klarna, etc.) through dedicated gateways. Local shipping integrations are uneven — InPost has an official integration, smaller regional carriers may need third-party apps. E-invoicing typically runs through an external bridge. Shopify Plus starts at ~$2,300/mo, with negotiated pricing for higher volumes.

A good fit for B2C stores without complex pricing or inventory logic.

BigCommerce — frequent candidate in mid-market RFPs. Cheaper fees than Shopify Plus, better B2B out-of-the-box, headless API in the standard plan, no transaction fees on your own payments. Smaller app ecosystem than Shopify, but sufficient for mid-market.

commercetools — enterprise headless. Expensive (from ~€50,000/year), but for stores with genuinely complex logic (multi-brand, multi-region, multi-channel, B2B + B2C in one) often the cleanest move. MACH-native (microservices, API-first, cloud-native, headless).

WooCommerce — still the largest e-commerce platform on the web by install count. For small and mid-sized stores with strong content (blog, content marketing) it’s often a solid choice. Most regional integrations have mature plugins. The limit: WooCommerce doesn’t scale well above a few thousand orders per month without serious optimization investment.

Open source headless — Medusa (Node/TS), Saleor (Python/Django, GraphQL-only), Vendure (TypeScript). For technical teams that want full control and don’t want to fall into a new cloud dependency.

• Medusa — closest to Magento’s “way of thinking” (extensible core, similarly structured data model), fastest growing in 2026, the best DX for Node/TS teams. Medusa Cloud is an option, but self-hosted works great.
• Saleor — most “enterprise” of the three, GraphQL API, multi-channel native, B2B and B2C support in a single store. Python + Django + GraphQL stack, so it requires a team with a specific profile.
• Vendure — TypeScript-first, strong plugin system, mature ecosystem. A good choice if your team already works in TypeScript end-to-end.

Real platform migration costs (2025–2026 benchmark):

• Small store: $25,000–45,000
• Mid-sized: $55,000–115,000
• Enterprise: $140,000–300,000+
• Timeline: 4–9 months depending on scale and data volume
• Plus post-launch support $2,500–11,000 and training $1,250–5,000

2–3× more expensive than upgrading within Magento, but it usually gives a measurable return through lower maintenance costs in subsequent years.

Path 4: Mage-OS + Hyvä — the option nobody with a marketing budget pushes

This is the most interesting thread in the whole story, and the one missing from the LinkedIn graphics.

Mage-OS is a non-profit, community-driven fork of Magento Open Source. It originated in 2021 from the community’s open letter to Adobe. Today (2026) it’s a serious, production-used project:

• Mage-OS 2.0 released October 2025
• Mage-OS 2.2.0 is the current release
• Mage-OS 3.0 planned for May 2026, in parallel with Magento 2.4.9
• Includes upstream security patches from Adobe + additional community fixes
• Often a faster patch cycle than official Magento OS

Hyvä — the frontend that effectively buried Adobe PWA Studio. In November 2025 it became fully open source. Magento + Hyvä + Mage-OS is today the most actively developed stack in the Magento community. Hyvä replaces the old Knockout/UI-Component frontend with lightweight Alpine.js + Tailwind, hitting genuine 90+ Lighthouse scores out-of-the-box.

When it makes sense:

• You keep the entire business logic (modules, integrations, data)
• The migration is comparable in cost to a regular upgrade
• The patch cycle is faster than official — no other path offers this advantage
• No vendor lock-in — you can return to official Magento if you change your mind
• Regional integrations (payments, carriers, ERPs) work the same as on Magento OS

What it doesn’t solve:

• Magento is fundamentally heavy — Mage-OS doesn’t change that
• The community is smaller than the Adobe ecosystem
• Some commercial modules may not be tested on Mage-OS
• No commercial support — you’re responsible for the store yourself (through an integrator)

For many mid-market stores that have already invested $50,000–125,000 in custom Magento modules, Mage-OS + Hyvä is the cheapest move that preserves the value of that investment. It’s a path worth considering before signing a migration contract.

Comparison table — what you’re actually choosing

B2B vs B2C — different paths for different models

Often overlooked: the recommendation depends heavily on whether you sell B2C, B2B, or a mix.

Pure B2C (catalog store, lifestyle, fashion, FMCG):

• Most common move: Shopify Plus
• Alternative: BigCommerce, Mage-OS + Hyvä
• Least sensible: commercetools, Adobe Commerce for small stores

B2B with simple logic:

• Most common move: BigCommerce (very strong B2B out-of-the-box) or Magento upgrade
• Alternative: Mage-OS + Hyvä, Saleor

B2B with complex logic (multi-tier pricing, contracts, trade credit, ERP integration, custom catalogs per customer):

• Most common move: Adobe Commerce or commercetools
• Alternative: Magento upgrade + custom modules, Saleor (strong B2B in core)
• Not recommended: Shopify (B2B in Shopify is maturing but still rough)

B2C + B2B in one store:

• Saleor is the least painful choice — multi-channel in core is exactly that
• Adobe Commerce has it, but expensive
• commercetools has it, even more expensive
• Magento attempts it, but it’s brutally complex

These are rough buckets — every concrete store has its own specifics.

Migration and SEO — the playbook you can’t get wrong

One of the two most common causes of migration disasters is the lack of an SEO strategy. The other is the lack of a data strategy. Here, on SEO.

A platform migration is a scenario in which you can lose 30–60% of organic traffic in 4–8 weeks if you don’t think about it upfront. Lost traffic is lost revenue, and recovering rankings can take a year.

Things that must be done before the migration:

1. Full crawl of the old store. Screaming Frog, Sitebulb, JetOctopus — pick one, but do a complete inventory of every URL, HTTP status, title, meta description, canonical, hreflang, schema, rel=prev/next. Export to CSV as a baseline.

2. 1:1 URL mapping. Old URL → new URL. Every one. Products (obvious), categories, filters, pagination, blog (if any), static pages, help pages, policies, FAQ. The most common mistake: you remember products and categories, you forget pagination /category?p=2 and filters. Google has those indexed.

3. 301 strategy. All 301s must be implemented from the day the new store goes live, not a week later. Best at nginx / Cloudflare Workers / reverse proxy level, not at the application layer (faster, less load).

4. Hreflang. If you have language versions (EN/DE/PL), make sure the new platform generates hreflang correctly. Botched hreflang = duplicate content, keyword cannibalization.

5. Schema markup. Product, Offer, AggregateRating, Review, Breadcrumb, Organization. Whatever you had has to be on the new store. Google scores structured data and notices its absence immediately.

6. XML sitemap and robots.txt. After the new store goes live, the new sitemap must be submitted to Google Search Console immediately. The old sitemap stays for the duration of the crawl (a few weeks) so Google sees the 301s.

7. Core Web Vitals baseline. Measure LCP, INP, CLS before migration. After migration they should be better, not worse. If they’re worse — you have a problem you won’t notice until it starts hurting rankings.

After the migration:

• Monitor 404s in Search Console (alert on a sudden spike)
• Re-submit sitemap immediately after launch
• Re-validate structured data in Search Console
• Track rankings on top keywords (Ahrefs, Semrush, Sistrix) — daily for 4 weeks
• Regenerate internal linking if needed

This is a topic for a separate article, but if you skip this part, the entire migration is at risk.

Three real migration patterns I see most often

Instead of hypothetical examples, here are three patterns I run regularly. Details are anonymized; the numbers are real.

Scenario A: mid-sized B2C on Magento Open Source 2.4.4 → Mage-OS + Hyvä

A fashion store, ~500 products, ~1,500 orders/month, 20 custom modules, integrations with regional payment gateways, InPost, Comarch ERP.

What I did: a technical upgrade from Magento 2.4.4 → Mage-OS 2.2 + replacing the Luma frontend with Hyvä.

• Time: 12 weeks
• Cost: ~$23,000
• Result: maintenance cost dropped ~30% (lighter frontend = smaller server), Lighthouse jumped from 38 to 91, page load -55%
• All integrations stayed, data didn’t move, e-invoicing kept running through the ERP

This is a pattern worth considering first if you don’t have a fundamental problem with Magento itself.

Scenario B: mid-market B2C on Magento 2.4.5 → Shopify Plus

A home furnishings store, ~3,000 products, ~6,000 orders/month, heavy content marketing, ~80 Magento modules (half unused).

What I did: full platform migration + frontend redesign + module audit (some unused modules dropped).

• Time: 7 months
• Cost: ~$93,000 migration + $7,500 post-launch
• Result: infrastructure maintenance gone (Shopify Plus), dev costs dropped ~60%, conversion went up ~18% (mainly thanks to Shopify checkout)
• Loss: lost some of the customization Magento gave for free; reduced control over promo logic
• Organic traffic: -22% in the month after migration, -8% after 3 months, +5% after a year (vs baseline)

This move makes sense if you don’t need deep backend customization and you value zero infrastructure maintenance.

Scenario C: B2B on Magento 2.4.6 → Saleor

A parts wholesaler, ~10,000 SKUs, customer contracts, per-contract pricing, trade credit, ERP integration (custom system + partial Comarch).

What I did: full migration to self-hosted Saleor, custom Next.js storefront, custom modules for pricing and contract logic.

• Time: 9 months
• Cost: ~$175,000
• Result: time-to-market for new features dropped from ~6 weeks to ~1 week (GraphQL + modern stack), hosting costs dropped 4× (Saleor is dramatically lighter than Magento)
• Loss: had to build the payment gateway integration from scratch, ERP got a custom bridge too

This is a pattern for technical teams that want full control and are willing to invest in custom solutions.

Decision tree — how I think this through

The first thing I do with a client is inventory the current store, not pick a new platform. Without that, the migration conversation is speculation.

The questions I ask first:

1. How many custom modules / overrides do you have? If fewer than 10 and they’re simple — platform migration is easy. If more than 50 and they’re complex — leaving Magento is very expensive.
2. What’s the annual GMV and what are the margins? If GMV can’t absorb a $30k/year license, Adobe Commerce is out immediately. Low GMV with high margins (e.g. luxury) is a different calculation than high GMV with thin margins.
3. What are the external integrations? ERP, PIM, carriers, marketplaces, e-invoicing. Every integration is potentially $1k–10k of re-implementation cost.
4. Does the team (in-house or external) know another stack? Migrating to Saleor when nobody writes Python adds 6–12 months of learning. Migrating to Medusa with a Node-experienced team — completely different scenario.
5. What’s your time horizon? A store with 2 years to make the move has different options than one that wants to be on a new platform in 6 months.
6. What’s the risk tolerance? Migrating in peak season is risk. Migrating in January/February — minimal. Some industries (seasonal e-commerce) have realistically only 2–3 months a year when a cutover is even possible.

Realistic matching looks roughly like this today:

• Simple B2C up to $1.5M annual revenue → Shopify, sometimes WooCommerce, rarely Magento upgrade
• Mid-sized B2C, tens of millions, heavy customization → Mage-OS + Hyvä or BigCommerce
• B2B with complex pricing / contracts → commercetools or Adobe Commerce, alternatively Saleor
• Headless-first, strong tech team → Medusa or Saleor
• Enterprise with strong Adobe stack and budget → Adobe Commerce Cloud + Edge Delivery
• Store with $50k+ invested in custom Magento, working ecosystem → Mage-OS + Hyvä, almost always

There’s no single right answer.

Migration plan, week by week

A realistic plan for a mid-sized B2C store migrating from Magento 2.4.5 to Shopify Plus (or Mage-OS — the process is 70% the same). Scale: 3,000 products, 5,000 orders/month, 8 external integrations.

Phase 0: Audit (4 weeks) — before the decision

• Full inventory of modules, extensions, customizations
• Integration inventory (each separately: API, data format, auth, retry strategy)
• Full SEO crawl (Screaming Frog, CSV export)
• Data inventory (products, customers, orders, reviews, carts, wishlists)
• GMV by category, top 100 products, top 50 keywords

Phase 1: Decision and contract (2 weeks)

• Platform selection
• Vendor selection (RFP, bids, references)
• Contract, schedule, milestones

Phase 2: Setup (3 weeks)

• Provisioning the new platform (store, hosting, repo)
• Base configuration (currencies, languages, taxes, units)
• CI/CD setup, staging environment
• Analytics setup (GA4, GTM, Search Console, Meta Pixel)

Phase 3: Data migration (4 weeks)

• Product migration script (categories → collections, attributes → metafields, variants)
• Customer migration script (with password hashes — every platform has its own approach)
• Historical order migration script (read-only, for customer service)
• Content migration (blog, static pages, policies)
• Redirect migration (URL mapping → 301)

Phase 4: Frontend (4 weeks)

• Design implementation on the new platform
• Storefront components (PLP, PDP, cart, checkout)
• Mobile (typically 60%+ of traffic)
• Search & filters
• Performance optimization (LCP, INP)

Phase 5: Integrations (5 weeks)

• Payments (Stripe, Klarna, regional schemes, Apple Pay, Google Pay)
• Carriers (DHL, DPD, regional)
• ERP / accounting / e-invoicing
• Marketing (Klaviyo / Mailchimp / Edrone, push, ads)
• Reviews (Trustpilot, Yotpo, Reviews.io)

Phase 6: Regression testing (3 weeks)

• Full E2E cycle (preferably automated — Playwright or Cypress)
• Payment testing in sandbox
• Edge case testing (returns, partial returns, cancellations, double orders)
• Load testing (before Black Friday — mandatory)
• UAT with real users (5–10 people, loyal customers + customer service team)

Phase 7: Soft launch (2 weeks)

• Beta on a subdomain (new.store.com)
• Letting in 5–10% of traffic (e.g. via Cloudflare load balancing)
• Monitoring conversion, funnel, errors (Sentry, LogRocket)
• Iterate, fix, retest

Phase 8: Cutover (1 day + 4 weeks of monitoring)

• DNS switch (preferably overnight Tuesday-Wednesday — lowest traffic)
• 301s active immediately
• 404 monitoring hourly for the first 3 days
• Search Console: re-submit sitemap, monitor crawl errors
• Daily team standup for 4 weeks

Total: 7–8 months of real work, ~28 weeks on the schedule.

This is a fast plan, for an experienced team. Real projects usually add 30–50% buffer for things nobody anticipated.

What not to do in a migration plan

A few mistakes I see repeatedly:

Big-bang cutover. Turn off the old store Friday, turn on the new one Monday. Average downtime cost is ~$5,600/min per IT benchmarks — and that’s not counting reputation damage. If a gradual cutover is possible (subdomain for the new store, redirects per category), it’s always worth it.

“As-is” migration. Moving all 80 modules 1:1 to the new platform usually wastes half the budget. Migration is the one moment when you can honestly ask: which of these 80 modules are actually used? Half turn out to be dead code.

No data inventory. SKUs, customers, orders, reviews, SEO redirects. Each of these needs a thought-through migration plan, including 301 URL mapping (not just product pages — categories, filters, pagination). Lost Google rankings can cost more than the migration itself.

Choosing a platform before choosing a team. The best platform for a team that doesn’t know it isn’t the best platform.

No regression tests. I keep saying this in the context of any major change — it applies here too. Migration is the scenario where a solid E2E test suite (Playwright or Cypress) pays for itself in weeks of manual work you don’t have to repeat after every iteration.

Migrating in peak season. If your store has a season (holiday, summer, back-to-school), absolutely don’t plan the cutover during it. Every percent of conversion lost in peak season costs many times more than keeping the old platform alive a month longer.

No rollback plan. First rule of cutover: you must be able to go back. DNS must be reversible in 5 minutes, the data on the old platform must remain consistent and current for at least a week post-cutover, the old platform’s infrastructure must run in parallel.

Skipping e-invoicing / tax compliance. In several EU markets in 2026 this is no longer optional. Every new platform must have working tax-compliance integration from day one of launch, otherwise you risk being unable to legally issue invoices.

Migration without an SLA. A migration the “agency does and walks away from” is a migration that leaves you stranded after the first serious bug. SLA + a post-launch retainer for at least 3 months is a standard, not a luxury.

Myths I hear regularly

“Magento is free.” The code is. Hosting, maintenance, integrators, extensions, security patches — all cost money. Real Magento TCO for a mid-sized European store is $2,000–6,000/month all in.

“Adobe is shutting down Magento Open Source.” It isn’t. It’s stopping support for specific versions. The project itself still exists, the code is on GitHub, the community (including Mage-OS) maintains it.

“Moving to Mage-OS is risky.” Less risky than staying on an unsupported version of official Magento. Mage-OS receives all upstream Adobe patches + additional community fixes.

“Shopify is for small stores.” Shopify Plus serves stores with billions in GMV (Gymshark, Allbirds, Heinz). What used to be “for small stores” is enterprise-ready today.

“Headless is the future, monolith is the past.” Headless is just an architecture. For many stores a monolithic platform with a strong frontend (Hyvä, Liquid) is cheaper to maintain and faster to build than headless. Headless makes sense when you need multiple channels (web + mobile + POS + IoT) or a very specific UX.

“Migration always wrecks SEO.” Not always. A well-planned migration with full URL mapping, 301s, and structured data can come out neutral, sometimes positive (if the new platform is dramatically faster).

“Adobe Commerce is the enterprise standard.” For many enterprises, yes — but commercetools, BigCommerce Enterprise, Salesforce Commerce Cloud, and headless are growing faster than Adobe Commerce.

The timeline I keep for clients

A concrete plan if you’re on Magento Open Source today (May 2026):

You’re on 2.4.4 or 2.4.5:

• Right now — audit, platform decision, in case of delay minimum upgrade to 2.4.7
• By end of 2026 — implement target path

You’re on 2.4.6:

• Q2–Q3 2026 — audit, decision
• By August 2026 — minimum upgrade to 2.4.7 or 2.4.8 (regular support for 2.4.6 ends August 11, 2026)
• Q4 2026 – Q1 2027 — target implementation

You’re on 2.4.7:

• Q3–Q4 2026 — audit
• Q1–Q3 2027 — target implementation, before regular support for 2.4.7 ends (May 2027)

You’re on 2.4.8:

• you have the most time, regular support through May 2028
• 2026 — strategic planning of the next move (upgrade to 2.4.9, migration, Mage-OS)
• 2027 — implementation

In every scenario, the first step is the same: an honest audit of the current state.

What’s next — AI, agentic commerce, edge delivery

The discussion about Magento Open Source is happening in a broader context worth being aware of when making a 5-year decision.

AI search in e-commerce. Adobe Live Search, Algolia AI, Klevu, Coveo — all of them are redefining how store search works. A store without proper AI search loses conversion to a competitor that has it. This is a platform differentiator: some have it natively (Adobe Commerce, Shopify), others require integration.

Agentic commerce. Early stage but real. AI assistants buying on behalf of users (ChatGPT with Stripe, Perplexity Shopping). Your platform has to be ready to expose clean APIs for products / prices / inventory so AI agents can actually talk to it. Headless platforms are by definition better positioned here.

Edge delivery. Rendering at edge nodes, content authoring in modern tools (Sanity, Contentful, Adobe Edge Delivery). Lighthouse 100 is becoming the standard, not the ambition.

AI-driven personalization. Individual pricing, individual collections, individual recommendations per user. Adobe Commerce is strong here, but headless platforms + a modern stack will catch up quickly.

These are all early trends in 2026 but will be table stakes by 2028–2029. Today’s platform decision should account for them.

In short: is the panic justified?

No, if you understand where the real risk actually is. Yes, if you’re on 2.4.4/2.4.5 and have no plan.

Adobe isn’t shutting down Magento Open Source as a project. Adobe is stopping support for old versions — and never had extended support for Open Source. The community (Mage-OS, Hyvä) is filling the gap faster than most Adobe communications suggest.

The worst decision is no decision. Every quarter of delay is additional technical debt, a more expensive migration, higher risk in a PCI DSS audit, higher risk of a security incident.

The best decision is inventory before strategy. Picking a platform is trivial when you have an honest list: how many modules you have, which ones are used, how much data needs to move, which integrations are critical, who’ll do the work. Without that list, every agency will sell you what they know best.

If you run a Magento store and want to talk through a specific situation — drop me a line. One conversation is usually enough to lay out a risk hierarchy and show 2–3 realistic options with rough quotes.