Magento 2.4.9 Upgrade Guide

DB dump (with routines + triggers), pub/media tar.gz, app/etc/env.php (gitignored — contains the crypt key!), composer.json + composer.lock. Store the tar.gz somewhere OFF this server.

mysqldump --single-transaction --quick --no-tablespaces \
  --routines --triggers <db_name> | gzip -9 > backups/db.sql.gz
tar -czf backups/media.tar.gz -C <magento_root> pub/media
cp <magento_root>/app/etc/env.php backups/env.php
cp <magento_root>/composer.{json,lock} backups/

What to expect: Takes 2–10 minutes depending on store size. The crypt key in env.php is non-negotiable — without it the DB is gibberish.

2.4.9 minimum is PHP 8.4 (PHP 8.3 is dropped). On bare LAMP/LEMP, install the new PHP-FPM and the Magento-required extensions, then point your FPM pool + nginx fastcgi_pass at it. On Docker, bump the base image tag.

# Bare LAMP/LEMP (Ubuntu / Debian)
sudo apt install php8.4-fpm php8.4-{cli,mysql,gd,curl,xml,mbstring,intl,bcmath,soap,zip,imagick}
sudo systemctl restart php8.4-fpm nginx

# Docker
# In your Dockerfile, change:
#   FROM php:8.3-fpm  -->  FROM php:8.4-fpm

What to expect: ~10–20 minutes including FPM pool config. Run php -v from inside the web user’s shell to confirm.

Adobe’s 2.4.9 supported matrix: MySQL 8.4 / MariaDB 11.8 / OpenSearch 3 / Valkey 9 (Redis 7 still works for back-compat). Production should match spec. Local dev usually works on older versions because Magento’s drivers adapt at connection time.

# Examples — adapt to your hosting
# MySQL: managed cloud (RDS, Aurora, MemoryStore) → schedule maintenance window
# OpenSearch: blue-green a new cluster, re-index, swap DNS
# Redis → Valkey: most managed providers swap with zero downtime

What to expect: Plan service migrations BEFORE the Magento upgrade if production. On a clean dev box, you can skip this and patch later.

Don’t use plain composer require for Magento metapackages — it errors out. Use Adobe’s require-commerce command (added by the magento/composer-root-update-plugin that ships with 2.4.4+).

composer require-commerce --no-update "magento/product-community-edition=2.4.9"
composer update --no-interaction

What to expect: 3–8 minutes. Pulls ~40 magento/* dependency bumps + Symfony 7.4. If your composer.json has version pins, you may have to relax them first.

This is where 3rd-party module breakages will surface. Read the FULL output (errors are interleaved with module names). If a module crashes here, jump to the composer-patches recipe below — or temporarily composer remove to keep moving.

bin/magento setup:upgrade --keep-generated

What to expect: Usually 30–90 seconds on a small store. If it aborts, read the LAST traceback line — that’s the module to patch or remove.

Don’t edit vendor/ files directly — they get overwritten on the next composer install. Use cweagans/composer-patches to ship reversible 3-line patches. Full recipe in the next section.

# Quick install
composer config allow-plugins.cweagans/composer-patches true
composer require cweagans/composer-patches

What to expect: 5–30 minutes per broken module — mostly writing the diff. When the vendor releases a fix, you drop the patch entry from composer.json.

Flush cache, reindex, regenerate sitemaps (if you have a SEO module), curl 10 representative pages, test admin login, run a checkout if you can. Watch var/log/exception.log + var/log/system.log for fresh entries.

bin/magento cache:flush
bin/magento indexer:reindex
curl -sI https://your-store.example/ | head -1
tail -n 50 var/log/exception.log

What to expect: 15–30 minutes of click-testing. Look for new entries in the log files in the last 10 minutes — not old ones.