Adobe Commerce upgrade service: what's actually involved

Start with the version and support matrix. 2.4.9 has the longest standard support, to May 31, 2029, but lists only PHP 8.5. 2.4.8 runs to May 31, 2028 and lists PHP 8.4 and 8.3. If an extension you can’t replace isn’t ready for PHP 8.5, that decides it for now.

List every installed module, then sort them into core, vendor extensions and your own custom code.

bin/magento --version
bin/magento module:status --enabled
composer show

On Adobe Commerce, the Upgrade Compatibility Tool (bin/uct) checks a customized instance against a target version and reports critical issues, errors and warnings. It is available for Adobe Commerce only, and it finds problems but doesn’t fix them. For each vendor extension, someone also has to confirm that a compatible release exists, or decide what replaces it.

Adobe’s upgrade prerequisites contain more than the headline PHP change. A proposal that says “we’ll update Composer and run the upgrade” has probably not read them:

• Update system software, including PHP, and handle the MySQL and MariaDB changes.
• Confirm a supported search engine: bin/magento config:show catalog/search/engine.
• Convert tables from COMPACT to DYNAMIC row format, and from MyISAM to InnoDB.
• Set the open files limit to 65536 or higher.
• Confirm cron is running.
• Set DATA_CONVERTER_BATCH_SIZE for the serialized-to-JSON conversion, testing before raising it, because larger values use more memory.
• Check file system permissions and set the docroot to pub/.
• Install the magento/composer-root-update-plugin Composer plugin.

The work happens on a copy of the store with a sanitised database, with your catalogue’s real shape. Custom modules get fixed against the compatibility report. Vendor extensions get updated or replaced. Theme overrides need comparing with the new core templates, because the override keeps old markup when the core moves on.

Test the paths that make or lose money: browsing and search, add to cart, checkout with each payment method, tax and shipping totals, order export to your ERP, emails, admin order handling and returns. Run them with your own products and customer groups, because a demo catalogue won’t find your edge cases. Time the database conversion on the copy too, since it tells you how long the release window needs to be.

Release from a written plan, outside your busy periods, with a backup taken and a tested route back. Afterwards, watch order flow and error logs closely, and confirm that integrations and cron are running.

Adobe’s monthly isolated security patches aren’t cumulative, so the first missed month starts a backlog. Agree who reads the bulletins and applies them. Adobe’s upgrade guide says PCI compliance requires being on the latest patch or security patch, and recommends upgrading with each patch cycle.

1. Which target version do you recommend, and which extension or stack constraint decided it?
2. Which of Adobe’s prerequisites apply to our store, and who handles the server changes?
3. What happens if an extension has no compatible release?
4. What will you test, against what data, and what is the rollback?
5. Who applies security patches after go-live?

We answer these in an assessment of your store, and quote a price for the agreed scope afterwards. See our Adobe Commerce services for the rest of that work. Most of our work is delivered under NDA, so many projects cannot be named. We have no published Adobe Commerce upgrade case study here. Our published prices for Laravel upgrades don’t apply to this platform.