Most Magento upgrades that run over budget fail for one reason. It is not the core upgrade. It is a third-party extension nobody checked. A Magento extension compatibility audit is the step that prevents this, and most merchants skip it.
The pattern repeats constantly. First, a merchant approves a quote based on a version jump. Then, two weeks in, a payment extension turns out to be three versions behind. Meanwhile the vendor has gone quiet. Worse still, a previous agency forked the checkout it powers.
As a result, an upgrade becomes an upgrade plus a checkout rebuild. Nobody enjoys the conversation about who pays for that.
Adobe tests core against core. Every release goes through heavy QA. Therefore the core upgrade path between supported versions works well.
However, Adobe cannot test your specific setup. Your store might run forty third-party modules. It might also carry six custom modules from three different agencies. On top of that, your theme probably overrides templates nobody expected.
Adobe is clear about where the effort sits. In its guidance on upgrade scope, Adobe notes that checking custom modules is the most time-intensive part of any upgrade. In addition, releases can contain backward-incompatible changes. Adobe documents these as major change highlights and a minor change reference.
The current cycle makes this urgent. For example, Adobe Commerce 2.4.9 dropped PHP 8.2 support. It also replaced Laminas with a native MVC layer. Furthermore, it raised the database requirement to MySQL 8.4 or MariaDB 11.4.
These are not cosmetic changes. Consequently, any extension that imports Laminas classes will need work. You want to know which ones before you commit to a date.
You cannot audit what you have not listed. Unfortunately, the list is rarely where you expect. Modules hide in three places.
Start with your lock file. It records what is actually installed, not what someone requested:
composer show --installed
This is where the surprises live. Modules copied straight into app/code are invisible to Composer. As a result, they never appear on a vendor compatibility list. So enumerate them directly:
ls -1 app/code/*/*
bin/magento module:status
Next, compare the two outputs. Any module in module:status that is missing from Composer is an orphan. Treat every orphan as unsupported until you prove otherwise.
Adobe removed all vendor bundled extensions in 2.4.4. Vendors still support them on the Marketplace. However, you must update the package dependencies in your composer.json first. Adobe advises contacting the vendor for the correct package name.
Adobe ships a free tool for this exact problem. Surprisingly, most merchants have never heard of it.
The Upgrade Compatibility Tool analyses every installed module against a target version. Then it returns a list of critical issues, errors and warnings.
Install it with Composer:
composer create-project magento/upgrade-compatibility-tool uct --repository https://repo.magento.com
chmod +x ./uct/bin/uct
These are the commands worth knowing, per Adobe’s documentation:
upgrade:check — analyses all modules against your target versioncore:code:changes — compares your install against a clean one, which finds modified core filesdbschema:diff — shows schema differences between two versionsgraphql:compare — compares two GraphQL endpointsrefactor — fixes a small set of issues automaticallyPay close attention to core:code:changes. Modified core files are the worst debt on any Magento store. Upgrades overwrite them without warning. Moreover, the resulting breakage is hard to trace. So deal with these first.
Here is the catch most articles omit. The tool works on Adobe Commerce instances only.
You need valid Adobe Commerce access keys in your auth.json. Without them, the composer create-project command simply fails. Adobe lists the full access key and system requirements, including 2GB of RAM and a Node.js dependency.
Are you on Magento Open Source? Then you cannot use it. Nevertheless, you still need the audit. In that case, Steps 1, 3, 4 and 5 happen manually. Budget accordingly. Above all, be sceptical of any Open Source quote that assumes automated checking.
An inventory is a list. By contrast, an audit is a classification. Every module belongs in one of six groups.
Compatible. The vendor has released a version for your target. Also, you verified it in the package rather than on a web page. Effort: update and regression test.
Update pending. The vendor is active and has promised a compatible release. However, it has not shipped yet. Effort: track it, with a fallback date.
Abandoned. No release in over a year. Alternatively, no vendor response at all. Effort: fork, replace or remove.
Duplicated. Functionality overlaps another module. This happens often on stores that have changed agencies. Effort: consolidate.
Removable. Someone installed it for a campaign years ago. Nobody uses it now. Effort: removal, which is the cheapest outcome available.
Custom. Written for you, so there is no vendor to ask. Therefore you must check it line by line. Effort: code review and remediation.
That removable group matters most. On a five-year-old store, many extensions serve no business purpose. Consequently, every removal cuts testing effort, risk and cost.
Adobe’s upgrade scope documentation explains the Marketplace compatibility policy. Listed extensions must support the latest release within 30 days of the GA date.
That is a meaningful guarantee. For this reason, source through the Marketplace where you can. Extensions bought from a vendor site carry no such promise.
“Compatible with Magento 2.4.x” is marketing copy. It is not a version constraint. Above all, it is not testable.
The testable version sits in the package. So download the release and open its composer.json. Look at the require block. It holds the real constraint against magento/framework. If your target version falls outside it, the product page is simply wrong.
Then test properly. Adobe’s Cloud upgrade guidance recommends a new integration branch with extensions disabled. After that, re-enable and upgrade them deliberately.
This sequence matters. It separates core failures from extension failures. In practice, that is the difference between a two-hour diagnosis and a two-day one.
Every Magento extension compatibility audit finds at least one. You have three options. Cost them over three years, not three weeks.
Fork and maintain. This is cheapest today and dearest later. You now own code you did not write. Furthermore, you own it at every future upgrade. It suits small modules. However, it is a poor choice for payments, checkout or tax.
Replace it. This costs more upfront, including data migration. On the other hand, it ends the liability. Usually it is right for anything business-critical.
Remove the feature. Ask whether it still earns its place. Sometimes it does not. Clearly, this is the cheapest outcome.
One decision goes wrong repeatedly. Merchants fork a payment extension because it looks cheaper this quarter. In reality it is not cheaper. The cost simply arrives later, in a worse form.
Running Hyvä? Then compatibility has a second dimension.
A module can suit your target Magento version and still render nothing. That happens because it ships Luma templates with no Hyvä equivalent.
Fortunately, Hyvä maintains compatibility modules for many common extensions. A tracker shows what is covered. So check your list during the audit, not during the build.
Is a module missing? Then you can write a compatibility module, replace the extension, or fall back to the Luma version. Each carries a different cost, and each belongs in the estimate.
Also note the version detail. Hyvä states requirements at patch level, not minor version level. Being on 2.4.7 differs from being on a specific 2.4.7 patch. The Hyvä getting-started documentation confirms what your version needs.
A classified list is only half an audit. The useful output attaches effort to every entry.
Adobe makes the same point in its upgrade implementation guidance. A good analysis saves time and limits surprises. Its output should be a detailed checklist covering all dependencies.
So estimate per extension. Then add contingency for the custom modules, because they are always least predictable. As a result, you get a number that survives the project.
Record eight things per module. These are: name, version, source, vendor status, verified compatibility, classification, chosen action and effort in hours.
A healthy entry reads like this. vendor/module-name, version 2.1.4, from the Marketplace, vendor active, compatibility confirmed in composer.json, classified compatible, action is update and test, two hours.
An unhealthy one reads differently. vendor/other-module, version 1.0.9, found in app/code, no release since 2023, not compatible, classified abandoned, action is replace, sixteen hours.
Finally, keep it portable. Any agency should be able to use it, including one that did not write it.
Run it before you request quotes. Do not run it after you accept one.
The audit makes quotes comparable. Three agencies pricing the same classified list produce numbers you can weigh. Otherwise you get three guesses about a codebase nobody examined.
The timing pressure is real. Support for Adobe Commerce 2.4.7 ends on 9 April 2027, per Adobe’s release version documentation. Meanwhile 2.4.8 runs to 11 April 2028. Merchants on 2.4.6 are already past their date.
Cloud customers face another deadline. Adobe’s software lifecycle policy states that from 1 June 2027 it will stop maintaining Cloud environments on unsupported versions. Additionally, it reserves the right to decommission them.
For a store with 25 to 60 extensions, the audit takes three to five working days. Compare that to an upgrade lasting weeks. Clearly, the ratio is good.
Ribog delivers a Magento extension compatibility audit as a standalone engagement. It sits separate from any upgrade work.
You receive a per-extension breakdown. It covers current version, source, vendor status, verified compatibility, licence position and our recommendation. Every entry carries an effort estimate.
We run Adobe’s Upgrade Compatibility Tool where your licence allows it. Otherwise we run the manual equivalent. Therefore Open Source merchants get the same depth, not a thinner deliverable.
Running Hyvä? Then we check every extension against the compatibility module tracker in the same pass. Consequently the frontend cost lands in the estimate, not in week three.
The audit is deliberately portable. You can take it to three agencies and get comparable quotes. Its recommendations do not depend on us doing the work. Honestly, if your codebase is healthier than you feared, we would rather tell you.
Talk to us about an extension compatibility audit, or read about our Magento and Adobe Commerce development services.
How long does a Magento extension compatibility audit take?
Usually three to five working days for 25 to 60 extensions. However, stores with heavy undocumented customisation take longer. In those cases, the inventory phase becomes investigative work.
How do I find extensions installed outside Composer?
Enumerate app/code directly. Then cross-reference it against bin/magento module:status and your Composer packages. Anything in one list but not the other is an orphan. Orphans break upgrades.
Can I use the Upgrade Compatibility Tool on Magento Open Source?
No. Adobe documents that the tool works on Adobe Commerce instances only. Moreover, it needs valid access keys in auth.json to download. Therefore Open Source merchants run these checks manually.
Should I trust vendor compatibility claims?
Not without checking. “Compatible with 2.4.x” is marketing copy, not a constraint. Instead, download the package and read the real constraint in composer.json. Then verify in staging.
What should I do about an abandoned extension?
Fork it, replace it, or remove the feature. Forking is cheapest now and dearest over three years. For payments, checkout or tax, replacement is almost always right.
Should the audit come before or after quotes?
Before. It makes quotes comparable, because every agency prices the same list. Otherwise they price their own assumptions.