Adobe Commerce Upgrades: What They Cost and When You Must Move
Shakewell ·
Most Adobe Commerce upgrade projects start the same way: someone forwards an email about a version reaching end of support, and a date that felt theoretical becomes a budget line.
If you are on 2.4.5 or 2.4.6, that date is this week.
The dates that matter
From Adobe’s software lifecycle policy, each 2.4.x release gets a three-year standard support window from general availability, followed by an extended support period:
| Version | Standard support ends | Extended support ends |
|---|---|---|
| 2.4.4 | 12 April 2025 | 14 April 2026 |
| 2.4.5 | 12 August 2025 | 12 August 2026 |
| 2.4.6 | 11 August 2026 | 30 August 2027 |
| 2.4.7 | 31 May 2027 | 31 May 2028 |
| 2.4.8 | 31 May 2028 | TBC |
Two things follow. 2.4.4 is now entirely out of support — both windows have closed. And 2.4.5 and 2.4.6 both hit a deadline in August 2026: 2.4.5 leaves extended support on the 12th, 2.4.6 leaves standard support on the 11th.
If you are on Adobe Commerce Cloud there is a second date: from 1 June 2027, Adobe stops maintaining Cloud environments running unsupported versions.
What “out of support” actually means
Not that the store stops working. It means no more security patches for the core application.
That distinction matters for budgeting, because it turns a technical task into a risk decision. An unsupported store keeps trading until a vulnerability is disclosed that will never be patched — and commerce platforms are actively scanned. The cost of the upgrade is knowable; the cost of the alternative is not, which is exactly the wrong shape of risk to carry on a system that takes card payments.
It also has a compliance dimension. If you handle payments, running unpatched software on a known-vulnerable version is difficult to defend in a PCI conversation.
What an upgrade costs
The honest answer is that the version jump is rarely the expensive part.
A minor version upgrade — 2.4.6 to 2.4.7, say — on a store with few customisations and well-maintained extensions is usually a matter of days: dependency updates, a regression pass, a staged deploy.
A typical mid-market upgrade costs more because of what surrounds the core. Third-party extensions need versions compatible with the target release, and some will not have them. Custom modules written against older APIs need updating. Theme changes may be required. Budget weeks rather than days, and expect the extension audit to produce at least one unwelcome surprise.
A multi-version jump — anything from 2.4.4 or earlier — behaves like a small replatform. You are crossing several sets of breaking changes at once, and the realistic path is often to upgrade in stages rather than in one leap.
The variable that predicts cost better than any other is how disciplined the original build was. A store with fifteen well-chosen extensions and clean custom code upgrades cheaply and repeatedly. A store with sixty extensions installed over eight years, several abandoned by their vendors, is expensive every single time — and will be expensive again in three years unless that debt gets addressed during the upgrade.
Budgeting for support, not just upgrades
The pattern we see most often is a business that budgets for builds and treats support as a contingency. It is the wrong way round: on a platform with a three-year support window, upgrades are not exceptional events, they are a recurring obligation.
A workable annual budget covers four things:
- Security patching between versions — Adobe releases patches within a supported version, and applying them promptly is the cheapest security work available.
- The upgrade itself, amortised. If you must move every two to three years, set aside a portion each year rather than facing it whole.
- Extension maintenance — licence renewals, and the periodic cost of replacing one whose vendor has stopped maintaining it.
- Improvement work. A store that only ever receives maintenance slowly stops matching the business.
Reducing what the next one costs
Every upgrade is an opportunity to make the following one cheaper, and most teams skip it because the pressure is to get back to trading.
Audit extensions and remove what nobody uses. The most common finding on a store we take over is a set of extensions still installed, still loading, and serving no current purpose.
Get custom code off deprecated APIs rather than shimming it. A shim survives one upgrade and fails the next.
Stop customising the core. Core patches applied over modified core files are how a three-day upgrade becomes a three-week one.
Keep a staging environment that matches production. Upgrades tested somewhere that resembles production go well; upgrades tested somewhere that does not are how launch-day surprises happen.
When the answer is not to upgrade
Sometimes the right response to an end-of-support date is to leave.
If Adobe Commerce is more platform than you are using — no complex catalogue rules, no B2B pricing, no multi-store, no ERP integration that has to be exact — then paying for repeated upgrades to a platform you are not exploiting is poor value. Moving to Shopify removes the upgrade cycle entirely, and for many mid-market retailers the total cost of ownership drops.
If those things do describe you, Adobe Commerce is earning its keep and the upgrade is simply the cost of the capability. For Aelia Duty Free — multi-currency, multi-location, duty and tax logic, real-time inventory across airports — that is exactly the case, which is why we stabilised the platform first and then kept it current rather than proposing a move.
What to do this week
If you are on 2.4.5 or 2.4.6, you do not need a full project plan today. You need three answers:
- What version are you actually on, including patch level?
- Which extensions block the next version, and does each have a compatible release?
- Who is applying security patches between now and the upgrade?
That is a short audit, not an engagement, and it converts an unknown risk into a scheduled cost.
If you want a second opinion on where your store sits, we are happy to look — including telling you when staying put is the right call.
Related: Adobe Commerce development · Support & maintenance · Magento to Shopify migration cost