Skip to main content
Talk to an expert
Issue 048PositionAdobe CommerceRef 065

When to keep Magento 2 past end-of-life: a defensible position, not a default one

The official advice is clear: migrate from any platform before its support ends. For Magento 2, this means moving to Adobe Commerce or replatforming entirely. However, for a select few enterprise businesses facing major strategic shifts, a calculated, temporary delay can be a defensible position. This requires a rigorous risk mitigation plan, not inertia.

The Default Action: Why End-of-Life is a Hard Stop

The standard advice from any platform vendor, including Adobe, is unequivocal: running software beyond its end-of-life (EOL) date is a critical business risk. The Adobe Commerce documentation is clear on its lifecycle policy for a reason. Once a version is no longer supported, it stops receiving security patches, quality fixes, and performance updates. For any commerce director or CTO, this should trigger immediate action. The risks are not theoretical. Without security patches, your platform becomes a fixed target for automated exploits searching for known vulnerabilities. PCI DSS compliance, the baseline for accepting card payments, becomes almost impossible to maintain without costly and complex compensating controls, which your Qualified Security Assessor (QSA) may not even accept.

Beyond security, the entire ecosystem begins to decay. Third-party extension vendors move on, focusing their development and support on current platform versions. Finding skilled developers willing to work on an obsolete and insecure stack becomes harder and more expensive. Performance degrades as the underlying technologies, like PHP and Elasticsearch, also move on, leaving your site unable to benefit from their improvements. In short, the platform becomes an island of accumulating technical debt and escalating risk. For 99% of businesses, the correct and only decision is to begin the process of replatforming well in advance of the EOL date. This is the default, and it is the correct default.

The Exception: When Strategy Overrules the Technical Roadmap

While the risks are real, there are exceptional business circumstances where a rigidly enforced technical roadmap can create a greater strategic risk. These are not get-out-of-jail-free cards for budget deferral; they are specific, board-level scenarios where a planned, short-term delay of a replatform is the lesser of two evils. Consider a large group of companies undergoing a major merger or acquisition. We have seen this with complex organisations like the Donaldson Group. Committing to a multi-million-pound replatforming project for one entity, only to find the new parent company uses a different stack entirely, is an immense waste of capital and effort. In this case, the strategically sound move might be to place the existing Magento 2 site into a hardened, stable state for 9-12 months while a group-wide technology decision is made.

Another classic example is a concurrent, high-stakes ERP migration. Moving from an on-premise SAP or Microsoft Dynamics instance to a cloud equivalent is one of the most disruptive projects a B2B business can undertake. It affects every corner of the organisation, from finance to logistics. Attempting a full commerce replatform at the same time introduces an unacceptable level of compound risk. A failure in one project will cascade into the other. Decoupling the two, and accepting a managed period on an EOL platform to ensure the ERP project lands successfully, can be a prudent decision. The key condition is that this is a conscious choice with a defined, alternative plan, not simply a failure to plan ahead.

"An end-of-life platform is not a technical problem to be patched; it is a business risk to be owned at board level, with a funded exit plan and a non-negotiable deadline."

What 'A Defensible Position' Actually Involves

Choosing to remain on an EOL platform temporarily is not a passive act. It is not 'doing nothing'. It is an active, expensive, and resource-intensive strategy of risk mitigation. The term we use internally is 'containment'. The first and most critical component is a security lockdown. This means moving beyond standard protections and investing in a top-tier Web Application Firewall (WAF), continuous penetration testing by external specialists, and an aggressive server hardening and access control policy. You are effectively building a perimeter wall around a known vulnerability, and that wall needs to be exceptionally strong. We often see clients in this position double their spend on security and infrastructure monitoring for the duration.

Secondly, the platform must enter a strict operational lockdown. This means a total feature freeze. The site's purpose is to continue transacting safely, not to evolve. No new extensions, no new feature development, no significant changes to the front-end. The development team's role shifts from building to monitoring and maintaining the containment field. This can be a difficult message for commercial teams to hear, but it is non-negotiable. Attempting to build new functionality on a frozen, EOL platform is how many businesses find themselves needing emergency rescue projects. The goal is stability above all else, preserving the asset until the strategic blockers are cleared and a full replatform can commence.

The Exit Plan: A Bridge, Not a Destination

The single most important element that makes staying on EOL Magento 2 defensible is a funded, board-approved, and time-bound exit plan. Without this, you are not being strategic; you are simply procrastinating. The decision to delay a replatform must be accompanied by the project to replace it. A 'defensible' EOL strategy might state: 'We will remain on our current platform for a maximum of 12 months post-EOL, during which time we will run a hardened security posture. In parallel, the replatforming project to Adobe Commerce will complete its discovery and design phase, with development commencing no later than month six.' This is a plan. 'We will revisit replatforming next year' is not.

This plan must have a budget attached and a project lead assigned from day one. It is the guarantee that the temporary measure remains temporary. From our experience with large-scale B2B commerce sites, particularly in sectors like builders merchants, the discovery and architecture phase of a major replatform can take 3-6 months. This work can and should happen during the EOL containment period. This ensures that as soon as the strategic hurdle, such as M&A finalisation, is cleared, the project can move into execution without delay. The containment strategy buys you time for your business, but you must use that time to prepare for the inevitable migration.

Written by
Neil Boughton, Technical Director at iWeb
Neil Boughton
Technical Director
29 years at iWeb

Neil leads platform architecture and integration strategy at iWeb. He has designed ERP and commerce integration patterns across manufacturing, wholesale and retail, and writes about operational resilience, release governance, observability, and the infrastructure decisions that determine whether large programmes stay stable under pressure. Bias toward durable, measurable systems over architectural theatre.

The briefing · regular

A regular round-up of new notes.
No content marketing.

Sent on the last Thursday of the month. The most useful five notes from the previous four weeks, written by the operators, architects, engineers and commercial leads running the work.
Next step

Take this conversation private.

If this note matches the brief on your desk, the version we'd write for your platform, sector and trade-account model is the work itself. Send a short brief and a senior lead replies inside 48 hours.
Talk to an expertBack to The Record →