Magento Migration and Upgrade Guide (2027): Moving to 2.4.9

Ishant
Published on October 30, 2026
Ishant
Ishant Sharma is the Founder and CEO of Hustle Marketers, a Google Partner digital marketing agency. Working in Google Ads, Meta Ads, SEO and ecommerce PPC since 2013, he has helped 2,500+ brands generate $780M+ in trackable sales. Upwork Top Rated Plus with 100% Job Success Score. Ishant Sharma is the digital marketing specialist, not the Indian cricketer of the same name.

By Ishant Sharma, Google Ads, Microsoft Ads and SEO specialist at Hustle Marketers, working in digital marketing since 2013. Published March 9, 2026.
Magento migration usually means one of three moves: upgrading Magento 2 to a newer 2.4 release, moving a Magento 1 store to Magento 2, or leaving Magento for another platform. In October 2026, most stores should target Magento 2.4.9, the latest Magento 2 version, released May 12, 2026, which Adobe supports until May 31, 2029.
This guide covers which version to target, Adobe’s support dates, what 2.4.9 needs from your servers, the upgrade steps, Magento 1 migration and the SEO checks that keep rankings intact. We checked the dates and requirements in this guide against Adobe’s Experience League pages and security bulletins in October 2026. Sources are also linked next to the claims they support.
Summarize this article with:
Key Observations
- Magento 2.4.9 is the latest general release. Adobe’s released versions page lists only a 2.4.10-alpha1 build after it, added on October 13, 2026.
- Adobe’s requirements for 2.4.10-alpha match 2.4.9 except Varnish 9 and a few point releases, so the 2.4.9 stack carries over.
- Regular support for 2.4.6 ended on August 11, 2026. Adobe Commerce customers get extended support until August 31, 2027, but Adobe’s September 8, 2026 bulletin says Open Source merchants can only download patches for 2.4.7 or later.
- On September 7, 2026, Adobe published an urgent bulletin, APSB26-146, for a vulnerability exploited in the wild. It lists Adobe Commerce 2.4.4 to 2.4.9 and Magento Open Source 2.4.6 to 2.4.9 as affected. Patching cannot wait for the next upgrade.
- Adobe’s newest Commerce bulletin, when we checked on October 28, 2026, was APSB26-153. So apply its monthly patch files in order, then run php vendor/bin/patch-status.
- Magento 2.4.9 needs PHP 8.5 in production. Adobe allows PHP 8.4 only for the upgrade itself and dropped PHP 8.2 and 8.3.
- PHP 8.2 loses security support on December 31, 2026, and PHP 8.3 a year later. So every 2.4.7 store loses PHP fixes before Adobe Commerce extended support for 2.4.7 ends.
- 2.4.9 also moves the stack to OpenSearch 3, MariaDB 12.3 or MySQL 8.4, Valkey 9 and Composer 2.10, so for most stores the work sits in hosting and extensions rather than in Magento’s own code.
- Adobe’s Upgrade Compatibility Tool, however, is for Adobe Commerce only. Open Source stores need another way to check custom code.
- A version upgrade does not change your URLs on its own. The SEO risk comes from theme changes, staging settings reaching production, broken URL rewrites and slower pages, so crawl the store before and after.
What is the latest Magento version?
The latest Magento version is 2.4.9, released on May 12, 2026 for both Magento Open Source and Adobe Commerce. Adobe’s released versions page gives it regular support until May 31, 2029, and lists no later general release, only a 2.4.10-alpha1 build dated October 13, 2026.
Updates to 2.4.9 also look different. Older lines still have numbered patch releases such as 2.4.8-p5, while 2.4.9 has none on the released versions page. Adobe’s September 2026 security bulletin labels every line by month instead, such as 2.4.9-2026-aug, and ships monthly isolated patch files such as 2-4-9-sep-2026.zip. Check the bulletin for your exact version rather than relying on the patch number alone.
Is Magento 2 still relevant?
Yes. Adobe released 2.4.9 in May 2026 with three years of regular support and ships security fixes for every supported line. Its release schedule plans a full patch for each supported 2.4.x line every May. Whether Magento still suits your business is a separate question, covered in the platform section below.
What do we know about Magento 2.4.10?
So far, its first test build, its requirements and Adobe’s alpha release notes. Adobe’s released versions page added 2.4.10-alpha1 on October 13, 2026 and says the date when support for the 2.4.10 line ends has not been set. Adobe has not published a general availability date.
Adobe’s release schedule describes the pattern: one alpha and one beta for the 2.4.x line each year, and a full patch release every May. The system requirements page, updated October 13, 2026, already lists 2.4.10-alpha next to 2.4.9, and the two stacks are close:
| Component (on-premises) | 2.4.9 | 2.4.10-alpha | What changes |
|---|---|---|---|
| PHP | 8.5 | 8.5 | Nothing |
| Composer | 2.10 | 2.10.2 or later | Point release |
| OpenSearch | 3 | 3.7 or later | Higher minimum within version 3 |
| MariaDB | 12.3 | 12.3 | Nothing |
| MySQL | 8.4 | 8.4 | Nothing |
| Valkey | 9 | 9.0 | Nothing |
| RabbitMQ | 4.3 | 4.3 | Nothing |
| Varnish | 8 | 9 | New major version |
| nginx | 1.30 | 1.30.2 | Point release |
Our reading: the big stack jump happens on the way to 2.4.9, not after it. A store that reaches 2.4.9 on PHP 8.5, OpenSearch 3 and Valkey 9 should face a much smaller project for 2.4.10, mainly Varnish 9 and extension updates. An alpha is a pre-release build, so use it on a test copy to check extensions and keep production on 2.4.9 until Adobe ships a general release.
What is in the Magento 2.4.10-alpha1 release notes?
Adobe’s 2.4.10-alpha1 release notes, dated October 13, 2026, describe a maintenance release rather than a new stack. Overall, Adobe says the alpha fixes 169 issues in Adobe Commerce and 152 in Magento Open Source. Besides those fixes, the notes list these changes:
- Payments: Fastlane by PayPal for faster guest checkout and Braintree Insights reports in the Admin, both through the Braintree extension.
- Admin: merchants can add, edit or deactivate states and provinces without code changes.
- Libraries: predis moves to 3.x, Knockout.js to 3.5.3 and Less.js to 4.6.4, plus a PHP 8.5 fix for chr().
- Caching: Varnish 9 support, which is also the main change in the requirements table above.
So for most stores, 2.4.10 looks like an extension and caching update on top of the 2.4.9 stack. That said, an alpha can change before general availability, so treat this list as a preview, not a plan.
How do you check which Magento version you are running?
Run bin/magento --version from the Magento root folder. It returns the installed version, such as Magento CLI version 2.4.0 in Adobe’s example. Then compare it with the latest release, 2.4.9. Adobe’s developer guide, Check the Commerce version, also lists three other ways, compared below.
bin/magento --version| Method | How to use it | What it shows |
|---|---|---|
| Command line | Run bin/magento --version from the Magento root | The installed version, so you can match it to Adobe’s release list |
| Admin panel | Sign in, then look at the bottom right of any Admin page | The version, shown above the Account Activity and Report an Issue links |
| composer.lock | Search for magento/product-community-edition or magento/product-enterprise-edition | The installed version as well as the edition |
| Browser | Add /magento_version to your store URL | Less detail, such as Magento/2.3 (Community) in Adobe’s example |
So the command line and composer.lock are the reliable checks, while the browser URL is only a quick hint. To see which newer versions Composer can install, Adobe’s upgrade guide gives this command for Magento Open Source:
composer show magento/product-community-edition 2.4.* --available | grep -m 1 versionsAdobe Commerce stores, however, use magento/product-enterprise-edition in the same command. We also checked both commands against Adobe’s guides on October 28, 2026.
How do you read a Magento version number?
Read it from left to right. The first three numbers name the release line. A -p suffix marks a security patch release, and Adobe’s 2026 bulletins also add a month label for monthly patch files. For example, 2.4.8-p5 and 2.4.9-2026-oct are both current, but they describe different things.
- 2.4.9 is a release line, so it has its own three-year support window.
- 2.4.8-p5 is a security patch release, and it is also the base that monthly patch files for 2.4.8 need.
- 2.4.9-2026-oct is a monthly patch level, so it means 2.4.9 plus the October 2026 isolated patch.
- 2.4.10-alpha1 is a pre-release, so use it on a test copy only.
Which Magento versions are still supported?
Magento 2.4.7, 2.4.8 and 2.4.9 still have regular support. 2.4.6 left regular support on August 11, 2026, and 2.4.4 and 2.4.5 are past both regular and extended support. Adobe Commerce customers on 2.4.4, 2.4.5 and 2.4.6 also get a one-time security-only period with isolated security fixes. Magento Open Source stores on 2.4.6 or older no longer get Adobe’s regular patch downloads.
The table combines Adobe’s released versions page and lifecycle policy, both checked again on October 28, 2026.
| Version | Released | Regular support ends | Extended support ends (Adobe Commerce only) | Security-only fixes end (Adobe Commerce only) | Status on October 28, 2026 |
|---|---|---|---|---|---|
| 2.4.9 | May 12, 2026 | May 31, 2029 | Not set yet | N/A | Latest release |
| 2.4.8 | April 8, 2025 | May 31, 2028 | Not set yet | N/A | Supported |
| 2.4.7 | April 9, 2024 | May 31, 2027 | May 31, 2028 | N/A | Supported |
| 2.4.6 | March 14, 2023 | August 11, 2026 | August 31, 2027 | May 31, 2028 | Extended support (Adobe Commerce only) |
| 2.4.5 | August 9, 2022 | August 12, 2025 | August 11, 2026 | May 31, 2027 | Security-only fixes for Adobe Commerce; out of support for Open Source |
| 2.4.4 | April 12, 2022 | April 12, 2025 | April 14, 2026 | May 31, 2027 | Security-only fixes for Adobe Commerce; out of support for Open Source |

