Magento 2.4.6 End of Life (Aug 11): The Performance Checklist Before You Upgrade

On August 11, 2026, Adobe pulls the final security patch line for Magento Open Source 2.4.6 and Adobe Commerce 2.4.6. The last release in the line, 2.4.6-p15, shipped on May 12, 2026, and it is the last one you will get. After August 11, no new patches for security, PHP compatibility, or dependency CVEs on that version.

That has two immediate consequences. First, PCI compliance. Merchants running on an unsupported version at the end of 2026 will fail PCI-DSS 4.0 audits, because the standard requires vendor-supported components. Second, and less discussed, is performance risk. Every unpatched Composer dependency you carry starts to accrue debt that PHP 8.4 and 8.5 will eventually refuse to load, and the closer you get to the next PHP release, the more your options narrow.

The Adobe Commerce lifecycle policy has the exact windows. Read it once, then plan the upgrade before the last full week of July so you have a rollback window.

There are three realistic paths from 2.4.6 to a supported platform, and each has a different speed profile.

Patch to Magento 2.4.9 (Open Source or Adobe Commerce). This is the cheapest and fastest path if your codebase is reasonably clean. You stay on the same platform, keep your themes and extensions, and inherit a large batch of bug fixes and dependency updates. Well-maintained stores can complete the upgrade in two to four sprints.

Move to Adobe Commerce Cloud. If you are already on Adobe Commerce and want managed infrastructure, this is a lift and shift with configuration work. Speed impact depends heavily on how much of your current custom Nginx and Redis configuration you can port. Cloud gives you Fastly at the edge by default, which usually improves TTFB, but the underlying PHP-FPM tuning is opinionated and can regress you if your current stack is heavily tuned.

Replatform to Shopify or BigCommerce. This is a business decision, not a maintenance decision. Speed-wise, both hosted platforms usually cut TTFB significantly on catalog and search, but require a full theme rebuild and a checkout flow rewrite. If you are considering this, you are looking at a three to six month project, not a five week one. Do not treat it as a substitute for the 2.4.6 patch deadline.

For nine out of ten stores we audit, the 2.4.9 patch is the right answer. The rest of this post assumes you are going to 2.4.9.

2.4.9 is the largest bug-fix release in the 2.4.x line, with more than 501 fixes rolled up according to Adobe. The 2.4.9 release notes document the full list, but the changes that matter for storefront speed are:

• Symfony Cache replacing older cache pool code, which reduces PHP object hydration cost on cache reads.
• Valkey support for session and cache backends, a drop-in Redis fork that is still actively developed. If you are running Redis 7.2 or below, Valkey is your migration target.
• PHP 8.4 and 8.5 compatibility. PHP 8.4 gives you real JIT improvements on catalog-heavy pages; 8.5 (when released) brings further Opcache work. 2.4.6 caps you at PHP 8.3.
• Extended support through roughly 2029, so this upgrade should hold for two to three more years before you have to plan another one.

Skipping 2.4.7 and 2.4.8 to jump straight to 2.4.9 is the recommended path in Adobe's own upgrade guidance. You pick up every fix in one step.

The upgrade window is the natural moment to answer a question that most Magento stores have been putting off for two years. Do you stay on Luma or the classic PWA Studio frontend, or move to Hyva?

Hyva is a Tailwind and Alpine.js based frontend that replaces the Luma theme. It ships with less JavaScript, no Knockout.js, and no RequireJS on the storefront. In our 2026 audit sample, Hyva stores pass all three Core Web Vitals at roughly a 65% rate, compared to about 41% for traditional Luma-based frontends on comparable catalogs.

The catch is that Hyva is a full theme rewrite. Every extension that touches the frontend needs a Hyva-compatible module or a custom port. If you have five or fewer frontend extensions and no heavy customization, add three to five weeks to your upgrade and switch. If you have twenty or more, plan Hyva as a separate project after the 2.4.9 patch lands.

The wrong move is a partial migration. A store that is half Luma and half Hyva runs both stacks and is slower than either.

Before you touch composer.json, capture a baseline you can compare against after the upgrade. If you skip this, you will not know whether your upgrade improved, degraded, or held speed steady.

Capture these five numbers per key template (homepage, category, product, cart, checkout), from CrUX where available and from a lab tool where the URL has no field data yet:

• 75th percentile LCP from CrUX for the URL and the origin.
• 75th percentile INP from CrUX for the same.
• 75th percentile CLS.
• Server TTFB from a warm-cache PageSpeed Insights or WebPageTest run, averaged over three tests.
• Full page weight and request count from WebPageTest, so you can see if a theme change bloats the payload.

Save the raw exports somewhere durable. Screenshots alone are hard to diff, so keep the underlying CSV or JSON for every metric you plan to compare after the upgrade.

After the upgrade goes live, wait a full 28 days before you decide whether it was a speed win. CrUX data is a 28-day rolling window; anything you look at sooner is contaminated by the pre-upgrade tail.

The checklist we run for clients on the day of go-live and again at day 28:

• Compare each of the five baseline numbers to their post-upgrade values. Anything that regresses more than 10% is a bug, not a feature.
• Confirm Opcache and Realpath cache are sized for PHP 8.4. Default values from a 2.4.6 install are usually too small for 8.4's JIT working set.
• Re-tune Valkey or Redis maxmemory for the new session and cache footprint, which is different from 2.4.6.
• Verify Fastly or Varnish cache hit rate. Layout XML changes in 2.4.9 can invalidate cached blocks in ways that lower your hit rate without any visible error.
• Run a full Lighthouse audit against the four key templates and diff against the pre-upgrade run.
• Watch INP for two full weeks. JavaScript changes in 2.4.9 admin and storefront modules occasionally introduce new long tasks, and INP is the metric that surfaces them first.

We audit Magento storefronts against exactly this checklist, before and after major version upgrades, and hand back the pre and post CrUX comparison so you can prove the upgrade held speed. If you want a second set of eyes on your 2.4.6 to 2.4.9 plan, book a free assessment through our speed optimization services, or get in touch with your current storefront URL and we will pull your CrUX baseline before the call.