Partner
Magento upgrade services for stores that cannot afford a broken checkout.
Magento upgrade services move your store from an aging 2.4.x release onto a version Adobe still patches, with PHP, search, and the database updated alongside it. IWD runs every Magento 2 upgrade service as a planned project: a readiness assessment, the upgrade on a staging copy of your store, regression tests against your real checkout and integrations, and a cutover with a rehearsed rollback.
You’ll know every name on your project.
- 175+ years of combined ecommerce experience.
- Senior developers & designers, dedicated PM & CXM.
- Over a decade together for most of us. Average tenure is nine years.
- 15 people. Lean mean machine.
Joe M.Founder & CEO
Max D.CTO
Marcos A.Senior Project Manager
Yaro P.Lead Full-Stack Developer
Bohdan B.Senior Frontend Developer
A Magento version upgrade is due when your release line or your PHP runtime stops getting fixes.
Two clocks run on every Magento store. Adobe supports each 2.4.x release line for about three years from release, and PHP supports each runtime on its own schedule. The PHP clock is the one most stores miss: PHP 8.2 stops getting security fixes on December 31, 2026, and Magento 2.4.6 cannot run anything newer. Here is where each release line stands under Adobe's lifecycle policy.
| Release line | End of standard support | Adobe Commerce extended support | PHP on the latest patch | What it means |
|---|---|---|---|---|
| 2.4.4 and 2.4.5 | Ended April 12, 2025 and August 12, 2025 | Ended. Security-only fixes until May 31, 2027 | PHP 8.1, past end of life since December 31, 2025 | Upgrade now. Only isolated security fixes remain, and Adobe Commerce Cloud enforcement starts June 1, 2027. |
| 2.4.6 | Ended August 11, 2026 | August 31, 2027 | PHP 8.2 or 8.1. PHP 8.2 security support ends December 31, 2026 | Upgrade before the end of 2026. There is no supported PHP version for this line after that date. |
| 2.4.7 | May 31, 2027 | May 31, 2028 | PHP 8.3 or 8.2 | Plan the move during 2027, and run PHP 8.3 until you do. |
| 2.4.8 | May 31, 2028 | To be announced | PHP 8.4 or 8.3 | Supported. Stay on the latest patch and test 2.4.9 when your extensions are ready. |
| 2.4.9 | May 31, 2029 | To be announced | PHP 8.5 | Current release, published May 12, 2026. |
Dates from Adobe's Commerce lifecycle policy (updated September 18, 2026), Adobe's system requirements, and php.net. Adobe revises these pages, so check them before you commit budget. Every release line, patch, and Cloud deadline is in our Magento 2.4 end-of-support dates guide.
What our Magento 2 upgrade service covers, from the stack audit to the first weeks after launch.
A Magento upgrade fails when it is treated as a Composer command instead of a project. The version change itself is the small part. The work is in the services, extensions, theme, and custom code that depend on it, and in proving that checkout still works before customers find out it does not.
Version and stack assessment
Your exact release and patch level, plus every service the new version depends on: PHP, OpenSearch in place of Elasticsearch, MariaDB or MySQL, Valkey or Redis, RabbitMQ, Varnish, and Composer. Adobe's requirements change with each release line, so the stack is planned with the code.
Extension and theme compatibility audit
Every third-party module gets a status: a compatible release exists, it needs a patch, it should be replaced, or it can be retired. Retiring dead modules makes this upgrade and every later one smaller.
Custom code review
Class rewrites, preferences on core models, plugins, and observers are checked against the target version, along with deprecated APIs and PHP features your custom modules still rely on.
Luma, Hyva, and custom themes
Older themes break on new releases more often than core does. We update the theme you have, or, if the timing suits, pair the upgrade with a Hyva build so the storefront gets one QA cycle instead of two.
Upgrade on a staging copy
All of the work happens on a staging environment built from a production copy: the same modules, theme, configuration, and a recent data sample, so conflicts surface where customers cannot see them.
Regression testing on real flows
Checkout, cart, search, payments, tax, shipping, and your integrations are tested on staging, plus the B2B flows that matter to you, such as company accounts, quotes, tax exemption, and reorders.
Cutover and rollback plan
A written runbook for the deploy: the window, the order of steps, who is on the call, how success is checked, and a rollback that has been rehearsed before launch day.
Post-upgrade support
We watch errors, orders, and integrations closely after launch, fix what surfaces, and set up the patch routine that keeps the new version current until the next upgrade.
Want the theme rebuilt while the store is in testing anyway? Our Hyva theme development team plans both in one release. Not sure what is in your codebase? A Magento code audit maps it first.
Magento upgrade work backed by public client reviews.
Adobe Solution Partner
Shopify Plus Partner
BigCommerce Elite Partner
Salesforce Partner
Klaviyo Partner
Your Magento upgrade path depends on the version you start from.
The same target version means a different project depending on where the store is today. These are the starting points we see most often, and what each one usually involves.
From Magento 1
Magento 1 has no upgrade path to Magento 2. Moving off it is a rebuild of the store on Magento 2, with data, customers, orders, and URLs carried across, so it belongs to our Magento migration services team.
From 2.4.0 to 2.4.3
These releases left support in 2022. Expect a bigger PHP jump, extensions that need replacing rather than updating, and custom code written for APIs that have since changed. We usually plan it as one move to the current line with a longer staging phase.
From 2.4.4 or 2.4.5
Standard and extended support have ended, and only isolated security fixes remain until May 31, 2027. On Adobe Commerce Cloud, Adobe says it may suspend traffic to unsupported environments from June 1, 2027. The target is usually 2.4.8 or 2.4.9.
From 2.4.6
The most urgent group in 2026. Standard support ended August 11, 2026, and the newest PHP this line runs is 8.2, which stops getting security fixes on December 31, 2026. Magento Open Source stores should treat 2.4.6 as unsupported today.
From 2.4.7
Supported until May 31, 2027, with extended support for Adobe Commerce to May 31, 2028. Moving in 2027 on your own schedule costs less than moving under a deadline, and PHP 8.3 keeps you covered meanwhile.
From 2.4.8 to 2.4.9
A routine Magento version upgrade on a supported line. The main work is the move to PHP 8.5, which 2.4.9 requires, and confirming that every extension you run has a release for it.
Moving from Magento Open Source to the licensed edition at the same time? That is an edition change as well as a version change, covered by our Adobe Commerce migration team.
How long a Magento upgrade takes, and what drives the scope.
Two stores on the same version can need very different upgrades. The version gap matters less than what is built on top of it. These four factors decide most of the timeline, and the readiness assessment measures each one before we quote.
How far you are jumping
One release line is a contained project. Three lines and two PHP versions is a larger one, because each step changes dependencies your modules rely on.
How many extensions you run
Third-party modules cause more upgrade failures than core does. Forty extensions with a dozen abandoned by their vendors is a very different scope from ten maintained ones.
How much custom code overrides core
Plugins and observers usually survive a release. Class rewrites and preferences on core models often do not, and they are where most of the engineering time goes.
Theme, integrations, and hosting
A custom Luma theme, ERP and payment integrations, and Adobe Commerce Cloud or on-premise hosting each add testing and deploy steps that have to be planned in.
Every upgrade is scoped to your store, with a firm, itemized quote after the assessment and no open-ended hourly estimate. For a breakdown of where upgrade budgets go, read our guide to the cost of upgrading Magento.
Magento and Adobe Commerce stores we upgrade and keep current.
An Adobe Commerce and PHP upgrade sequenced with a hosting move and an ERP integration for BinMaster, annual Magento and PHP upgrades for Purdue Extension, and release-by-release upgrades with B2B regression testing for School Fix.
BinMaster
An Adobe Commerce rebuild for a global level-measurement manufacturer, with a modernized storefront and integrations.
Purdue Extension
A Magento storefront for Purdue Extension's education and resource catalog.
SchoolFix
An Adobe Commerce B2B store for a school-supplies distributor, with DCKAP integration and Yotpo reviews.
Our job is to get you promoted.
You're going to love coming to work. Think of us as an extension of your team, here whenever you need us. Our mission is simple: your store wins, and so do you.
A Magento upgrade service run by the team that also patches and supports it.
We have been building on Magento since 2008, and upgrades are routine work for our support clients: one B2B store has moved release by release without ever replatforming, and another is upgraded every year ahead of Adobe's lifecycle dates. The engineers who scope your upgrade are the ones who run it, and they stay on after launch.
Staging first, every time
No upgrade or patch reaches production before it has run on a copy of your store with the same modules, theme, and configuration.
Senior engineers, no handoffs
The people on the assessment call are the people who resolve your extension conflicts and run the deploy.
B2B and integrations tested
Quotes, company accounts, tax exemption, ERP sync, and payment flows are on the regression list, because they are what breaks quietly.
Honest about upgrade or replatform
If years of workarounds mean a rebuild is the better investment, the assessment says so, and if a simple upgrade will do, we do not sell you more.
Every Magento upgrade starts on a staging copy of your store, never on production.
The process is the same whether you are moving one release line or three. We find the risk first, agree the plan, do the work where it cannot hurt sales, and touch production once, with a way back ready.
Readiness assessment
We review your version and patch level, PHP and services, extension list, custom modules, integrations, and hosting, then recommend a target version and tell you what the upgrade will touch.
Scope and plan
You get a firm, itemized quote and a sequenced plan: what gets upgraded, replaced, or retired, the deploy window, and the rollback path. Nothing starts until you agree to it.
Upgrade and test on staging
We upgrade core and the stack, resolve extension, theme, and custom code conflicts, and regression-test checkout, integrations, and your B2B flows against real catalog data.
Cutover and hypercare
We deploy in your lowest-traffic window with the rollback ready, verify the live store, and stay close through the first weeks before handing over to a normal patch cycle.
Between upgrades, our Magento support services keep the store on the latest security patch using the process in our Magento security patching playbook. Need engineers inside your own team instead? You can hire Magento developers from us directly.
What merchants ask before booking a Magento upgrade.
The questions we hear most on the first call. If yours isn't here, just ask.
What do Magento upgrade services include?
A Magento upgrade service covers everything the new version touches: an assessment of your release, PHP, and services such as OpenSearch and MariaDB, a compatibility audit of every extension and the theme, a review of custom code that overrides core, the upgrade itself on a staging copy, regression testing of checkout, integrations, and B2B flows, a deploy with a tested rollback, and support after launch.
How long does a Magento upgrade take?
It depends on how many release lines you are jumping, how many third-party extensions you run, and how much custom code overrides core. A move between supported lines on a clean codebase is a contained project, while a store several releases behind with heavy customization needs a longer staging and testing phase. The readiness assessment gives you a real timeline before any work starts.
Which Magento version should we upgrade to?
Usually the newest release line that every extension you depend on supports. As of November 2026 that means 2.4.9, which requires PHP 8.5 and has standard support until May 31, 2029, or 2.4.8 on PHP 8.4, supported until May 31, 2028, if a critical extension is not ready for PHP 8.5 yet.
What happens when PHP 8.2 reaches end of life?
PHP 8.2 stops receiving security fixes on December 31, 2026. Magento 2.4.6 runs on PHP 8.2 or 8.1 only, so a 2.4.6 store cannot move to a supported PHP version without a Magento upgrade. Adobe notes that PCI compliance is at risk on an end-of-life PHP version. PCI is assessed by the merchant, so confirm with your security assessor.
Can you upgrade Magento without taking the store down?
The store stays live while all of the upgrade work happens on a staging copy. The deploy itself runs in a short maintenance window at your lowest-traffic time, with a rehearsed rollback ready, so customers see a brief planned pause rather than an outage.
Do you upgrade both Magento Open Source and Adobe Commerce?
Yes. Both editions ship on the same version numbers. Adobe Commerce customers get an extra year of extended support on 2.4.6 and 2.4.7, and Adobe Commerce Cloud adds enforced upgrade dates: June 1, 2027 for 2.4.4 and 2.4.5, and June 1, 2028 for 2.4.6 and 2.4.7. Open Source stores should plan around the end of standard support.
How do you quote a Magento upgrade?
From the readiness assessment, not from a guess. The quote reflects your current version, the target version, the extension and integration list, the theme, and how much custom code overrides core. You get a firm, itemized quote and a timeline before work begins.
What happens after the upgrade?
We monitor errors, orders, and integrations closely through the first weeks, fix anything that surfaces, and set up a patch routine so the store stays on the latest security release for its line. Many clients keep the same team on a support retainer, so the next upgrade is planned rather than urgent.
Tell us which Magento version you run and what you are worried will break.
Send us your version, your hosting, and your extension list if you have it. We will check them against Adobe's support dates and come back within one business day with a recommended target version, the main risks, and the next step toward a firm quote.