To a supported release, rehearsed on staging and deployed with the shop open.
Point-release upgrades and security patching for Magento Open Source, Adobe Commerce and Mage-OS stores, planned around Adobe's support dates rather than against them. For merchants whose release has lost support, or is about to, including stores still on Magento 1. You get a written plan and estimate once we have examined the store.
The three things merchants say before an upgrade.
Our agency says the upgrade is a rebuild and it will take months.
Usually it is not. Most upgrades are a module-by-module job on staging, with the shop open.
We have been putting off the upgrade because last time it broke checkout.
The last one was probably deployed without a rehearsal. A staging copy and a tested rollback are what make the next one uneventful.
We got an email saying our PHP version is end of life. What does that mean for us?
PHP 8.1 lost security fixes on 31st December 2025, and 8.2 does on 31st December 2026. PHP moves with the Magento release, so it is one plan, not two.
Six things, every time, whether the jump is one release or four.
The longest-supported release your modules and PHP can move to, recommended in writing with our reasons.
A complete copy of your store is upgraded first, and checkout, payments, search, feeds and integrations are tested on it.
Each module and each piece of custom code is checked against the new release, then updated, replaced or removed.
Customers see the same store. A Hyvä theme stays on Hyvä; a Luma theme stays on Luma, brought up to date.
The plan states the PHP version you will be on afterwards; search, cache and queue services are upgraded with it.
Backups are taken, the rollback is tested in advance, and we deploy at a quiet time that you choose.
The same five steps for a single patch release and a four-release jump, with the store open throughout.
Send us the store address. A senior engineer reads its release, support status, PHP, headers, hosting and any sign of a hijack.
Within two working daysRelease, patch state, PHP, hosting, every module and every custom change, read from the code and the server.
Within two working days of accessA full copy is upgraded, incompatibilities fixed, retired modules replaced and the money paths tested end to end.
Most of the projectYou place orders, check the admin and try your exports on staging. Nothing goes live until you have seen it work.
Before the deploymentA rehearsed sequence at a quiet hour, backups first, then logs, indexers, feeds and payments monitored in the days after.
A quiet hour agreed with youAdobe's calendar for each release line. Open Source stores lose fixes when standard support ends; Adobe Commerce customers have the extended dates on the right. Mage-OS follows its own calendar.
Dates read from Adobe's lifecycle policy and released versions pages on 31st October 2026. APSB26-138 (September 2026) lists Open Source 2.4.6 as affected, with no fix. PHP 8.1 reached end of life on 31st December 2025 and 8.2 does on 31st December 2026 (php.net), which Adobe says puts PCI compliance at risk.
We price the work, not the clock.
The number of releases to cross, the modules and the custom code decide the work, so we examine the store first and then give you a written plan and estimate. If the detail changes what is needed, we tell you before the work is done, not afterwards. Security patching between upgrades can be ad hoc, invoiced at the end of the month, or part of a monthly retainer.
A Magento store with a Hyvä storefront, kept fast and secure through every change: the main content loads in 1.1 seconds on a phone for real customers.
Core Web Vitals, real-user data (Chrome UX Report), mobile, 28 days to 31st October 2026. Marks show Google's thresholds.
… We no longer feel like we are in perpetual development. We are growing and improving and Rowan has been key to this success. …
Decades of collective experience across Magento 1, Magento 2, Adobe Commerce, Hyvä and Shopify. Very little about your store will be new to us.
You deal directly with the founder. No juniors learning on your store and no account managers between you and the people doing the work.
Small stores and large ones, described in their owners' words. The reviews are quoted on this site word for word.
The one that gives you the longest period of support before the next decision, as long as your extensions and PHP can follow. At the time of writing that is 2.4.9, supported to 31st May 2029, with 2.4.8 (to 31st May 2028) as the fallback where an extension you depend on is not ready. Every module is checked against the target before we recommend one.
You need a dated plan now; the upgrade itself can follow. Adobe no longer ships fixes for 2.4.6 and below on Magento Open Source, so until the upgrade lands we backport the relevant security patches ourselves and keep the edge in front of the store hardened. That is a bridge, and we say in writing how long it should be.
Yes. Magento 1 to Magento 2 is a larger job than a point-release upgrade, because the two are different applications: the store is rebuilt on Magento 2 and the catalogue, customers and orders are migrated into it. We do this regularly, and we can keep your Magento 1 store patched and trading in the meantime. See Magento 1 to Magento 2 migration.
Some will need updating and a few replacing; staging is where we find out which, before your customers do. Every module and piece of custom code is checked against the target and listed in the plan with what we propose. Modules with no supported version are called out.
No. The whole upgrade is rehearsed on a staging copy of your store first, so the live deployment is a known sequence carried out at a quiet hour you choose, with a tested way back if anything looks wrong. Any maintenance window is minutes, agreed in advance, and customers keep browsing and buying either side of it.
It moves with the release. PHP 8.1 lost security fixes on 31st December 2025 and 8.2 loses them on 31st December 2026, which Adobe says puts PCI compliance at risk. The plan names the PHP version you land on, and the server moves with the code.
It depends on the jump, the number of modules and the amount of custom code. A straightforward upgrade can be planned, rehearsed and deployed within a week when it needs to be; four releases with thirty modules takes longer. The written plan gives you dates before you commit.
It is priced as a project once we have examined the store, because the number of releases to cross, the modules and the custom code decide the work. You get a written estimate before anything starts, and payment is usually spread across the project. The first look and the estimate are free.
Often it is the efficient moment, because the frontend has to be tested against the new release anyway. If your store still uses Luma, we will price the upgrade with and without a move to Hyvä so you can compare.
Give us the address and we will read what the store already shows the world: release, support status, PHP, headers, hosting and any sign of a hijack. One page, by email, within two working days. Nothing is accessed or tested.
What we would do first. Apply the outstanding security fixes, then plan the upgrade to a supported release.