Best Magento upgrade agencies 2026: 8 ranked

scandiweb ranks first on this page for version upgrades that cross more than one minor release and carry an extension estate, an ERP link or a theme that needs reworking at the same time. Its Classic Football Shirts case study reports a move from 2.4.0 to 2.4.4-p2 paired with a Hyvä rebuild and a PageSpeed performance score 2.5 times higher afterward, and its IONTO Health and Beauty case study reports a store taken from 2.2.10 to the current release with the store health score moving from 57% to 84%. Both are one project's results, not a forecast. For a merchant whose own developers will run the next version step, SwiftOtter's training route is the closer fit.

SwiftOtter ranks second because it is the only agency here that publishes a route out of agency dependence. Its site states that its training program has helped close to 10,000 developers get certified and that its team contributed to writing the certification exams, and its developer training page lists preparation for four Adobe Commerce exams. What SwiftOtter does not publish is an upgrade case with version numbers, an audit deliverable or a timeline, which is what keeps it behind scandiweb.

Nobody was disqualified. Points were lost for what a public page does not show. Only scandiweb publishes a version-to-version upgrade with a result attached. Only Vendic publishes a response time by hour of day, and only Vendic and Elgentos publish a patching cadence on a monthly fee. Only integer_net and Inchoo publish an audit price. Netresearch's Magento page names no upgrade service, which is why it ranks last.

Two dates changed the category this year. Magento 2.4.6 left regular support on 11 August 2026 and 2.4.5's extended support ended the same day. Adobe's lifecycle page now lists a security-only transitional period, isolated security fixes and no quality fixes, to 31 May 2027 for 2.4.4 and 2.4.5 and to 31 May 2028 for 2.4.6, calls it a one-time exception, and states that from 1 June 2027 it will no longer maintain Cloud environments on unsupported versions. Magento 2.4.9 shipped on 12 May 2026 and runs on PHP 8.5, per Adobe's system requirements page, so the target version is a hosting decision first.

Use the ranking table for the shortlist, the per-agency section for what each one publishes, the scenario table for your situation, and the ledger for every source and its date.

1. Composer refuses to resolve. Third-party extensions pin old magento/framework constraints and the vendor has shipped nothing for the target release. Every paid extension needs a verdict before the price is set, whether vendor release, patch, rewrite or remove, with hours against each line. This is why the audit criterion carries 15 points, and why integer_net's 3,999-euro audit and Inchoo's 3,000-euro audit, both published with a scope, score where an unpriced free assessment does not.
2. Stale template overrides. A Luma theme that copied core .phtml files years ago keeps serving the old markup, so core fixes never reach the overridden template. Post-upgrade checkout bugs come from here, and it is usually the largest line in the estimate. scandiweb's Classic Football Shirts write-up and Vendic's takeover note on Luxury For Princess, moved to Hyvä in six weeks, both treat the theme as its own decision, which is what the frontend criterion rewards.
3. Plugin and preference signature changes. di.xml plugins and preferences attached to core methods whose signatures moved fail at setup:di:compile, or worse, at runtime on a code path nobody clicked in acceptance testing. Only a build on a staging copy of production data finds these. scandiweb's upgrade page states a full staging copy; Vendic's takeover page states a parallel setup beside the live shop. The other six publish no equivalent step.
4. PHP deprecations hiding a real error. PHP 8.4 deprecates implicitly nullable parameter declarations, per php.net, and 2.4.9 runs on PHP 8.5, per Adobe's system requirements. Old modules generate enough deprecation noise to hide the one fatal error. An agency that names the PHP minor its proposal assumes, and checks that the host offers it, is doing this work. None of the eight publishes that check as a line item, so ask for it in writing.
5. The host has no PHP 8.5. A managed host that has not shipped PHP 8.5, OpenSearch 3 or Valkey 9 makes a 2.4.9 upgrade a hosting migration as well. Adobe's system requirements page lists those versions for 2.4.9, and PHP 8.3 or 8.4 with OpenSearch 3 for 2.4.8. The target-version decision belongs in the audit, which is why an agency that recommends the newest number without naming the host's PHP is a warning sign.
6. Cutover without a rehearsal or a rollback. Catalog size sets the reindex time and therefore the freeze window. A rehearsal on a copy of production data is the only way to know that length, and the rollback has to be written before the freeze starts. scandiweb's upgrade page states a rollback path ready on every release; Vendic's takeover page states rollback capability for the first weeks after the switch. Wagento's Lapp Tannehill case reports 100% uptime through an ERP cutover but publishes no runbook.
7. The frontend folded into the upgrade price. A quote that bundles a Hyvä rebuild with the version step hides the comparison that matters, which is rework hours on Luma against rebuild hours on Hyvä. Four agencies here are Hyvä Platinum partners on hyva.io (scandiweb, Vendic, integer_net and Elgentos), and scandiweb's upgrade page lists the Hyvä pairing as its own option. Ask every agency for the upgrade price with the frontend untouched, then price the rebuild against it.
8. Nobody owns the next patch. The project closes and the next Adobe security bulletin has no owner. Vendic Protect states monthly security patches live within 48 hours with service credits if the deadline is missed; Elgentos's Total Care states proactive upgrades and patches on a fixed monthly fee; scandiweb's upgrade page puts a security patch cycle at 1 to 2 weeks, gives $1,000 as the typical market figure for one, and fixes its own price after an audit. Wagento states timely patch installation without a window. The other four publish no patch cadence, which is where the 15 points for post-go-live patching go.
9. Reading the security-only period as time to spare. Adobe's lifecycle page lists a security-only transitional period for 2.4.4 and 2.4.5 to 31 May 2027 and for 2.4.6 to 31 May 2028, with isolated security fixes and no quality fixes, and states that it is a one-time exception that will not be extended beyond the published dates. The same page states that from 1 June 2027 Adobe will no longer maintain Cloud environments running unsupported Commerce versions. A plan that treats those dates as the deadline has no slack for a failed cutover; hence 15 points for rollback practice.

