DEV Community: Zelpex

Magento 2.4.6 Lost Support in August: What Waiting Actually Costs

Andrii B. — Wed, 23 Sep 2026 18:19:09 +0000

If your store runs Magento 2.4.6, it stopped receiving security patches on 11 August 2026. The one exception is Adobe Commerce, the paid edition, which gets one more year. Magento Open Source, the free edition, does not.

So the decision in front of you is about exposure, not features: how long you are willing to run a checkout that nobody will fix when the next hole is found, and what it costs to stop.

Who is out of support, and until when

Adobe gives every 2.4 release three years of standard support, then stops shipping patches for it. For 2.4.6 and 2.4.7 it adds one extra year, but its lifecycle policy grants that year to "Adobe Commerce customers" only.

Version	Standard support ended / ends	Adobe Commerce only, extended to
2.4.6	11 August 2026	31 August 2027
2.4.7	31 May 2027	31 May 2028
2.4.8	31 May 2028	–
2.4.9	31 May 2029	–

There is a second clock under the first, and it catches Adobe Commerce customers too. Magento 2.4.6 runs on PHP 8.1 or 8.2. PHP 8.1 stopped receiving security fixes on 25 November 2025, and PHP 8.2 stops on 31 December 2026. So even a licence holder using the extra year will spend most of it on a language version that no longer gets security fixes of its own. The extension buys time to plan the upgrade. It is not a place to stay.

What waiting has cost other stores

The usual argument for waiting is that nothing has gone wrong yet. The last two years of Magento security history say otherwise.

In June 2024 Adobe patched CosmicSting (CVE-2024-34102), a flaw that let attackers read files on the server, including the store's secret encryption key. Sansec, which monitors Magento stores, reported that by that autumn 5% of all Adobe Commerce and Magento stores had a payment skimmer on their checkout page: 4,275 stores, attacked by seven competing groups. Some of them had installed the patch. Patching did not invalidate keys that had already been stolen, so stores that skipped rotating the key stayed open.

In September 2025 Adobe shipped an emergency fix for SessionReaper (CVE-2025-54236), a critical flaw that could lead to remote code execution. Six weeks later, when attacks began, Sansec found 62% of Magento stores still unpatched.

Two things follow for a store deciding what to do about 2.4.6. The gap between a fix and mass exploitation is measured in weeks, not years. And on an unsupported version there is no fix to install when the next one arrives: you are in the 62% by default, with no way out except the upgrade you postponed.

The compliance side

If you take card payments, PCI DSS requirement 6.3.3 expects critical security patches to be installed within 30 days of release. Version 4.0.1 of the standard narrowed that to critical vulnerabilities only, but kept the deadline.

A store on an unsupported version cannot meet that requirement the ordinary way, because no patch will be released. That doesn't make you non-compliant overnight, and it isn't legal advice. It does mean that at your next assessment you will need to explain which compensating controls you rely on instead, and that conversation gets harder every month the version stays in place.

What the upgrade actually involves

The upgrade itself is rarely the expensive part. What makes it expensive is everything around the Magento code.

The infrastructure moves first. Magento 2.4.8 runs on PHP 8.3 or 8.4, and 2.4.9 only on PHP 8.5 with OpenSearch 3, so the hosting stack has to change along with the application. Then come extensions and integrations: Adobe's own guidance notes that Marketplace extensions and third-party integrations may be affected, and each one has to be checked, updated or replaced. A store with a handful of well-maintained extensions and a stock theme is a very different project from one with years of custom modules and a hand-built ERP sync.

That is also why the cost of waiting compounds. Adobe says plainly that regular updates take less overall effort than infrequent ones. A store that moves every release does a small upgrade each time. A store that skips two or three does all of them at once, under pressure, usually after something has already gone wrong.

Our view on the target: go to the newest release your extensions support. If everything you rely on runs on 2.4.9, that buys support until May 2029. If a critical extension isn't ready, 2.4.8 is a sound stop until May 2028, and the next step from there is smaller.

The options, honestly

Upgrade on Magento. For most stores this is the answer. It keeps your catalogue, customers, order history and integrations where they are.

Move to Mage-OS. Mage-OS is a community-maintained distribution of Magento Open Source that ships its own releases and security patches, with the aim of patching faster. It is currently based on Magento 2.4.9, so switching is itself an upgrade, not a way to stay on 2.4.6. It is worth considering if you would rather not depend on Adobe's release schedule for the free edition.

Replatform. If the upgrade estimate comes back close to the cost of moving, it is fair to ask whether Magento is still the right platform. That is a bigger decision with its own hidden costs; we compared the platforms in what Adobe Commerce, Shopify and BigCommerce actually cost.

Do nothing. A web application firewall and closer monitoring reduce risk while you plan. They buy time. They don't replace patches, and they don't help with the PHP version underneath.

Before you get an estimate

Four questions decide how big this job is:

Which edition are you on? Adobe Commerce gives you until 31 August 2027. Open Source gave you until 11 August 2026.
Which PHP version does the server run? If it is 8.1, the language itself is already out of security support.
How many extensions and custom modules does the store use, and who maintains them? This list drives the estimate more than anything else.
What sits around the store? ERP, PIM, payment and shipping integrations each need testing against the new version.

If you would rather work through this against your own store's extension list and integrations, talk to us.

Support dates verified against Adobe's software lifecycle policy and system requirements, and PHP dates against php.net, in September 2026. Incident figures from Sansec's reports on CosmicSting and SessionReaper; PCI DSS changes from the PCI Security Standards Council.

