Magento 2 End of Life: Adobe’s Real Support Dates and Your Three Options

There’s no Magento 2 end of life date. Adobe publishes support dates for each release line, not for the platform as a whole, and several lines crossed a support boundary in 2026. On Adobe’s lifecycle policy page (opens in new tab), extended support for 2.4.4 ended April 14, 2026, and extended support for 2.4.5 ended August 11, 2026, the same day standard support for 2.4.6 ended.

Those dates are why “Magento 2 end of life in 2026” keeps coming up, but they end support for specific versions. Magento 2 itself doesn’t end.

Your actual deadline depends on three things you can look up quickly: which release line you run, whether you’re on Adobe Commerce or Magento Open Source, and whether your store runs on Adobe Commerce on Cloud or on your own servers. We build Shopify stores and move merchants off Magento, and this is the breakdown we give a merchant who asks how long they have.

Every Magento 2 date below links to Adobe’s own documentation, all read on September 23, 2026. Adobe revises these pages (the lifecycle policy was last updated September 18, 2026), so check the linked page before you commit to a date.

No. Adobe’s lifecycle policy (opens in new tab) offers “a three-year standard support window from the General Availability (GA) date for each version.” None of Adobe’s lifecycle, release, or support pages gives an end date for Magento 2 as a whole. Adobe is still shipping new release lines: Adobe Commerce 2.4.9 reached general availability on May 12, 2026, and Magento Open Source 2.4.9 has its own release notes (opens in new tab), last updated May 22, 2026.

So a question about Magento 2 end of life is really a question about your release line. On Adobe’s schedule, a store on 2.4.9 has standard support until May 31, 2029. An Adobe Commerce store on 2.4.4 is already past standard and extended support and gets security-only fixes until May 31, 2027. Both stores run Magento 2.

Adobe’s support comes in three tiers. On the lifecycle policy page (opens in new tab), “Standard support includes quality fixes, security patches, and full Adobe Commerce on-call support,” and it runs three years from a line’s release date. The contractual lifecycle policy PDF (opens in new tab) says the same for 2.4.4 onward: a three-year Software Support Period from each version’s release date.

Extended support is the second tier. Adobe “offers one year of additional support at no additional cost for Adobe Commerce customers on versions 2.4.6 and 2.4.7,” covering “quality and security patches for the core application.” The two older lines have already used their extra year. The same page says “Extended support for Adobe Commerce 2.4.4 and 2.4.5 versions ends in April and August 2026 as planned.”

The third tier is temporary. Adobe describes it as “A one-time, time-limited transitional period available only for versions 2.4.4, 2.4.5, and 2.4.6,” and it “provides limited isolated security fixes only (no quality fixes).” Adobe also tells merchants how to use it: “Treat the security-only period as migration time, not as a long-term support tier.” And it adds, “It will not be extended beyond the published dates.”

Two more rules on that page affect every tier. Hotfixes for critical issues go “for all customers on a supported version,” so a line outside all three tiers doesn’t get them. And the software your store runs on is your responsibility: “Adobe does not provide security and quality fixes for third-party services and software dependencies (such as PHP and MySQL) that may reach end of life while customers are in the three-year or extended support period for Adobe Commerce.”

The table below comes from Adobe’s lifecycle policy (opens in new tab), checked line by line against Adobe’s Released versions page (opens in new tab) and its Required actions and deadlines page (opens in new tab), which the lifecycle page calls the Security and Compliance Notice. Every date is for Adobe Commerce, the licensed product. The last column applies only to Adobe Commerce on Cloud, Adobe’s platform-as-a-service hosting, and gives the date by which a Cloud store must upgrade or move to Adobe Commerce as a Cloud Service.

Here’s where each line stands on September 28, 2026, from that table. 2.4.9 and 2.4.8 are in standard support, and 2.4.7 stays in standard support until May 31, 2027. 2.4.6 is in extended support. 2.4.4 and 2.4.5 are past standard and extended support and are in the security-only period, which ends May 31, 2027.

Older lines are already out. The Released versions page (opens in new tab) lists regular support ending November 28, 2022 for 2.4.0 through 2.4.3, September 8, 2022 for 2.3, December 1, 2019 for 2.2, June 30, 2019 for 2.1, and March 31, 2018 for 2.0.