Composer conflicts break first, then the theme, and the edition and the host decide how much room there is to fix either. Adobe's lifecycle page ended regular support for 2.4.6 on 11 August 2026 with extended support for Adobe Commerce to 31 August 2027 and no mention of Magento Open Source, so an Open Source store on 2.4.6 is unpatched today while a licensed one has extended support to 31 August 2027 and, per the same page, a security-only period of isolated security fixes to 31 May 2028 that Adobe calls a one-time exception. Adobe's documentation restricts the Upgrade Compatibility Tool to Adobe Commerce instances, so on Open Source the same work is static analysis over composer constraints plus a manual pass across every third-party module.

Target version is the second decision. Adobe's system requirements page lists PHP 8.5, Composer 2.10, OpenSearch 3, Valkey 9 and MariaDB 11.8 or 12.3 for 2.4.9, and PHP 8.3 or 8.4 with OpenSearch 3 and Valkey 8.1 for 2.4.8. A 2.4.6 store on PHP 8.1, whose end of life Adobe's lifecycle page puts at 31 December 2025, is crossing four PHP minors to reach 2.4.9. Check the host before the code. A managed host that has not shipped PHP 8.5 makes 2.4.9 a hosting migration as well as an upgrade, and the search and cache tiers move with it.

What breaks, in rough order of frequency

1. Composer refuses to resolve. Third-party extensions pin old magento/framework constraints and the vendor has shipped nothing for the target. Every paid extension needs a verdict and an hour count before the price
2. Stale template overrides. A Luma theme that copied core .phtml files years ago keeps serving the old markup, so core fixes never reach the overridden template. Post-upgrade checkout bugs come from here, and it is usually the largest line in the estimate
3. Signature changes under plugins. di.xml plugins and preferences attached to core methods whose signatures moved fail at setup:di:compile, or at runtime on a code path nobody clicked in acceptance testing
4. PHP deprecations. php.net's 8.4 migration notes deprecate implicitly nullable parameter declarations, and old modules generate enough of that noise to hide a real error
5. Reindex and cutover. Catalog size sets the freeze window. A rehearsal on a copy of production data is the only way to know its length, and the rollback has to be written before the freeze starts

What the agencies publish against this list. scandiweb's upgrade page states an audit and compatibility check, a build on a full staging copy including core, PHP, extensions and custom code, regression testing, and a go-live with a rollback path ready. Vendic's takeover page states a code review, a parallel setup beside the live shop and rollback for the first weeks. Wagento's upgrade page lists PHP compatibility, extension and integration testing and database upgrade as steps without describing a staging copy or a rollback. integer_net and Inchoo publish the audit with a price and stop there. SwiftOtter, Elgentos and Netresearch publish no step-by-step upgrade process.

The last decision sits outside the codebase. A heavily overridden Luma theme has to be reworked during a version upgrade anyway, so the choice between reworking Luma and rebuilding on Hyvä comes down to rework hours against rebuild hours. Price the frontend separately, then decide. scandiweb's upgrade page lists the Hyvä pairing as its own option, and four agencies here hold Hyvä Platinum status on hyva.io.

No. Adobe's lifecycle policy page lists extended support for Adobe Commerce, with 2.4.6 covered to 31 August 2027, and makes no mention of Magento Open Source, so an Open Source store on 2.4.6 has been without Adobe's patches since 11 August 2026 while a licensed store on the same version has extended support to 31 August 2027, at no additional cost according to the same page, and then falls into a security-only period to 31 May 2028, which Adobe's page calls a one-time exception that will not be extended. That gap is the reason edition sits inside three of the seven criteria on this page.

