Magento 2 Upgrade Service

Four to eight weeks from audit to go-live for most stores, with the rehearsal on staging taking the largest share. A store coming from 2.4.4 or 2.4.5 with a large extension stack sits at the long end; a store on 2.4.7 with a current theme at the short end. The audit in the first week gives you the dates for your store rather than the average.

Individually, after the audit, because the price depends on the starting version, the extension stack, the theme and the hosting rather than on the version number alone. The audit produces a fixed scope and a fixed price for the upgrade before any work on staging begins. There is no price list on this site because no two Magento stores start from the same place.

The upgrade runs to the end on staging first, so production is touched once, in a window you choose at your quietest hour. Most stores show a maintenance page for minutes rather than hours, and where the hosting allows a parallel environment the switch can be made with none at all. A tested rollback stands ready either way.

Usually, yes. 2.4.8 and 2.4.9 require PHP 8.4 and newer MySQL or MariaDB versions, and they use OpenSearch in place of Elasticsearch. The audit checks what your hosting can provide, and the infrastructure changes are rehearsed on staging with everything else so there is one go-live, not three.

Each one is checked against its vendor's release for the target version. Where a compatible release exists we install it; where the vendor has stopped, we replace the module or rewrite the feature and show the cost of each option; where two modules fight over the same class, we decide which one stays. Licences bought under a previous agency's account can usually be re-issued to you.

Yes. Magento 2 does not require intermediate stops, and each stop would cost a rehearsal of its own without fixing anything the final version does not fix. We plan one rehearsed jump from your current 2.4.x line to 2.4.9.

No, but the clock is visible. Adobe's standard and extended support for both lines has ended; Adobe Commerce customers receive security fixes only until 31 May 2027, and Magento Open Source stores receive no extended support at all. The upgrade is the same work it would have been a year ago, with a fixed end date now attached.

Often that is the right moment. If the Luma theme is what blocks the upgrade, replacing it costs less than making it compile on the new PHP, and Hyvä has been free and open source since November 2025. The audit says whether your extension stack makes the frontend change a small step or a large one, and the rehearsal covers both if you choose it.

Through your Cloud project's pipeline: the upgrade is rehearsed on an integration or staging environment, the services such as OpenSearch are updated in the environment configuration, and production is deployed in the window. Note Adobe's own deadline: from 1 June 2027 it no longer maintains Cloud environments that run an unsupported version.

Yes, both. The steps are the same; the difference is urgency, since Open Source lines receive no extended support once standard support ends.

A patch upgrade stays inside your line, for example 2.4.8-p2 to the latest 2.4.8 patch, and carries Adobe's security and stability fixes with few compatibility changes. A release upgrade moves the line, for example 2.4.6 to 2.4.9, and changes the runtime, the search engine and the extension requirements. Both are rehearsed on staging; the release upgrade simply has more to rehearse.

The store goes on a patch calendar: every Adobe security release tested on staging and applied inside the agreed window, the next May release planned a year ahead, and a monthly report of what changed. The regression suite built for the upgrade is kept, so the next release is a smaller rehearsal rather than a new project.