Adobe's lifecycle documentation lists August 11, 2026 as the end of support for the Adobe Commerce 2.4.6 release line. If you are running 2.4.6, your store does not stop working that day. What changes is quieter and sometimes moreexpensive. New vulnerabilities discovered after that date do not get official patches. Your PCI posture starts drifting. Extension vendors begin testing against newer versions and stop testing against yours. Every future integration decision gets made around a platform version that is no longer moving.
Most of the content published about this deadline has an answer attached before it has a question. Move to SaaS. Replatform now. Upgrade immediately. Those are all defensible recommendations in specific situations and bad ones in others. What follows is the decision framework we walk clients through, including the option most agencies would rather you not consider.
First, confirm which version you are actually on
There is a meaningful difference between Adobe Commerce and Magento Open Source here. Adobe's lifecycle policy describes additional support availability for Adobe Commerce customers on certain versions. Magento Open Source has no equivalent path. If you are on Open Source 2.4.6, August 11 is a harder stop than it is for a licensed Adobe Commerce customer.
Before you budget anything, get three facts from whoever maintains your environment:
- The exact version and patch level you are running today
- Whether you hold an Adobe Commerce license or run Open Source
- Whether your contract includes any extended support entitlement, and through what date
Teams routinely get this wrong. We have walked into environments where leadership believed they had another year of coverage and did not, and environments where the panic was unnecessary because coverage existed. Verify before you decide.
Option one: patch to the latest 2.4.6 release and hold
Apply every available patch, harden what you can at the infrastructure and WAF layer, and accept a defined window of elevated risk while you plan properly.
This is the option nobody writes blog posts about, and it is occasionally the right one. If you are eight weeks from a peak season, or mid-way through an ERP migration, or your commerce leadership seat is currently vacant, starting a platform upgrade in August is how you end up with two failed projects instead of one.
Choose this if: you have a hard organizational constraint in the next two quarters and a real plan to move after it clears. The tradeoff: you are accepting unpatched vulnerability exposure on a revenue-generating system. That is a decision for a named executive to make deliberately, not something to arrive at by drift. Do not choose this if: you cannot name the date you will start the actual upgrade.
Option two: upgrade to 2.4.8 and stay on PaaS
The conventional path. Support for the 2.4.8 release line runs into 2028, which buys you real runway.
For most B2B merchants with heavy customization, deep ERP integration, and a stable operating model, this remains the lowest-drama option. Your extensions mostly work. Your team already knows the platform. Your integrations survive.
Choose this if: your current implementation basically works and the problem you are solving is a support deadline, not a business one. The tradeoff: you are buying time, not changing your structural position. You will run this project again in a few years. Watch for: custom code volume. The upgrade cost lives almost entirely in customization and extension compatibility, not in the core version bump. Audit that before you scope.
Option three: move to Adobe Commerce as a Cloud Service
Adobe's SaaS offering removes the upgrade treadmill. Updates are managed. Infrastructure is managed. The recurring cost of staying current largely goes away.
The caveat is that this is not an upgrade. It is a rebuild. The architecture is headless-first, and if you are running a traditional Luma-based storefront, your frontend is not coming with you. Budget accordingly and do not let anyone tell you otherwise in a sales cycle.
Choose this if: you are already planning a significant experience redesign, and the platform decision and the UX decision can be made together rather than sequentially. The tradeoff: highest near-term cost and longest timeline of the four options. The payback is real but it is measured in years, not quarters. Do not choose this if: you are making the decision under deadline pressure. This is the worst possible way to enter a rebuild.
Option four: reassess whether Adobe is still the right platform
Some of the B2B merchants running 2.4.6 today chose Adobe in an era when it was the only enterprise-grade option for complex catalogs and contract pricing. That is no longer true. A forced platform decision is a legitimate moment to check whether the original reasoning still holds, and the answer is frequently that it does. Complex configurable products, deep ERP dependency, sophisticated pricing hierarchies, and multi-org account structures are still places where Adobe is genuinely strong. But if your catalog is simpler than it was, or your customization backlog exists mostly to work around the platform rather than to serve buyers, it could be worth exploring an eCommerce technology audit to decide the best path forward.
Choose this if: your last platform evaluation was more than four years ago and your business has changed materially since.
The tradeoff: evaluation takes time you may not have in August. Do the triage first, then run this properly in the fall.
What to do in the next two weeks
The deadline is close enough that the goal is not to complete a migration. It is to make a deliberate decision instead of an accidental one.
- Confirm your version, license type, and any extended support entitlement. In writing.
- Get a current inventory of customizations and extensions, with an owner for each. This number drives every cost estimate that follows.
- Name one accountable executive for the decision. Platform decisions made by committee stall, and the stall becomes the decision.
- Pick a lane from the four above and put a date on the next milestone.
The merchants who handle this well are not the ones who move fastest. They are the ones who decide on purpose. An unpatched platform is a manageable risk for a defined period with a named owner and a plan. It is a serious problem when it is simply what happened because nobody chose.
If you want a second opinion on which lane fits your situation, our eCommerce technology audit maps current-state architecture and customization load against business outcomes, and produces a ranked recommendation rather than a single predetermined answer.
FAQs
Q: Does my store stop working on August 11, 2026?
A: No. Adobe Commerce 2.4.6 continues to run normally after the support end date. What ends is official patching and support. Any security vulnerability discovered after that date will not receive an official fix for your version, which creates compounding risk over time rather than an immediate outage. The practical concerns are security exposure, PCI compliance posture, and gradually diminishing extension and integration compatibility.
Q: What is the difference between Adobe Commerce and Magento Open Source for this deadline?
A: Adobe's lifecycle policy treats licensed Adobe Commerce customers differently from Magento Open Source users regarding additional support availability. Open Source users generally have no extended support path once a release line reaches end of support. Because entitlements vary by contract and have been adjusted over time, verify your specific coverage with Adobe or your solution partner rather than relying on general guidance, including this article.
Q: How long does an Adobe Commerce upgrade actually take?
A: The core version upgrade is rarely the long pole. Timeline is driven almost entirely by the volume of custom code, the number of third-party extensions requiring compatibility work, and the depth of ERP and PIM integration. A lightly customized store can move in six to eight weeks. A heavily customized B2B implementation with deep back-office integration commonly runs four to six months including testing. Scope the customization inventory before you accept any timeline estimate.
Q: Should we move to SaaS instead of upgrading?
A: It depends on whether you are also ready to rebuild the storefront experience. Adobe Commerce as a Cloud Service uses a headless-first architecture, so a traditional Luma storefront does not migrate directly. That makes the move a rebuild rather than an upgrade. It is a strong option when a platform decision and an experience redesign are being made together, and a poor one when it is being chosen under deadline pressure to avoid a future upgrade cycle.