The Released versions page (opens in new tab) says “Regular support for the 2.4.6 release line ended on August 11, 2026.” It gives the extended date as “Extended support for the 2.4.6 release line ends on August 31, 2027,” which matches the lifecycle policy table (opens in new tab). Adobe’s Required actions page (opens in new tab) gives the same support “through August 30, 2027,” and so does the system requirements page (opens in new tab). Adobe’s pages disagree by a day, so plan against August 30.

After extended support, 2.4.6 moves into the security-only period, which the lifecycle table ends on May 31, 2028.

The PHP runtime is the earlier constraint for 2.4.6. Adobe’s system requirements (opens in new tab) list PHP 8.2 or 8.1 for 2.4.6. The lifecycle page (opens in new tab) lists PHP 8.1’s end of life as December 31, 2025, and PHP 8.2’s as December 31, 2026, affecting “2.4.6 (where PHP 8.2 is used).” PHP’s own supported versions page (opens in new tab) gives the same December 31, 2026 end of security support for 8.2.

Adobe’s advice for those stores is to “plan upgrade or migration before the end of 2026 to maintain PCI compliance.” The same page adds that “PCI compliance is the merchant’s responsibility to assess.” A 2.4.6 store therefore stays inside Adobe’s extended support until August 2027, but its runtime reaches end of life about eight months earlier.

On the lifecycle policy table (opens in new tab), extended support ended April 14, 2026 for 2.4.4 and August 11, 2026 for 2.4.5. Both lines now receive only isolated security fixes, and only until May 31, 2027. The Released versions page (opens in new tab) lists 2.4.5-p17, dated May 12, 2026, as the newest 2.4.5 patch.

These two lines are also stuck on an old PHP version. Adobe’s system requirements (opens in new tab) list only PHP 8.1 for 2.4.4 and 2.4.5, and PHP’s end-of-life page (opens in new tab) dates 8.1’s end of life to December 31, 2025. A store on either line can’t move to a supported PHP version without moving to a newer release line. On Cloud, the upgrade deadline for both is June 1, 2027.

2.4.7 has the most time of the lines under pressure. The lifecycle policy (opens in new tab) keeps it in standard support until May 31, 2027 and in extended support until May 31, 2028, with no security-only period after that. On Cloud, its upgrade deadline is June 1, 2028.

Adobe’s PHP table ties the PHP 8.2 date only to 2.4.6. The system requirements (opens in new tab) list PHP 8.3 or 8.2 for 2.4.7, so our reading of the two tables together is that a 2.4.7 store still on 8.2 faces the same December 31, 2026 PHP end of life. Moving that store to 8.3 is a smaller job than changing release lines.

For comparison, standard support runs until May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9, with extended support not yet announced for either.

The dates above are Adobe Commerce dates. The contractual lifecycle policy (opens in new tab) says “Specifically, this Policy does not apply to Magento Open Source.” Adobe’s security patch overview (opens in new tab) and release policy (opens in new tab) both say “Extended support security patches are available to Adobe Commerce customers only. They are not available for the Magento Open Source code base.”

We couldn’t find a separate Magento Open Source support schedule on any of these pages: the lifecycle policy, Released versions, Required actions, the security patch overview, the release policy, the end of support FAQ, and the contractual PDF. That means Adobe doesn’t publish one there. It doesn’t mean Adobe has dropped Open Source. It shipped Open Source 2.4.9 in May 2026.

Our reading of those two statements is this: once an Open Source release line leaves standard support, Adobe documents no extended-support patch path for it, because extended patches are for Commerce only. If you run Open Source, treat the Adobe Commerce end of standard support for your line as your working Magento end of life date.

Enforcement is new in this cycle, and it applies to Adobe’s hosting, not to the software license. The Required actions page (opens in new tab) applies to “Adobe Commerce on Cloud (PaaS) environments running Adobe Commerce versions 2.4.4 through 2.4.9.” It also says “This guidance does not apply to Adobe Commerce as a Cloud Service (SaaS) environments or Adobe Commerce on-premises deployments.”

The lifecycle policy (opens in new tab) says “Starting June 1, 2027, Adobe will no longer maintain Cloud environments running unsupported Commerce versions,” and describes what follows: “This includes suspending traffic to the affected infrastructure. As a result, your ecommerce storefront will go offline.”

The Required actions page sets the deadline by version. Cloud stores on 2.4.4 or 2.4.5 have to upgrade or move to Adobe Commerce as a Cloud Service by June 1, 2027. Stores on 2.4.6 or 2.4.7 have until June 1, 2028, and for 2.4.8 or 2.4.9 an upgrade is “Not required at this time.”