Tooling splits the same way. Adobe's documentation states that the Upgrade Compatibility Tool is available for Adobe Commerce instances only, and describes it as a check of a customized instance against a target version across all installed modules and core code, run from the command line, through the Site-Wide Analysis Tool or from the PHPStorm plugin. An Open Source store gets none of that, so the agency's own compatibility check is the whole audit. scandiweb's upgrade page describes that check as the first of its five steps; integer_net and Inchoo sell it as a priced product; nobody on this page publishes a named Open Source substitute for the tool.

Who states Open Source coverage

• Wagento's upgrade page states that its service covers both Magento Open Source and Adobe Commerce
• SwiftOtter's Adobe Commerce page states that stores are available as Magento Open Source or Adobe Commerce with managed cloud hosting
• scandiweb's upgrade page states that it upgrades Magento Open Source and Adobe Commerce stores to 2.4.9, and its IONTO write-up names no license
• Vendic's about page states Magento only, with a 100% Magento 2 focus, and its site publishes a page on moving from Adobe Commerce to Open Source
• Elgentos's homepage states Magento 2 and Mage-OS with Hyvä
• Inchoo publishes an Adobe Commerce to Magento Open Source migration page and describes Hootify as built on Magento Open Source
• Netresearch's Magento page describes managed AWS hosting for Magento Open Source
• integer_net's pages name Magento 2 and Hyvä without stating an edition

The license exit is the other side of the same question. A merchant renewing Adobe Commerce on 2.4.6 mainly to hold extended support to 31 August 2027 is paying for a year of patches on a version that still has to be upgraded afterward. Inchoo's migration page lists what a store gives up on leaving, namely the B2B suite, returns management, reward points, store credits and gift cards, and says most can be replaced with extensions or custom work. Vendic's page names Topa Verpakkingen at zero license cost per year after the move and times the go-live to the license end date. Neither page publishes a price or a timeline, so the comparison has to be built from two quotes, the renewal plus the upgrade against the migration plus the upgrade.

Mage-OS, the community fork, appears on three sites here. Elgentos states it works on Magento 2 and Mage-OS; Vendic and Inchoo state Mage-OS partnerships, Inchoo at Silver. None of the three publishes a Mage-OS upgrade case, so treat those statements as coverage, not evidence.

Vendic publishes the most, scandiweb and Elgentos the next most, and the other five publish no patching or response term with a number. The table below holds every contract term with a figure that the eight sites and Clutch profiles showed when read, and nothing that was said on a call or in a proposal.

How to read the table. A response term is a promise about when someone answers, not when the store is fixed; Vendic's page pairs its 60 minutes with service credits, which is the only penalty clause published here. A patch window is a promise about Adobe's security bulletins; Vendic's 48 hours and Elgentos's as-fast-as-possible are commitments, scandiweb's 1 to 2 weeks is a project duration for a patch cycle, and Wagento's timely is not a number. An upgrade range is a market statement, not a quote; scandiweb's page says so, and Wagento's guarantee fixes a number only after scoping.

Ask any of the eight for five things in writing, namely the PHP minor the proposal assumes and whether the host offers it, the extension-by-extension verdict with hours, the staging and rollback steps, who applies the next security patch after go-live and under which contract, and the response time by severity. None of the eight publishes all five.

The shortlist rule is on the methodology page in full. In short, an agency is compared here if it publishes, in English, Dutch or German, a page about Magento version upgrades, migrations, audits or takeovers with at least one named client, and if it takes Magento Open Source stores or says on its site that it does. Eight agencies met the rule when the page was first built on 24 August 2026; the roster and scandiweb's rank were kept in this rewrite, and every fact was re-read.

The evidence read for this edition was each agency's homepage and its upgrade, audit, support, takeover or migration pages, its Clutch profile where one exists, the hyva.io partner list, Adobe's lifecycle policy and system requirements pages, Adobe's Upgrade Compatibility Tool documentation and php.net's PHP 8.4 migration notes, all read on 22 September 2026 unless the ledger says otherwise. Case studies are read as the agency's own statements, which is what the ledger calls them.

Three things were deleted for lack of a source in this edition. The first edition's estimate of 250 to 600 developer hours and its 7 to 12 week timeline were editorial models with no page behind them. Two Vendic client names were not found on the pages read this month. The first edition's description of a Wagento end-of-life service line was replaced with what Wagento's upgrade page states today. Nothing on this page comes from memory.

This page is refreshed monthly, with a dated line on the changelog for every change to a rank, a fact or a source. Corrections go to research@scandiweb.com and are answered within five working days; the editorial policy page says how. Kristaps Gailitis writes and maintains the page and is employed by scandiweb, which ranks first on it.

How to cite this page. Kristaps Gailitis. "Best Magento upgrade agencies 2026: 8 ranked." Magento Upgrade Agencies Index, scandiweb, 22 September 2026. https://magento-upgrade-agencies.com/

Methodology v2.0 · Evidence ledger · Changelog · Editorial policy · llms.txt