How do I resolve Composer dependency conflicts during a Magento 2 upgrade?
You resolve Composer conflicts in a Magento 2 upgrade by finding the package blocking the new version and fixing it. The blocker is usually a stale pin in your root composer.json or an extension built for the old core release. Once nothing blocks it, composer update can resolve the full dependency tree in one pass.
Quick answer
To resolve Magento 2 Composer conflicts during an upgrade, set the target release with composer require-commerce and --no-update. Then run composer why-not magento/product-community-edition 2.4.9 to list every blocker. Most blockers are stale version pins in the root composer.json or extensions with no release for the new version. Raise the pin, update the extension, or remove it, then run composer update --with-all-dependencies on a staging branch.
What causes Composer conflicts in a Magento 2 upgrade?
Composer stops with “Your requirements could not be resolved to an installable set of packages,” followed by a numbered list of problems. Look first for a line ending in “conflicts with your root composer.json require”. When it appears, the package on that line is your blocker. The version in parentheses is the pin in your own file.
Here is a trimmed real example from a 2.4.4-p2 to 2.4.6 upgrade:
- magento/product-community-edition 2.4.6 requires colinmollenhour/credis ^1.13 -> found colinmollenhour/credis[v1.13.0, v1.13.1, v1.14.0] but it conflicts with your root composer.json require (1.12.1).Magento 2.4.6 needs colinmollenhour/credis 1.13 or later, but the root composer.json still pins 1.12.1. Raising that pin to ^1.13 clears the conflict.
The blocker usually falls into one of these groups:
| Blocker | What the error shows | Fix |
|---|---|---|
| Stale pin in the root composer.json, often on packages like symfony/process or magento/magento2-functional-testing-framework | “conflicts with your root composer.json require” with the pinned version in parentheses | Raise the pin to the range core expects, or drop it if the new release fixes the original bug |
| Extension built for older core modules | The extension requires an older magento/framework or magento/module-* version | Require the extension version its vendor lists as compatible with your target release |
| PHP version mismatch | “your php version (x.x) does not satisfy that requirement” | Upgrade PHP on every environment, or choose a target release that supports your PHP version |
| Abandoned extension | No version of the extension fits the new core constraints | Remove it with composer remove vendor/module –no-update and plan a replacement |
Magento 2.4.9 adds its own blockers. Per Adobe’s 2.4.9 release notes, Magento 2.4.9 replaces Laminas MVC with a native MVC layer. The release also swaps Zend_Cache for Symfony Cache and drops support for PHP 8.2 and 8.3. An extension that only allows those PHP versions will stop composer update outright. Extensions built on Laminas MVC or Zend_Cache may install cleanly and then fail at runtime. Confirm 2.4.9 support with each vendor before you upgrade.
How to resolve Magento 2 Composer conflicts
The current release is Magento 2.4.9, released on 12 May 2026. The commands in these steps use it as the example target.
Step 1: Work on a branch with a backup
Copy composer.json and composer.lock before you touch anything, and run the upgrade on a staging branch. If a fix goes wrong, you restore both files and start again.
cp composer.json composer.json.bak
cp composer.lock composer.lock.bakStep 2: Set the target version with composer require-commerce
Since Magento 2.4.2, Adobe’s upgrade guide uses the composer require-commerce command from the magento/composer-root-update-plugin package. The –no-update flag writes the new constraint without resolving anything yet.
composer require-commerce magento/product-community-edition 2.4.9 --no-updateUse magento/product-enterprise-edition for Adobe Commerce, and swap in your actual target version. Adding –interactive-root-conflicts makes the plugin prompt you on each root composer.json value that clashes with the new release.
Step 3: Find the blocking package with composer why-not
Run composer why-not against the Magento metapackage and version you set in Step 2, for example magento/product-community-edition 2.4.9. Composer lists every installed package and constraint that prevents that version.
composer why-not magento/product-community-edition 2.4.9On a store with a dozen extensions, that beats hunting for Magento 2 Composer conflicts one package at a time.
Step 4: Fix each conflicting package
Apply the matching fix from the blocker table for each package composer why-not lists. Fix one package, then rerun composer why-not before moving to the next.
Step 5: Run composer update –with-all-dependencies
Once composer why-not returns no blockers, let Composer update the core packages and their dependencies together.
composer update --with-all-dependenciesThen run composer check-platform-reqs on each server you deploy to. It flags any PHP version or extension the new packages need and the server lacks. Once it passes, run the upgrade.
bin/magento setup:upgradeIf the update fails again, a new blocker has surfaced deeper in the tree. Rerun composer why-not to find it, then fix it the same way.
What not to do when Composer conflicts block a Magento 2 upgrade
- Don’t use –ignore-platform-reqs to get past a PHP mismatch. Composer skips the PHP check, so code built for newer PHP installs anyway and throws fatal errors at runtime.
- Use –force-root-updates with care. Adobe documents that –force-root-updates overwrites conflicting custom values in your root composer.json with the values Commerce expects.
- Never edit composer.lock by hand or copy vendor/ folders between environments.
- Removing an extension’s code leaves its database tables, its setup_module entry and its core_config_data rows behind. Run bin/magento module:disable before you remove it.
Most Magento 2 Composer conflicts trace back to a stale root pin or an extension without a compatible release. Check both before you change the core constraint, and composer update has far less to fight. If your project carries a long list of custom or abandoned modules, our Magento development team can audit them before the upgrade begins.
Related Answers
Was this answer helpful?
Your feedback helps us improve our answers.
Still need help?
Talk to our Magento experts
Stuck on a Composer conflict mid-upgrade? Send us the error output and we’ll help you find which package is holding the upgrade back.