Adobe gives two dates for what to do. The lifecycle page asks Cloud customers to move before their line’s extended support ends. The enforcement dates in the table are when traffic suspension can start, and each one comes after that line’s extended support ends.

The earliest Cloud deadline isn’t about release lines at all. It’s about the software a store runs on, and it applies to every Cloud version from 2.4.4 through 2.4.9. On the Required actions page (opens in new tab), Cloud stores must move MariaDB 10.5 and below to 10.6 or higher, any Elasticsearch to OpenSearch, and RabbitMQ 3.9 and below to 3.13 or higher, all by October 30, 2026. A second round is due May 31, 2027: PHP 8.1 and below to 8.2 or higher, MariaDB versions below 10.11 to 10.11, OpenSearch 1.x to a newer version, RabbitMQ versions below 3.13 to 4.3, and Redis 5 and below to Valkey 8 or higher.

How those two dates apply depends on the release line, and the page isn’t consistent here. For Cloud stores on 2.4.4 or 2.4.5, the page’s per-version table says dependency upgrades are “Required by October 30, 2026.” But the page’s dependency table gives May 31, 2027 for several items, including an OpenSearch 1.x row that names 2.4.4 and 2.4.5 customers. Plan against October 30 and get your line’s dates confirmed in writing by your account team.

For 2.4.6 through 2.4.9, the date is October 30, 2026 or May 31, 2027, depending on the software. Adobe’s system requirements (opens in new tab) note that “Elasticsearch 7.17 reached End of Support (EOS) on January 15, 2026.”

A Cloud store that misses its deadline on that page has its inbound traffic suspended, which takes the storefront offline, per the Required actions page. The same page gives a way out for stores that are close: “If you have concerns about meeting the deadline and need a short extension, please contact your account team or Adobe Support as soon as possible.” If a store stays non-compliant after suspension, the lifecycle policy (opens in new tab) says “Adobe may terminate cloud services, initiating the decommissioning process,” after which “all data and assets within the hosted ecommerce environment, including all instances, environments, and branches, will be permanently deleted and cannot be restored.”

A store on your own servers doesn’t get switched off. Adobe’s end of support FAQ (opens in new tab) says “No, Adobe Commerce software does not ‘shut down’ once the end of support date is reached or passed.” Traffic suspension is a policy for Adobe’s own Cloud hosting, and the Required actions page says it doesn’t apply to on-premises deployments.

What does change for a self-hosted store is support. The FAQ says “Once a version of Adobe Commerce software is no longer supported, that version is no longer PCI compliant,” and “Adobe Commerce will not work to resolve support tickets that were opened after the end of support date for that software version.” It also says you’ll no longer receive security patches, and it allows outside help: “Yes, you can look for security firms, developers, or partners who will provide support for unsupported versions of Adobe Commerce.”

The FAQ was last updated May 13, 2026, before the September revisions to the Cloud pages. It describes what happens to the software license. The Cloud pages describe what Adobe does to its own hosting.

Magento 1 reached end of life on June 30, 2020. None of the Magento 2 support tiers above apply to a Magento 1 store. If you’re still on Magento 1, the options below all start from a store that’s had no platform support since mid-2020.

Magento 2 works differently. Each release line gets its own dates, so the platform keeps running while individual lines go out of support. That’s why Magento 2 end of life depends on which version you run.

For Adobe Commerce on Cloud, the Required actions page (opens in new tab) lists two paths: upgrade to Adobe Commerce on Cloud 2.4.9, or migrate to Adobe Commerce as a Cloud Service. Leaving Adobe isn’t on the list. Replatforming to Shopify is the third path, and the support calendar sets the timeline for all three.

An upgrade keeps you on the platform your team and integrations already run on. On the lifecycle policy (opens in new tab), 2.4.9 has standard support until May 31, 2029, with extended support not yet announced. Adobe’s system requirements (opens in new tab) list PHP 8.5 for 2.4.9, so a store coming from 2.4.4 or 2.4.5 on PHP 8.1 moves up several PHP versions at once.

For Cloud customers, the Required actions page (opens in new tab) describes Adobe’s security cadence as “Monthly isolated security fixes for faster and predictable protection against critical vulnerabilities” and “Annual patch releases with long term support.” The tradeoff is the three-year window itself. By our math from Adobe’s policy, a store that lands on 2.4.9 in 2027 reaches the end of standard support on May 31, 2029, and Adobe hasn’t announced extended support for 2.4.9.

