Magento support, maintenance and version upgrades

Magento support services for stores that are already running: we take over maintenance, bring the store up to a supported version and keep it there under a support contract. Including when somebody else wrote the code.

Free consultation, no strings attached.

Trusted by market leaders

Scope of the service agreement

What Magento maintenance services cover

Maintenance is not a ticket inbox. It is monitoring, security patches and the tests that keep new work from breaking old work. We do not publish a standard support package, because the response times that matter are the ones written into your contract, not the ones printed on a website.

Application monitoring

New Relic and Sentry under constant watch, so an error surfaces from an alert rather than from a customer ticket or a question from your board.

Security patches

We follow Adobe security bulletins and apply patches on your version. When a version leaves support we say so plainly, instead of applying a patch that does not exist.

Contract and response times

Scope, service hours and response times are set in a contract for your store. We do not run one price list for everyone: a store with one integration and a store with five carry different risk.

Backups and restores

A backup is half the job. The other half is a tested restore, which we run, because a backup nobody has restored is an assumption rather than a safeguard.

Regression testing

Regression is the biggest enemy in e-commerce: new work breaks a feature that used to work. Automated tests take a real 10–15% of working time, and that is both their cost and their entire point.

Development in sprints

Maintenance and development share one backlog, so a fix does not compete with a new feature for the same week. A monthly report says what we shipped and what we moved.

Version upgrades

Magento upgrade: what actually gets upgraded

A Magento 2 upgrade moves you to a higher version of the same platform. Data, orders, customers and integrations stay where they are; what changes is the code underneath and what that code stands on: PHP version, database, queues, search. That is why an upgrade is rarely just raising a version number.

The cost is not set by the version you are going to, but by what you have added on top. A paid module with no release for the new Magento, a module written to order years ago, a template changed without an override layer: any one of those can cost more than the version jump itself. So the first step is an inventory, not an upgrade.

Our Magento upgrade services cover both editions, and the difference between them decides how long you can wait. Adobe's lifecycle policy, including extended support, applies to Adobe Commerce only: it is not available for the Magento Open Source code base, and Adobe's own policy page does not mention open source at all. So Adobe Commerce support buys you a longer runway; on open source the end of a version's support is the end.

If you are weighing a change of platform rather than a change of version, migrating from Magento to Shopify is a separate decision and a separate conversation. If you want to see the technical state of the store first, start with a Magento store audit.

Process

How we run an upgrade

01
Inventory of version and modules
We start with what you actually run: Magento version, PHP version, database, and the list of paid and custom modules. This step is what usually finds a module with no support for the new version, and that module, not the version, decides the cost of the whole upgrade.
02
Sizing the jump
Going from 2.4.6 to 2.4.9 is different work from leaving 2.4.4. We say how many jumps are needed, what cannot be skipped and what has to change on the server side.
03
Staging environment
The upgrade runs on a copy, never on production. A copy is where module conflicts and template changes become visible before a customer sees them.
04
Upgrade and fixes
Moving through the versions, fixing your own code where the API changed, and raising what has to move with it: PHP, queues, search.
05
Regression tests before release
We check cart, payments, integrations and order export. An upgrade that threw no console error and stopped the feed to your ERP is an outage, not a success.
06
Release and service window
Release in an agreed window, with a rollback plan. Afterwards we stay on raised monitoring, because the first days after a version jump are the one moment worth watching more closely.

Version lifecycle

Which Magento versions are still supported

Check your version in the admin panel or with bin/magento --version, then find it in this table.

Version	Released	Regular support until	Status
2.4.9	12 May 2026	31 May 2029	Current
2.4.8	8 Apr 2025	31 May 2028	Supported
2.4.7	9 Apr 2024	31 May 2027	Supported
2.4.6	14 Mar 2023	11 Aug 2026	Out of support
2.4.5	9 Aug 2022	12 Aug 2025	Out of support
2.4.4	12 Apr 2022	12 Apr 2025	Out of support
2.4.0–2.4.3	2020–2021	28 Nov 2022	Out of support

Extended support is for Adobe Commerce only. Adobe provides extended-support patches to Adobe Commerce customers and does not extend them to the Magento Open Source code base. So a store on Adobe Commerce 2.4.6 still has patches after August 2026, and a store on Magento Open Source 2.4.6 has had none since 11 August 2026. If you run open source, the date in the “Regular support until" column is the only one that counts, and nothing follows it.

Source: Adobe documentation, released versions and the software lifecycle policy. As of 27 August 2026. Adobe ships the next version in May, so the dates are worth re-checking after the May release.

What next for Magento? Mage-OS and Hyvä in 2026

Taking over from another agency

We take over stores we did not build

A substantial part of our maintenance work starts with somebody else's code. The reason is rarely an outage. More often it is rising cost against falling service quality, the technical debt of a platform that is four or five years old, or a lack of initiative: an agency closing tickets without a single suggestion about performance or SEO.

One thing about a handover we never change: code audit and maintenance takeover first, development only after that. The other order looks faster and ends with new work running on a platform nobody knows yet, and the first incident landing in release week.

The second thing is ownership. The code, the repository and the infrastructure have to be yours, whoever works on them. If they are not, that is the first problem to solve, and it gets solved before a change of agency rather than after.

Handover checklist

What to gather before changing agency

Eight items. A missing one does not block a takeover, but every gap is better known before signing than after.

Repository access
Code ownership
Server access
Vendor accounts
Module licences
Integration docs
Ticket history
Technical debt list

Changing your Magento agency: how to cut cost without losing quality

Questions we hear most often

Magento support and upgrades: FAQ

Do I have to upgrade Magento if the store works?

A store on an unsupported version works exactly until a vulnerability appears that nobody will patch on your version any more. An upgrade fixes nothing you can see today: what it buys you is access to security patches and to modules that stop shipping for older releases. If you are on a supported version, plan the jump calmly, on a yearly cycle.

What is the difference between an upgrade and a migration?

An upgrade moves you to a higher version of the same platform: data, integrations and template stay, the code underneath changes. A migration changes the platform, so you move the data and build the store again. An upgrade is always cheaper than a migration, and it is almost always the right answer while Magento still fits how you sell.

Does Magento Open Source get support for as long as Adobe Commerce?

No, and this is the most repeated error in writing about the Magento lifecycle. Adobe extended support is available to Adobe Commerce customers only and does not cover the Magento Open Source code base. For a store on Magento Open Source the only date that counts is the end of regular support in the table above, and after it there are no patches.

What blocks an upgrade most often?

A module with no release for the new Magento: a paid one whose author walked away, or one written to order years ago. Second in line is a template changed without keeping the override layer intact. That is why the module inventory is the first step rather than a formality: it, not the version number, decides the cost.

Will you take over a store you did not build?

Yes, and it is a substantial part of our maintenance work. We start with a code audit and taking over maintenance, and development only after that, so the business does not stall during the handover. The conditions are access to the repository and the infrastructure, and the code being yours.

What about Mage-OS and the future of Magento?

It is a fair question and we answer it separately, in the episode “What next for Magento? Mage-OS and Hyvä in 2026”, recorded in August 2026. The short version: your upgrade decision does not depend on how that plays out, because without a supported version you take none of those roads.

Check whether your Magento version is still supported.

Tell us which version you run and what you have added on top. We will come back with how many jumps separate you from a supported release and what decides the cost in your case.

Tomasz Grzemski, CEO Macopedia

Tomasz Grzemski

CEO Macopedia

Support, an upgrade, or taking over a Magento store

Tell us where you are and what you need. We come back with scope and questions, not with an off-the-shelf price.