Does Magento Open Source get the same support as Adobe Commerce?
Not after regular support ends. The security patch overview says extended support patches are for Adobe Commerce and are not available for the Magento Open Source code base. The lifecycle policy, including its security-only period, covers Adobe Commerce only, even though many guides apply its dates to both editions.
Indeed, the download rules confirm the gap. At first, the July and August 2026 bulletins said Open Source customers could download patches for 2.4.6 or later. The September 8, 2026 bulletin (APSB26-138) then moved that to 2.4.7 or later. An Open Source store on 2.4.6 can no longer download the regular monthly patches, although the urgent APSB26-146 bulletin of September 7, 2026 still listed Open Source 2.4.6 among affected versions.
In addition, Adobe Commerce on cloud has more deadlines. The security enforcement policy requires every cloud project on 2.4.4 through 2.4.9 to update third-party services. The first deadline is October 30, 2026, when any Elasticsearch must have moved to OpenSearch, and the next is May 31, 2027.
Cloud projects on 2.4.4 or 2.4.5 must also upgrade Magento by June 1, 2027, and projects on 2.4.6 or 2.4.7 by June 1, 2028. Adobe warns that otherwise your Commerce storefront will go offline. However, the policy covers Adobe Commerce on cloud only, not on-premises or Open Source stores. Our Adobe Commerce SEO guide covers Fastly and the other Adobe Commerce settings that affect search.
What happened to Magento 1?
Adobe released the final security patches for Magento 1 in June 2020, and its bulletin APSB20-41 says support for Magento Commerce 1.14 and Magento Open Source 1 ended that month. A Magento 1 store in 2026 has gone more than six years without official patches. So the Magento 1 section below covers the way out.
What is the Magento 2 version history?
Adobe’s released versions page lists every Magento 2 release since 2.0.0 arrived on November 17, 2015. Every line before 2.4.4 is out of support. Meanwhile, 2.4.4 to 2.4.6 get fixes for Adobe Commerce only, while 2.4.7 to 2.4.9 keep regular support. The table shows when each line first shipped, its latest release and when regular support ends or ended.
| Release line | First release, then latest release | Regular support |
|---|---|---|
| 2.4.10 | October 13, 2026 (2.4.10-alpha1 only) | End date not set yet |
| 2.4.9 | May 12, 2026, then monthly patches up to 2.4.9-2026-oct | Ends May 31, 2029 |
| 2.4.8 | April 8, 2025, then 2.4.8-p5 on May 12, 2026 | Ends May 31, 2028 |
| 2.4.7 | April 9, 2024, then 2.4.7-p10 on May 12, 2026 | Ends May 31, 2027 |
| 2.4.6 | March 14, 2023, then 2.4.6-p15 on May 12, 2026 | Ended August 11, 2026 |
| 2.4.5 | August 9, 2022, then 2.4.5-p17 on May 12, 2026 | Ended August 12, 2025 |
| 2.4.4 | April 12, 2022, then 2.4.4-p18 on May 12, 2026 | Ended April 12, 2025 |
| 2.4.0 to 2.4.3 | July 28, 2020, then 2.4.3-p3 on August 9, 2022 | Ended November 28, 2022 |
| 2.3 | November 28, 2018, then 2.3.7-p4 on August 9, 2022 | Ended September 8, 2022 |
| 2.2 | September 26, 2017, then 2.2.11 on January 28, 2020 | Ended December 1, 2019 |
| 2.1 | June 23, 2016, then 2.1.18 on June 25, 2019 | Ended June 30, 2019 |
| 2.0 | November 17, 2015, then 2.0.18 on February 27, 2018 | Ended March 31, 2018 |
Why does the history stop at the -p releases?
These dates come from Adobe’s released versions page, which we checked on October 28, 2026. However, that page lists only full and -p releases. So the newest code for a line is its latest release plus each monthly patch file since then. For 2.4.9, that means 2.4.9-2026-oct from the October 13, 2026 bulletin.
Which Magento deadlines fall in 2027?
Seven deadlines land in 2027. Regular support for 2.4.7 ends on May 31, 2027, Adobe Commerce on cloud projects on 2.4.4 or 2.4.5 must upgrade by June 1, 2027, and Google switches off the Content API for Shopping in early 2027, which breaks any Magento feed extension still using it.
| Date | What happens | Who it affects |
|---|---|---|
| Early 2027 | Google turns off every Content API for Shopping endpoint, and extensions to it do not run past the shutdown | Any Magento store whose feed extension still uses the Content API |
| May 31, 2027 | Regular support for 2.4.7 ends | Every 2.4.7 store. Adobe Commerce extended support runs to May 31, 2028 |
| May 31, 2027 | Security-only fixes for 2.4.4 and 2.4.5 end | Adobe Commerce stores on 2.4.4 or 2.4.5 |
| May 31, 2027 | Cloud dependency deadline: PHP 8.1 and older to 8.2 or higher, MariaDB below 10.11 to 10.11 or higher, Redis 5 and older to Valkey 8 or higher, RabbitMQ below 3.13 to 4.3 or higher, and OpenSearch 1.x to the version your release needs | Adobe Commerce on cloud, versions 2.4.4 to 2.4.9 |
| June 1, 2027 | Cloud projects on 2.4.4 or 2.4.5 must move to 2.4.9 or later, or to Adobe Commerce as a Cloud Service, and Adobe stops maintaining Cloud environments on unsupported versions | Adobe Commerce on cloud |
| August 31, 2027 | Extended support for 2.4.6 ends | Adobe Commerce stores on 2.4.6 |
| December 31, 2027 | PHP 8.3 security support ends, according to php.net | Every 2.4.7 store, since its newest supported PHP is 8.3, and 2.4.8 stores still on PHP 8.3 |
Where do these 2027 deadline dates come from?
Adobe dates are from its lifecycle policy and security enforcement policy, both checked October 28, 2026.
The PHP date comes from php.net’s supported versions page. Similarly, the Google date comes from Google’s Content API sunset guide, checked the same day. For the non-Magento side of the Google change, see our Content API for Shopping shutdown checklist. Adobe says a non-compliant cloud environment can lose admin access or inbound traffic, and in the end be decommissioned with its data deleted.
The Google date is the one most upgrade plans miss, because it has nothing to do with your Magento version. So check the feed extension in the same sprint as the upgrade: our Magento product feed guide shows how to tell whether it uses the old API in about a minute. If the move also changes templates or URLs, run the checks in our Magento 2 SEO checklist, and if speed drops after the stack change, our Magento speed optimization guide covers the caching side.
What changed in Magento 2.4.8 and 2.4.9?
Magento 2.4.8, released April 8, 2025, added PHP 8.4, MySQL 8.4 and OpenSearch 2.19 support and made Update by Schedule the default indexer mode on new installs. Magento 2.4.9, released May 12, 2026, moved production to PHP 8.5, OpenSearch 3 and Valkey 9 and replaced several framework parts that extensions depend on.
The table summarizes the release notes for 2.4.8 and 2.4.9. The editor row also uses the 2.4.8 patch notes, and the sitemap row comes from the site map page.
| Area | 2.4.8 (April 2025) | 2.4.9 (May 2026) |
|---|---|---|
| PHP | Adds PHP 8.4, keeps 8.3, removes 8.1 | PHP 8.5 for production; 8.4 allowed for the upgrade only; 8.2 and 8.3 dropped |
| Search | Optimized for OpenSearch 2.19; Elasticsearch 7 and 8 labeled deprecated | Fully compatible with OpenSearch 3; Elasticsearch is not listed in the requirements |
| Database | MySQL 8.4 LTS and MariaDB 11.4 LTS | MySQL 8.4 or MariaDB 12.3 |
| Cache | Valkey 8 support added | Valkey 9; the deprecated Zend_Cache replaced by Symfony Cache |
| Framework | Breaking changes needed for PHP 8.4 compatibility | Native MVC replaces Laminas MVC; Symfony dependencies move to 7.4 LTS |
| Content editor | TinyMCE at release; HugeRTE from 2.4.8-p3 (October 2025) | HugeRTE |
| Indexing | Update by Schedule is the default mode for new installs | Not mentioned in the release notes |
| Sitemaps | Standard generation | New memory-optimized Batch generation method for large catalogs |
| APIs and security | Support for RabbitMQ 4.x | CAPTCHA on account creation now also applies to REST and GraphQL; admins configure only one 2FA provider |
| Fixes | 581 issues fixed in Adobe Commerce, 497 in Open Source | 666 issues fixed in Adobe Commerce, 580 in Open Source |
Which 2.4.8 and 2.4.9 changes reach your storefront?
Two of these changes reach your storefront directly. Content written in the old editor should be spot-checked after the HugeRTE switch, so headings and links in category descriptions survive. And if your indexers run on Update by Schedule, the default for new 2.4.8 installs, prices, stock and category changes reach the storefront only when cron runs.
Upgrading does not switch existing indexers, so check the mode in Index Management after the move. For the SEO side of each setting, see also our Magento SEO guide.
Which Magento version should you upgrade to?
Target 2.4.9 if you are on 2.4.7 or older, because it carries the longest support window and you move the stack once. If you are on 2.4.8, you can stay patched until May 31, 2028 and move to 2.4.9 when your extensions and theme support PHP 8.5. Anything on 2.4.6 or older should upgrade now.
Which upgrade target fits the version you run now?
So use the row that matches your store. Stack changes come from Adobe’s system requirements page, rechecked October 28, 2026.
| You are on | Support position | Recommended target | Main stack changes to reach 2.4.9 |
|---|---|---|---|
| 2.4.8 | Regular support to May 31, 2028 | 2.4.9 once extensions confirm PHP 8.5, otherwise the latest 2.4.8 patch | PHP 8.4 to 8.5, MariaDB to 12.3 (or MySQL 8.4), Valkey 8.1 to 9 |
| 2.4.7 | Regular support to May 31, 2027; Adobe Commerce extended to May 31, 2028 | 2.4.9, planned for 2026 to early 2027 | PHP 8.2 or 8.3 to 8.5, MariaDB 10.11 or 11.8 to 12.3 or MySQL 8.4, Elasticsearch or OpenSearch 2 to OpenSearch 3, Valkey 9 |
| 2.4.6 | Regular support ended August 11, 2026; Adobe Commerce extended to August 31, 2027; no regular Open Source patch downloads since September 8, 2026 | 2.4.9, now | PHP 8.1 or 8.2 to 8.5, MariaDB 10.11 to 12.3 or MySQL 8.4, OpenSearch 3, Composer 2.2 to 2.10 |
| 2.4.4 or 2.4.5 | Regular and extended support ended; Adobe Commerce security-only fixes until May 31, 2027 | 2.4.9, now; cloud projects must move by June 1, 2027 | Every service in the stack, plus code compatibility work |
| 2.3.x or 2.4.0 to 2.4.3 | Long out of support | 2.4.9, scoped as a project rather than a routine update | Every service, custom modules and usually the theme |
| Magento 1 | Support ended June 2020 | Rebuild on 2.4.9 or move platform | New platform; data moves, code and theme do not |
Adobe’s upgrade best practices note that skipping releases makes the next upgrade more complex, while upgrading from consecutive versions makes it easier and cheaper. That is the case for regular, smaller upgrades. It does not mean you have to install every version in between: Composer targets one version, but every service in your stack must meet that version’s requirements first.
Should you upgrade to 2.4.8 or 2.4.9?
Choose 2.4.9 unless something in your stack cannot run PHP 8.5 yet. For example, a payment module, ERP connector or theme that has not confirmed PHP 8.5 is the usual blocker. In that case the latest 2.4.8 patch is a reasonable stopgap, with the move to 2.4.9 planned before 2.4.8 support ends.
If you are planning an upgrade, our Magento SEO consultant service sets the SEO requirements your developers test against before launch.
Should you upgrade on release day or wait for the first patch?
For a live store, wait for at least one round of patches and for your extension vendors to confirm support. Indeed, Adobe’s release history shows the first -p release of recent 2.4 lines arriving 63 to 119 days after launch. So upgrading on day one makes sense mainly for a new build or a test copy.
| Release line | General availability | First patch release | Days later |
|---|---|---|---|
| 2.4.4 | April 12, 2022 | 2.4.4-p1, August 9, 2022 | 119 |
| 2.4.5 | August 9, 2022 | 2.4.5-p1, October 11, 2022 | 63 |
| 2.4.6 | March 14, 2023 | 2.4.6-p1, June 13, 2023 | 91 |
| 2.4.7 | April 9, 2024 | 2.4.7-p1, June 11, 2024 | 63 |
| 2.4.8 | April 8, 2025 | 2.4.8-p1, June 10, 2025 | 63 |
| 2.4.9 | May 12, 2026 | No 2.4.9-p1 yet, monthly patch files instead | Not applicable |
Specifically, we counted the days from Adobe’s released versions page, checked October 28, 2026. 2.4.9 broke the pattern, because Adobe has shipped monthly isolated patch files such as 2.4.9-2026-oct instead of a -p1 release. For 2.4.9, then, waiting for the first patch really means waiting until the monthly patches and your extensions have settled.
When does upgrading early make sense?
Our working rule depends on what the store runs and how exposed it is today:
- Upgrade early if the store is new, the extension list is short and every vendor already supports PHP 8.5.
- Wait for patches if your payment, ERP or search extensions have not yet declared support for the new line.
- Do not wait if your line is out of support or an urgent bulletin such as APSB26-146 applies. In that case, patch first and then plan the move.
What does Magento 2.4.9 require?
Magento 2.4.9 needs PHP 8.5, OpenSearch 3, MariaDB 12.3 or MySQL 8.4, Valkey 9, Composer 2.10 and RabbitMQ 4.3. PHP 8.4 is allowed only while you run the upgrade. Most hosts that supported 2.4.7 need several services upgraded first, which is why the hosting plan usually decides the timeline.
Figures below are from Adobe’s system requirements page for on-premises installs, updated October 13, 2026 and checked October 28, 2026.
| Component | 2.4.9 | 2.4.8-p5 | 2.4.7-p10 |
|---|---|---|---|
| PHP | 8.5 | 8.4, 8.3 | 8.3, 8.2 |
| Composer | 2.10 | 2.10 | 2.10 |
| OpenSearch | 3 | 3 | 2.19, 3 |
| Elasticsearch | Not listed | 8 | 8 |
| MariaDB | 12.3 | 11.4, 11.8 | 10.11, 11.8 |
| MySQL | 8.4 | 8.4 | Not supported |
| Valkey | 9 | 8.1 | 8.1 |
| RabbitMQ | 4.3 | 4.3 | 4.3 |
| Varnish | 8 | 8 | 8 |
| nginx | 1.30 | 1.30 | 1.30 |
The same page also carries two notices worth acting on: MySQL 8.0 reached end of support on April 30, 2026, and Elasticsearch 7.17 on January 15, 2026. A store still on either is running unsupported software even if its Magento version is current. Then, for caching and server tuning once the new stack is in place, see our Magento speed optimization guide. Adobe’s 2.4.9 release notes give slightly different RabbitMQ and MariaDB versions, so we used the newer requirements table.
When does your PHP version stop getting security fixes?
PHP has its own end-of-life dates, and they can arrive before Adobe’s. According to php.net (checked October 28, 2026), PHP 8.2 gets security fixes until December 31, 2026. PHP 8.3 follows on December 31, 2027. In addition, Adobe’s lifecycle policy flags running PHP past its end of life as a PCI compliance risk.
| PHP version | Security support ends | Magento lines that run it (latest patches) |
|---|---|---|
| 8.1 | December 31, 2025 (already ended) | 2.4.4, 2.4.5 and 2.4.6 |
| 8.2 | December 31, 2026 | 2.4.6 and 2.4.7 |
| 8.3 | December 31, 2027 | 2.4.7 and 2.4.8 |
| 8.4 | December 31, 2028 | 2.4.8, while 2.4.9 allows it only for the upgrade |
| 8.5 | December 31, 2029 | 2.4.9 and 2.4.10-alpha |
As a result, a 2.4.7 store on PHP 8.3 loses PHP security fixes at the end of 2027. That is five months before Adobe Commerce extended support for 2.4.7 ends on May 31, 2028. For Adobe Commerce stores counting on extended support, then, the PHP date sets the real deadline. Meanwhile, the PHP versions per line come from Adobe’s system requirements page for on-premises installs.
How do you upgrade Magento 2 to the latest version?
Upgrade on a staging copy of the live store first. Bring PHP, the database, OpenSearch and Valkey up to 2.4.9’s requirements, check every extension and custom module, then run Adobe’s Composer upgrade, setup:upgrade and a full regression test. Only then repeat the same steps on production, during a quiet trading window.
Adobe’s upgrade prerequisites come first. Convert any COMPACT tables to DYNAMIC and MyISAM tables to InnoDB, and set the open files limit to at least 65536. Also confirm cron is running and install the magento/composer-root-update-plugin. Then follow its perform an upgrade sequence:
- To begin, put the store into maintenance mode.
- Stop cron, then let the message queue consumers finish.
- Then back up composer.json.
- Require the target version with composer require-commerce, without updating yet.
- After that, run composer update.
- Then clear var/cache, var/page_cache and generated/code.
- Run setup:upgrade, then take the store out of maintenance mode and restart Varnish if you use it.
For a Magento Open Source store moving to 2.4.9, the core commands look like this:
bin/magento maintenance:enable
bin/magento cron:remove
bin/magento cron:run --group=consumers
cp composer.json composer.json.bak
composer require-commerce magento/product-community-edition 2.4.9 --no-update
composer update
rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento setup:upgrade
bin/magento maintenance:disableAdobe Commerce uses magento/product-enterprise-edition instead, and cloud projects disable cron with ece-tools. Adobe’s documentation also adds two warnings. The built-in backup feature is deprecated, so take database and file backups with your host’s tools. And the Upgrade Compatibility Tool, which checks custom code against a target version, works on Adobe Commerce only.
What breaks most often when upgrading to 2.4.9?
Usually extensions, custom modules and PHP 8.5 behavior rather than Magento’s core. Adobe says the number of third-party modules and the amount of custom work strongly affect upgrade complexity. Reports on Magento’s GitHub tracker from the 2.4.8 and 2.4.9 cycles show where to test:
- PHP 8.5 deprecations in core code. Issues filed on 2.4.9 with PHP 8.5 report deprecation notices in downloadable product orders, PDF printing and currency formatting. On stores that turn deprecations into exceptions, the first two break order placement and PDF printing.
- Product 404s. Issue #40891 reports product pages returning 404 on 2.4.9 and PHP 8.5 when opened without category context, for example from a homepage widget, site search results or a CMS block. A visitor arriving straight from Google has no category context either, so test direct product URLs.
- Extensions that block Composer. On 2.4.8, a payment module released the same day conflicted on a dependency and had to be removed to finish the upgrade. Snowdog’s menu module, for instance, still had an open request for 2.4.9 and PHP 8.5 compatibility with no release date when we checked.
- Framework changes. Custom code that uses Zend_Cache or Laminas MVC, or extends Symfony classes, needs changes, because 2.4.9 replaced the first two and moved Symfony to 7.4 LTS. TinyMCE plugins need rework too, unless the store already moved to HugeRTE in 2.4.7-p8 or 2.4.8-p3.
- Database steps. Even a patch-to-patch move can fail at setup:upgrade, as in a foreign key error reported on 2.4.8-p5. Test with a copy of the production database, not an empty one.
- Search cutover. When the search engine is unavailable, category pages can render empty and the full page cache can store them, as issue #38284 describes. Flush the cache after switching to OpenSearch and check category pages before reopening the store.
Do Hyvä stores need anything extra?
Yes: confirm PHP 8.5 support before you switch. The Hyvä theme has been free since November 10, 2025, according to Hyvä’s announcement.
But its requirements page still listed PHP 8.1 to 8.4 on October 28, 2026, with no mention of 2.4.9. The same page says Hyvä products will be built for PHP 8.2 and newer from 2027. They will also stop supporting Magento 2.4.4 and 2.4.5 then. Hyvä’s paid Commerce package does say its 1.2.1 release is “primarily to support PHP 8.5 and Magento 2.4.9.” Ask Hyvä or your developer for written confirmation for your theme version and every compatibility module.
How do you test extensions and themes before a Magento upgrade?
Start with a full list of what the store runs. Then confirm that each item supports the target version and its PHP release before you touch production. On a staging copy, this command lists every enabled module, while composer.json shows the vendor packages behind them:
bin/magento module:status --enabledThen work through each extension and the theme with this checklist:
| Check | What to confirm |
|---|---|
| Vendor support | A release that declares 2.4.9 and PHP 8.5, for example in its composer.json or changelog |
| Full install on staging | Composer resolves every extension together, because conflicts often appear only then |
| Custom code | Code that avoids Zend_Cache and Laminas MVC, since 2.4.9 replaced both |
| Theme | Release notes for PHP 8.5 and 2.4.9, as well as a visual check of checkout and account pages |
| Integrations | Payment, ERP, PIM, search and feed modules, tested end to end because they touch orders |
| Admin content | Category and CMS text from the old editor, since the HugeRTE switch can change headings and links |
For Adobe Commerce, the Upgrade Compatibility Tool also scans custom code against the target version. Magento Open Source stores need a developer review instead, so budget time for it. In addition, our Magento marketing extensions guide shows which Magento and PHP versions marketing extensions should support. Our SEO extensions for Magento 2 guide also covers the SEO side.
What is your rollback plan if a Magento upgrade fails?
A rollback plan is the backups and steps that restore the old version if the upgrade fails on launch day. Before you start, take a database dump plus a copy of the code and media with your host’s tools. Also make sure the code copy includes composer.json, composer.lock and the vendor folder from the working version.
Do not rely on Magento’s own setup:backup and setup:rollback commands. Adobe deprecated that backup feature in 2.3.0 and suggests binary backup tools instead. Restore the database as well as the code, since setup:upgrade changes the database schema. Otherwise the code and database end up out of step.
How do you roll back a failed Magento upgrade?
- First of all, put the store back into maintenance mode.
- Restore the code backup, including the saved composer.json, composer.lock and vendor folder from the working version.
- Restore the database dump you took just before the upgrade.
- Clear var/cache, var/page_cache and generated/code, as in the upgrade steps.
- Finally, run your usual deployment steps, end maintenance mode and test checkout, search and product URLs.
bin/magento maintenance:enable
rm -rf var/cache/* var/page_cache/* generated/code/*
bin/magento maintenance:disableAbove all, agree before launch day who makes the rollback call. Also set how long the team may try a fix first. For example, a team might allow 60 minutes after setup:upgrade to fix a checkout error before it restores. That number is only an illustration, so set your own limit from how long a restore takes on staging.
How long does a Magento upgrade take, and what does it cost?
A minor 2.4.x upgrade on a store with few extensions can take days, while a heavily customized store can take weeks. In the agency price lists below, minor upgrades run from under $1,000 (AgentoSupport) to $35,000 (IWD Agency). Magento 1 migrations run from about $50,000 to over $500,000 (Elogic). In short, extension count, custom code and theme work decide where your store lands.
Also note that these are figures agencies publish on their own sites, linked in each row. They are not survey data, though:
| Source | Type of work | Published figure |
|---|---|---|
| AgentoSupport | Basic 2.4.x upgrade | $800 to $1,500 |
| scandiweb | Minor 2.4.x version jump | $3K to $8K, 2 to 4 weeks |
| IWD Agency | Magento 2.x to 2.y | $8,000 to $35,000 |
| IWD Agency | Luma to Hyvä theme | $35,000 to $80,000 |
| IWD Agency | Magento 1 to Magento Open Source 2 | $75,000 to $200,000, 10 to 18 weeks |
| Elogic | Magento 1 to Magento 2 | About $50,000 to $500,000+, typically 4 to 12 months |
When you compare quotes, ask each developer what is included. The numbers above differ mostly because of scope:
- How many third-party extensions and custom modules the store runs, and whether each vendor supports the target version.
- How far the stack has to move: PHP, database, search engine, cache and hosting.
- Whether the theme is Luma, Hyvä or heavily custom.
- Integrations such as ERP, PIM, payments and shipping.
- Store views, languages and B2B features.
- Whether testing, a staging environment and post-launch fixes are included.
Timing matters as much as budget. In the fourth quarter, a code freeze before Black Friday may make a January upgrade safer than a rushed November one. However, urgent security bulletins are the exception.
How do you migrate from Magento 1 to Magento 2?
A Magento 1 to Magento 2 migration is a rebuild, not an upgrade. Adobe’s Data Migration Tool moves settings, products, customers and orders, but themes, extensions and custom code have to be rebuilt or replaced for Magento 2. In 2027 the target should be 2.4.9, and every URL that changes needs a 301 redirect.
Adobe’s page on how data migration works describes three modes, run in order:
- Settings: system configuration and website-related settings.
- Data: database records in bulk, such as products, categories, customers and orders.
- Delta: changes made in Magento 1 since the last run, such as new orders, so the old store can keep trading until launch.
The tool supports Magento Open Source 1.6.x to 1.9.x and Magento Commerce 1.11.x to 1.14.x as sources, according to its GitHub README. Its install guide says the Data Migration Tool and Magento 2 versions must match exactly, so confirm a release exists for the version you are targeting before you plan the project around it.
URLs are where most Magento 1 migrations lose traffic. Category and product paths often change, and Adobe’s troubleshooting guide covers duplicate URL rewrites created during migration with an auto_resolve_urlrewrite_duplicates option that adds a hash string to the conflicting URLs. Crawl the Magento 1 store before you start, so every old URL has a mapped destination, and read our Magento SEO guide for the settings to apply on the new store.
How do you protect SEO during a Magento upgrade or migration?
Record how the store looks to search engines before the move, then compare the same things on staging and again after launch. Check status codes, canonical tags, robots tags, hreflang, structured data, sitemaps and page speed. For migrations that change URLs, map every old URL to its new equivalent with a 301 and keep those redirects for at least a year.
Will upgrading Magento affect your SEO rankings?
Not by itself. A version upgrade keeps your URLs and content, so rankings usually hold if nothing else changes. Drops after an upgrade come from side effects. The usual ones are a staging robots setting copied to production, SEO output lost with a theme or extension, broken URL rewrites, empty category pages during the search cutover, or slower templates.
Run this checklist around every upgrade:
| When | Check | Why |
|---|---|---|
| Before | Crawl the live store and export URLs, status codes, titles, canonicals, robots tags, hreflang and structured data | Gives you a baseline to compare against |
| Before | Export the url_rewrite table and XML sitemaps | Lets you restore any redirect that disappears |
| Before | Note Search Console indexed pages, Core Web Vitals and GA4 organic revenue by landing page | Shows whether a later dip is real |
| Staging | Set staging to NOINDEX, NOFOLLOW and protect it with a password | Keeps the copy out of Google |
| Staging | Compare product, category, CMS, filter and search templates with the baseline crawl | Finds SEO output lost with the theme or an extension |
| Staging | Open product URLs directly, change a category URL key, and run layered navigation and site search | Catches 404s, missing rewrites and search changes after the OpenSearch move |
| Launch day | Confirm Default Robots is INDEX, FOLLOW, robots.txt is the production file and sitemaps regenerate on cron | Stops a staging setting from deindexing the store |
| Launch day | Flush the full page cache and check category pages | Avoids caching empty results from the search cutover |
| Weeks after | Watch Page indexing, Crawl stats and GA4 organic revenue against the baseline | Shows problems Google finds after recrawling |
What extra SEO checks does a Magento 1 or platform migration need?
For a Magento 1 migration or a move to another platform, add Google’s site move guidance. Map old URLs to new ones and redirect straight to the final destination. Keep any chain to three hops or fewer, do not send many old URLs to the homepage, and remove migration-only noindex or robots.txt blocks. Google says a small to medium site can take a few weeks for most pages to move, and recommends keeping redirects for at least a year.
Two outputs often change with a theme or extension, so compare them closely: structured data, covered in our Magento schema markup guide, and filter URLs, covered in our layered navigation SEO guide. For page-level checks, use our Magento 2 SEO checklist.
Product feeds need the same care, because a new URL structure or price format can disapprove Shopping products. Our Magento product feed guide covers what to check in Merchant Center. If traffic has already fallen after an upgrade, our Magento SEO expert service starts with finding the cause.
How do Magento security patches work in 2027?
Every May brings a full patch release for each supported 2.4.x line, and isolated security patch files fix specific vulnerabilities in between. Since September 2026, Adobe’s bulletins have also described a monthly isolated patch for each supported line. Apply each bulletin’s patch for your exact version, test it on staging, and treat urgent bulletins as same-week work.
A few rules from Adobe’s own pages:
- Isolated patches are standalone and non-cumulative. Adobe’s security patch overview says they include fixes for vulnerabilities only.
- Even so, monthly isolated patches must be applied in sequence. Adobe’s Commerce Version Tool guide says so. Its October 2026 patch notes also require the latest -p release of your line first.
- In addition, extended support patches are for Adobe Commerce, not Magento Open Source.
- Since the September 8, 2026 bulletin, Open Source merchants can only download patches for 2.4.7 or later.
- Test every patch in a staging or development environment before production, as Adobe recommends.
On September 7, 2026, Adobe published APSB26-146 for CVE-2026-75650, a zero-day vulnerability that it says has been exploited in the wild against Adobe Commerce merchants. It affects Adobe Commerce 2.4.4 through 2.4.9 and Magento Open Source 2.4.6 through 2.4.9, August 2026 releases and earlier. The instructions are to apply the hotfix for your version, rotate your encryption keys, then rotate related credentials such as admin passwords, API tokens and payment gateway credentials.
Subscribe to Adobe’s security bulletins rather than waiting for the next upgrade. Since September 2026, they live in the Adobe Trust Center instead of HelpX. A store that is one release behind but fully patched is in a far better position than one that skipped months of bulletins.
What did Adobe’s October 2026 security bulletin fix?
Adobe published APSB26-153 on October 13, 2026, a priority 2 update for vulnerabilities rated critical, high and medium. Also, Adobe says it is not aware of any exploits in the wild for these issues. The fixes ship as monthly isolated patch files such as 2-4-9-oct-2026.zip. The bulletin also lists 2.4.10-alpha1 as an updated version.
Even so, three details matter for planning. First, the Open Source fixes cover 2.4.7 and later, even though Open Source 2.4.6 is listed as affected. Second, the October patch leaves out the hotfix for CVE-2026-75650 from APSB26-146, so apply it separately. Third, Adobe published an updated October patch for Adobe Commerce 2.4.8-p5 after some merchants saw an UNKNOWN patch status.
How do you check which security patches are installed?
Use Adobe’s Commerce Version Tool. Adobe ships it inside the monthly isolated patches, starting with July 2026, and it then installs at vendor/bin/patch-status. It then reports applied and missing monthly patches, and it marks each CVE as PROTECTED, VULNERABLE or UNKNOWN. It also works for Magento Open Source, not just Adobe Commerce.
php vendor/bin/patch-status
php vendor/bin/patch-status --format=csvRun it from the Magento root. The default output is JSON, while the CSV option gives one row per CVE for a spreadsheet. If the command is missing, apply the July 2026 isolated patch for your line first, starting with its CE file. Also note that Adobe calls the tool informational only, so it never applies or reverts patches.
Should you upgrade Magento or move to another platform?
Upgrade if Magento’s flexibility still earns its cost for your catalog, store views, B2B setup or integrations, and you have developers who maintain it. Consider moving if most of your budget goes on keeping the platform patched rather than improving the store. Either way, the SEO risk is in the URLs, and a platform move carries more of it than an upgrade.
Moving to another platform changes almost every URL, so the redirect map, structured data and feeds all need rebuilding. Our Magento vs Shopify comparison covers the trade-offs, and our Magento to Shopify migration guide covers the SEO side of the move. Mage-OS, a community distribution of Magento Open Source, is another option some Open Source stores evaluate; its 3.0.0 release in May 2026 builds on 2.4.9. Check its support policy before choosing it.
Still, Hustle Marketers does not run Magento upgrades or platform builds. We handle the search side: the requirements before launch, the crawl comparison and the monitoring after. That work sits in our Magento SEO agency and consultant services.
Magento migration and upgrade FAQs
What is the latest version of Magento?
Magento 2.4.9, released on May 12, 2026 for both Magento Open Source and Adobe Commerce. Adobe lists regular support until May 31, 2029. The only later entry is a 2.4.10-alpha1 build from October 13, 2026, which is not a general release.
When was Magento 2.4.8 released?
Adobe released Magento 2.4.8 on April 8, 2025. Its regular support runs until May 31, 2028. The latest patch on Adobe’s released versions page is 2.4.8-p5, from May 12, 2026.
When was Magento 2.4.7 released?
Magento 2.4.7 was released on April 9, 2024. Regular support ends on May 31, 2027, and Adobe Commerce customers get extended support until May 31, 2028.
Should I upgrade to Magento 2.4.8 or 2.4.9?
Pick 2.4.9 when your extensions, theme and hosting run PHP 8.5. Otherwise take the latest 2.4.8 patch for now and schedule 2.4.9 before 2.4.8 support ends on May 31, 2028.
Can I upgrade Magento from 2.3 to 2.4.9?
Yes, Composer can target 2.4.9 directly, but PHP, the database, the search engine and the cache all have to meet 2.4.9’s requirements first, and custom code usually needs rework. Treat it as a project with full testing on staging, not a routine update.
How long does a Magento 2 upgrade take?
It depends on extensions, custom code and how far the hosting stack must move. Agency figures published in 2026 range from a few days for a simple minor upgrade to several weeks for a customized store, and months for a Magento 1 migration.
Will upgrading Magento affect my SEO rankings?
Not by itself. A version upgrade keeps your URLs and content, so rankings usually hold. Problems come from side effects such as staging robots settings reaching production, SEO output lost with a theme or extension, broken URL rewrites or slower pages. Crawl before and after to catch them.
Does Magento Open Source get extended support?
No. Adobe says extended support patches are for Adobe Commerce only. The September 8, 2026 bulletin also says Open Source merchants can only download patches for version 2.4.7 or later.
Is Magento 1 still supported?
No. Adobe released the final Magento 1 security patches in June 2020, when support for Magento Commerce 1.14 and Magento Open Source 1 ended. Stores still on Magento 1 need a rebuild on Magento 2 or a move to another platform.
Is there a Magento 2.5 or Magento 3?
Adobe has not listed one. Its released versions page ends at a 2.4.10-alpha1 build from October 13, 2026, so plan around 2.4.9 and treat any future release date as unconfirmed until Adobe publishes it.
What is the difference between a Magento upgrade and a Magento migration?
An upgrade moves the same store to a newer Magento 2 release, such as 2.4.7 to 2.4.9, and keeps its URLs. A migration moves the store to a new codebase or platform, such as Magento 1 to Magento 2 or Magento to Shopify, which usually changes URLs and needs a full redirect map.
Do I need a developer to upgrade Magento?
For almost every live store, yes. The upgrade itself is a short set of Composer commands, but the work around it, from server changes and extension updates to code fixes and testing, needs someone who knows Magento. Keep the SEO checks in the same plan.
When will Magento 2.4.10 be released?
Adobe has not announced a general availability date. Its released versions page lists a 2.4.10-alpha1 build from October 13, 2026 and says the support end date for the 2.4.10 line is not set yet. Adobe’s release schedule says the 2.4.x line gets a full patch release every May, so plan around 2.4.9 until Adobe confirms a date.
Which Magento deadlines fall in 2027?
Regular support for 2.4.7 ends on May 31, 2027, as do security-only fixes for Adobe Commerce 2.4.4 and 2.4.5. Adobe Commerce on cloud projects on 2.4.4 or 2.4.5 must upgrade by June 1, 2027, and extended support for 2.4.6 ends on August 31, 2027. Google also turns off the Content API for Shopping in early 2027, and PHP 8.3 support ends December 31, 2027.
How do I check my Magento version?
Run bin/magento --version from the Magento root folder, or look at the bottom right of any Admin page. You can also search composer.lock for magento/product-community-edition or magento/product-enterprise-edition. The /magento_version URL works too, but it shows less detail.
How do I know if my Magento security patches are installed?
Run php vendor/bin/patch-status from the Magento root. Adobe’s Commerce Version Tool lists applied and missing monthly patches and marks each CVE as PROTECTED, VULNERABLE or UNKNOWN. If the command is missing, apply your line’s July 2026 isolated patch first, because it installs the tool.
Does PHP end of life affect my Magento store?
Yes. According to php.net, PHP 8.2 loses security support on December 31, 2026 and PHP 8.3 on December 31, 2027. Adobe’s lifecycle policy calls running PHP past its end of life a PCI compliance risk. So plan the PHP move with the Magento upgrade.