This is Adobe’s preferred path, and Adobe says so. Its lifecycle policy (opens in new tab) calls Adobe Commerce as a Cloud Service “Adobe’s recommended long-term destination for all Adobe Commerce on Cloud customers,” with the pitch that “You eliminate recurring upgrade cycles” and “Adobe manages all infrastructure, patching, and upgrades automatically.” That recommendation is addressed to Cloud customers, and it’s a vendor steering customers to another of its own products.

Adobe says its migration tooling is “available at no cost to you,” per the Required actions page (opens in new tab). We didn’t find pricing for the service or a migration timeline on any Adobe page we read, so get both in writing from your account team. Adobe’s service overview (opens in new tab) lists Commerce Storefront, Merchandising Services, Product Visuals, and Developer Platform as the products behind it.

The third path moves your catalog, customers, order history, URLs, and integrations to a different platform, and your store gets rebuilt on Shopify. It’s the only one of the three that takes you off Adobe entirely. It’s also the biggest change for your team’s day-to-day work, and it runs on the same deadlines, because the Magento store has to stay supported and online until cutover. Our Shopify migration services page describes how we run these moves across platforms.

Can Shopify’s own migration app import a Magento store? Shopify’s Store Migration app (opens in new tab) is free and built by Shopify. It says it moves “product and customer data into Shopify from Square, WooCommerce, Etsy, Wix, Amazon, eBay, Clover, and Lightspeed R/X (Vend).” Magento isn’t on that list.

The listing also offers to “Upload a CSV file or, on supported platforms, connect your account to import automatically with guided setup,” and it doesn’t say Magento CSVs are rejected. The older Store Importer app (opens in new tab) now shows “This app is not currently available on the Shopify App Store.”

That leaves CSV import, third-party migration apps, a Shopify Partner, or custom API work. Those are the methods Shopify’s migration guide (opens in new tab) describes, alongside manual copying. The same guide recommends importing products first, then customers, then historical orders. We’ve covered the same mechanics for another platform in our WooCommerce to Shopify migration guide.

Magento’s configurable products are where catalog mapping takes the most work. Shopify’s productOptionsCreate reference (opens in new tab) shows the error “Can only specify a maximum of 3 options.” Its ProductVariant reference (opens in new tab) says “By default, stores have a limit of 2048 product variants for each product.” Any Magento product with more than three configurable attributes has to be restructured before it can be imported.

Volume sets the import method. Shopify’s product import help (opens in new tab) caps product CSV files at 15 MB each, so larger catalogs get split across several files. Shopify’s developer docs (opens in new tab) say its bulk variant mutations can create, update, or reorder up to 2,048 variants at a time and delete up to 250 at a time.

Do customer passwords carry over? No. Shopify’s customer import help (opens in new tab) says passwords can’t be migrated from another store by CSV, so after the import you invite customers to set new ones. The same page caps customer CSV files at 15 MB.

Multipass (opens in new tab) doesn’t solve the password problem. Shopify’s docs say “Your store must be on a Shopify Plus plan,” and “Multipass login is only available with legacy Customer accounts, which needs to be explicitly chosen from your Customer Accounts settings in Shopify admin before you can enable Multipass.” Shopify describes what it does this way: “Multipass lets customers signed in on your external site log in to your Shopify store without entering credentials again, instead sending a signed token that redirects them.” That’s single sign-on from another site, not a password transfer.

Magento and Shopify build URLs differently. Adobe’s URL rewrite documentation (opens in new tab) says “Commerce uses ID-based URLs internally, but you can create SEO-friendly URLs for customers,” so a URL like /peripherals/keyboard.html sits on top of /catalog/category/id/6. On Shopify, URLs are built from handles: the Liquid docs (opens in new tab) say “The handle is used to build the URL for the resource,” giving paths like /products/{handle} and /collections/{handle}.

The redirect map translates Magento /{category}/{url-key}.html and /{url-key}.html product URLs to /products/{handle}, and Magento /{category}.html category URLs to /collections/{handle}. Adobe’s automatic product redirect documentation (opens in new tab) explains that saving a category can create product rewrites under category paths. Our reading is that one Magento product may be reachable at several URLs, and each of them needs its own redirect.