Originally published at zelpex.com.

When a Manufacturer's CRM Should Be Built, Not Bought

Andrii B. — Wed, 23 Sep 2026 17:50:28 +0000

Most manufacturers who ask whether they should build their own CRM are asking about the wrong piece of software. The part their sales team uses every day is close to a commodity, and buying it is usually right. The part their dealers, distributors and service technicians touch is where the business is genuinely different, and it is also where the licence bill grows fastest.

So the useful question is narrower: which part of the CRM should you build, and which part would you be foolish to build?

Why manufacturing sales breaks generic CRM

A CRM is designed around a contact, a deal and a pipeline. Manufacturing sales rarely looks like that. The customer is a distributor with negotiated contract pricing. The order is a spare part identified by a code that was superseded two revisions ago. The delivery date depends on a production slot the ERP knows about and the CRM does not. And the person asking is often a technician on a plant floor, not a buyer in an office.

None of that data belongs to the CRM. Price, availability and lead time live in the ERP, and they have to stay there. Every CRM project for a manufacturer therefore turns into the same work: showing people outside the ERP an honest answer from inside it, without exposing how complicated it is to produce. That is true whether you buy the CRM or build it, and it is the part of the budget people tend to underestimate.

What buying actually costs

The vendors built for this are not cheap, and they price per person. Salesforce's industry product for manufacturers, Manufacturing Cloud, lists at $275 per user per month for its Sales or Service "Core" editions, $425 for the Advanced edition, and $650 to $700 for the "Max" editions that bundle its AI agents, all on annual contracts. HubSpot's Sales Hub is the lighter alternative at $90 per seat per month on Professional (billed annually) and $150 on Enterprise, plus a mandatory one-off onboarding fee of $1,500 or $3,500.

Seats for your own staff are only half the bill. The other half is everyone outside the company who needs to log in.

Salesforce prices its partner portal, Partner Relationship Management, at $25 per member per month, with a more capable tier at $50 and login-based pricing available for users who rarely sign in. Run the list prices for a hypothetical mid-size manufacturer: 15 internal users on Manufacturing Cloud Sales Core and 300 dealer accounts on the partner portal.

Line	Calculation	Per year, list price
Internal users	15 × $275 × 12	$49,500
Dealer portal members	300 × $25 × 12	$90,000
Total licences		$139,500

The dealers cost almost twice as much as the sales team, before a single integration is built. List prices get discounted and login-based licences cut the portal line for dealers who sign in rarely, so treat the table as the shape of the bill rather than a quote. The shape is the point: in manufacturing, the external audience is usually larger than the internal one, and per-member pricing scales with it every year.

The quoting trap

Quoting is usually where a packaged CRM starts to fit badly. Prices come from rules, not a table: the customer's contract, the volume, the configuration, which options are compatible with which, and what the ERP says a variant actually costs to make.

The standard answer used to be Salesforce CPQ, and it is no longer sold to new customers. Existing customers keep it, with support and renewals but no new features, while new buyers are pointed at its successor, Revenue Cloud Advanced. Salesforce is careful to call this end of sale, not end of life. For a manufacturer choosing today, though, it means the configure-price-quote layer most comparison articles describe is not the one you would be buying, and a quoting project is a separate licence and a separate implementation on top of the CRM.

This is the first place building starts to make sense. If your pricing logic is yours alone, encoding it in a quoting tool you own is often cheaper and clearer than bending a generic rules engine around it.

Where building earns its place

We would split the system in three and treat each part differently.

The internal CRM: buy it. Accounts, pipeline, activity history, service cases, reporting. This is well-solved software. Building it means rebuilding permissions, audit trails, email sync and mobile access that a vendor already maintains, and your team would be maintaining them for ever.

The ERP: leave it alone. It is the system of record for price, stock and lead time. Neither the CRM nor anything you build should hold a second copy of those numbers that can drift.

The dealer portal and quoting rules: build them when they are where you compete. This is the software your customers actually use. It carries your contract pricing, your supersession chains for spare parts, your serial-number history for service, and your availability promises. A custom portal is priced once to build and then maintained, not charged per dealer per month, and it can read the ERP directly instead of through a CRM in the middle.

The split is not free. A custom portal needs an owner, a hosting bill, security updates and someone who understands it when the person who built it has moved on. If you have no one to own software, the per-member licence is the price of not needing them, and it can be worth paying.

The test

Before deciding, answer four questions honestly.

How many people outside the company need to log in? If it is a handful, a vendor portal is fine. If it is hundreds of dealers or technicians, price the per-member line over five years before anything else.
Is your pricing a table or a set of rules? A price list fits any CRM. Contract pricing, configuration rules and ERP-derived costs are where packaged quoting gets expensive and awkward.
Where does the true answer on availability live? If it is the ERP, whatever customers see has to read from it, and that integration is the real project either way.
Who will own the software in three years? Building only works if the answer is a named person or a partner, not "IT".

If the answers are "few", "a table", "the ERP" and "nobody", buy the whole thing and keep the configuration shallow. If they are "hundreds", "rules", "the ERP" and "we can", buy the CRM, build the portal, and let the ERP stay the source of truth.

If you would rather work this through against your own dealer network and pricing rules, talk to us.

Prices verified against Salesforce Manufacturing Cloud, Salesforce Partner Relationship Management and HubSpot Sales Hub pricing pages, and Salesforce's CPQ end-of-sale page, in September 2026. All figures are list prices in US dollars.

Originally published at zelpex.com.