This text gives you one answer: is your store still patched. Then we show what that means for costs, what really takes Magento stores down, and what an honest care budget looks like. If you then check the version and decide yourself, the text has done its job.
The dates everything starts from
The Adobe Commerce lifecycle policy is simple: three years of standard support from the GA date, plus extended support for some versions. Below are the deadlines that matter today.
| Version | Standard support until | Extended support until |
|---|---|---|
| 2.4.5 | August 12, 2025 | August 11, 2026 |
| 2.4.6 | August 11, 2026 | August 31, 2027 |
| 2.4.7 | May 31, 2027 | May 31, 2028 |
| 2.4.8 | May 31, 2028 | none published separately |
It is now September 2026, so the conclusions are short. On 2.4.5 both standard and extended support have passed (August 11, 2026): no new patches, and every publicly described vulnerability stays with you for good. On 2.4.6 standard support ended on August 11, 2026, but extended support runs to August 31, 2027: your window for a planned Magento upgrade, not for postponing the subject.
On 2.4.7 or 2.4.8 you can decide the next step with a cool head, well before May 31, 2027 and May 31, 2028 respectively.
Magento Open Source is a separate matter, with no commercial support and no published deadlines of its own. In practice you depend on community patches and on whether somebody on your side applies them. Do not transfer the dates above to it, the model is different.
How to check where you stand in five minutes
You need no provider and no audit. Three moves are enough.
First: the admin panel. The version number sits in the footer once you log in, a result in fifteen seconds.
Second: composer.json in the application directory, or rather composer.lock, which shows the core version plus every third party module. Without server access, ask for a copy. One email.
Third: a question to your provider that cannot be answered with a generality. Which exact version is on production, when was the last security patch applied, was it tested on staging. An answer without a version number and a date is not an answer.
Why Magento maintenance costs more than WooCommerce or PrestaShop
This is not about margin, but three technical differences.
Infrastructure. Beside the application stand services that must run and be watched: search, cache, message queues and the cron scheduler. On WooCommerce an outage is usually one process failing. In Magento several places can stop independently of the page the customer sees.
Skills. Magento is work for a developer, not a content administrator. What is a click in the panel elsewhere means a code change, reindexing and a deployment. The rate per hour is the same, but far fewer people can work it.
Time to ship a change. You do not change things on production. There is staging, a deployment procedure and regression tests, because one module change can overturn the cart. The same small fix takes more hours than on PrestaShop, the most common surprise at the first invoice. We cover it in the article on how much it costs to run an online store.
What really takes Magento stores down
Five things that in our practice generate the most tickets: symptom, cause and order of magnitude of restoration time. That is an observation from our work, not a declared repair time: the time to remove a failure cannot be honestly promised in advance.
Stopped queues and crons. The symptom misleads: the store looks healthy, pages open and orders are placed, but nothing reaches the ERP, transactional emails do not go out, stock does not update. The cause is often a killed queue consumer or a scheduler switched off after a restart. Order of magnitude: from tens of minutes to a few hours, the longest part being the backlog.
Full disk and logs. Symptom: write errors, the panel stops responding. The cause is usually banal: debug logging switched on at launch and never switched off. Order of magnitude: from fifteen minutes to an hour, if somebody watches free space.
Reindexing and cache after a deployment. Symptom: the store shows old prices, empty categories or broken styling. The cause is unprocessed indexes or static content that was not rebuilt. Order of magnitude: from tens of minutes to a few hours, by catalogue size.
Third party modules incompatible with the version. The symptom appears right after an upgrade: a 500 error at one step of the cart or in the panel. The cause is a module that does not declare compatibility with the new core. Order of magnitude: from a few hours to a few days, waiting for a vendor release.
Payment integrations. Symptom: the payment starts, no status comes back, the order stays pending. The cause is a change on the provider side, an expired certificate or key. Order of magnitude: from tens of minutes to a few hours, part of it outside our hands. What downtime costs is in the article on the cost of online store downtime.
What monthly Adobe Commerce store care should include
The minimum worth demanding from any provider, including us.
Security patches on an agreed regime. With us critical updates go in within 72 hours, the rest within 14 days, always on staging first. Without that last condition, fast patching is a risk, not a service.
Monitoring of what can actually stop. Checking the home page every 60 seconds is necessary and insufficient here. Watch the queues, the crons and whether events leave for external systems, where silent failures start.
Backups with a restore test. A backup nobody has restored is an assumption, not a safeguard. In the basic package we back up every 7 days and test a restore quarterly.
Log review. Reading application logs regularly is boring, and the only way to see a problem before the customer does.
Budget: three store profiles
Profile one: a store on 2.4.7 or 2.4.8, a few integrations, a catalogue of a few thousand SKUs, changes ordered rarely. The realistic package is Advanced at 500 USD a month with 20 hours, enough for patches, small changes and tickets.
Profile two: a store on 2.4.6 facing an upgrade, with a dozen third party modules and an ERP integration. Here 20 hours run out in the month the upgrade lands. The realistic package is Premium at 1,000 USD a month with 40 hours.
Profile three: a store on 2.4.5, out of support, with custom modules. Before we discuss a subscription, you need an exit plan, because monthly care will not solve the absence of patches.
An honest caveat: a Magento store rarely fits the Basic package at 250 USD with a pool of 10 hours. Ten hours here can vanish on one deployment with regression tests. If somebody offers you Magento for 250 USD, ask what happens once the pool is used up. An hour inside the package costs 25 USD, an hour above it 40 USD.
Availability supervision is priced separately: it is a different service from a pool of hours for your requests. The Standard level starts at 240 USD. With Magento the Extended level at 650 USD usually applies: what gets monitored is not one address but queues, crons and background processes, and diagnosis during a critical event needs someone who knows the platform. Continuous 24/7 cover exists only on our highest SLA level. We take that difference apart in the article on technical support versus SLA.
Upgrade or migrate to another platform
The question is worth asking honestly, especially on a version without support. We will not talk you into migrating: leaving Magento is expensive, long and in half the cases ends with the same problems elsewhere. Three criteria instead.
First: calculate maintenance over a year, the subscription times twelve plus hours above the pool plus hosting. Only that number, not one month's invoice, compares with anything.
Second: check how many of your store functions are genuinely specific. Complex B2B price lists, several warehouses and a hard ERP integration mean Magento does the job you pay for. A simple catalogue with a payment means you pay for capabilities you do not use.
Third: ask whether your team can use this platform. Magento needs somebody on your side who knows the difference between an index and a cache. Without such a person, every change gets bought by the hour, a real part of the bill.
If two of three criteria favour Magento, stay and plan the upgrade. If none do, a migration conversation is justified, but that is a separate project, not an annex to a maintenance contract.
Start with a review of your version and technical condition. We check which version the store runs on, when it last received patches, whether queues and crons work, and hand over a list of things to do with an estimate in hours. Write through /en/sla-help-desk and we will say whether a pool of hours is enough, or availability supervision too.