Shopify’s URL redirect help (opens in new tab) says a redirect only fires from a URL that no longer loads a page, and that redirects are 301s. It lists maximums of 100,000 redirects on non-Plus plans and 20 million on Plus.

It also says URLs with query strings may not redirect as expected, which by our reading matters for Magento’s filtered category URLs. Shopify’s redirect API reference (opens in new tab) says “Redirect paths are unique, so a shop can’t have more than one redirect with the same path.” The rest of the redirect process is in our SEO migration checklist.

B2B doesn’t require Shopify Plus. As of September 2026, Shopify’s pricing page (opens in new tab) lists Shopify B2B with “Up to 3 catalogs” on Basic, Grow, and Advanced, and “Unlimited B2B catalogs” on Plus, which is listed “from $2,300/mo.” Shopify’s pricing changes, so check the page. Shopify’s B2B developer docs (opens in new tab) note that “B2B doesn’t support purchase options, such as subscriptions, pre-orders, and try before you buy.”

Checkout customization on Shopify uses extensions and Functions, not template edits. Shopify’s checkout UI extensions reference (opens in new tab) says “Checkout UI extensions for the information, shipping, and payment steps are available only to stores on a Shopify Plus plan.” Shopify Functions work on every plan except Shopify Starter, per its checkout technologies page (opens in new tab), though only Plus stores can run custom apps that contain Shopify Function APIs, per Shopify’s Functions docs (opens in new tab), and “checkout.liquid is now unsupported for the Information, Shipping, and Payment checkout steps,” per its checkout docs (opens in new tab). If your Magento checkout is heavily customized, that’s the main point for evaluating Plus, and our Shopify Plus agency page covers how we assess plan fit.

For Magento stores running several websites or store views, Shopify’s pricing page lists localized selling with Shopify Markets, with local currencies and local payment methods requiring Shopify Payments. We didn’t find Shopify documentation of a one-to-one match for Magento’s website, store, and store view structure, so plan to map it rather than copy it.

On compliance, Shopify says on its PCI page (opens in new tab) that “Shopify is certified Level 1 PCI DSS compliant. This compliance extends by default to all stores powered by Shopify.” That’s Shopify describing its own platform. Adobe’s statement that PCI compliance is the merchant’s responsibility to assess reflects a different platform model.

How long does a Magento to Shopify migration take? We didn’t find a neutral source that publishes a reliable figure, and the work depends on catalog structure, customer count, redirect volume, and integrations. Adobe’s calendar sets the latest possible finish date. A Cloud store on 2.4.4 or 2.4.5 has to cut over before June 1, 2027 or upgrade on Cloud to stay online, and its dependency upgrades come due first.

For a Cloud store on 2.4.4 or 2.4.5, the first date is October 30, 2026, when the per-version table on the Required actions page lists dependency upgrades as due. Some items in its dependency table carry May 31, 2027 instead. The second is June 1, 2027, the version deadline.

Whichever path you choose, the current store has to stay compliant until cutover. If your Shopify store won’t launch before October 30, 2026, the dependency upgrades still apply to the Magento store until cutover.

For a Cloud store on 2.4.6 or 2.4.7, enforcement comes on June 1, 2028. Adobe asks you to move before extended support ends, which is August 2027 for 2.4.6 and May 31, 2028 for 2.4.7, and a 2.4.6 store’s PHP 8.2 reaches end of life on December 31, 2026. For a self-hosted Adobe Commerce store, nothing gets switched off, but Adobe’s FAQ ties PCI compliance and ticket support to being on a supported version. For Open Source, plan around your line’s end of standard support, because Adobe documents no extended patches for it.

Our recommendation depends on where your Magento budget goes. If most of it keeps the platform current (release upgrades, PHP moves, dependency changes like the October 30 list) rather than building things your customers see, replatforming to Shopify takes you off that cycle, and that’s what we’d recommend. Adobe makes the same claim for Adobe Commerce as a Cloud Service, so price both.

If your business logic lives in custom Magento modules that Shopify’s three-option limit, B2B restrictions, or Plus-only checkout steps can’t hold, price the upgrade to 2.4.9 against a rebuild. Adobe Commerce as a Cloud Service is the option for Cloud customers who want to stay with Adobe and are prepared to migrate within Adobe to do it.

If Shopify is on your shortlist, start by planning a Magento to Shopify migration with us. The free audit gives you a scoped estimate before you commit to anything, and every migration we run includes the Shopify build.