Search intent: procedural — Magento developers and agencies planning a 2.4.x version or security upgrade. We cover the pre-upgrade audit, extension compatibility, staging rehearsal, correct command sequence, what to test, and the production cutover. It pairs with our server requirements and CI/CD deployment guides.

The first section of the Magento upgrade checklist is pure reconnaissance, and it determines whether the rest goes smoothly. Record your exact current version (see the Adobe release lifecycle policy for supported lines) with bin/magento --version — not “2.4.7” but the precise patch level, because patch level determines which upgrade paths and isolated patches apply. Confirm the target version and check its requirements against your infrastructure: PHP, MySQL, search engine and Redis versions all shift across 2.4.x releases, and a version mismatch surfaces as a cryptic Composer failure rather than a helpful message.

Then inventory customisation. List every third-party extension with its version, note every core override or preference in your custom modules, and identify theme customisations that may depend on templates the upgrade changes. This inventory is the single most valuable artefact in the Magento upgrade checklist, because it tells you where breakage will occur before you cause it.

No step in the Magento upgrade checklist is skipped more often or more expensively than the staging rehearsal. Build staging from a genuine production clone — current database, current media, same PHP and service versions — because an upgrade that succeeds against sample data proves very little. Real catalogues surface real problems: data migrations that take hours, extension conflicts, and custom code depending on changed core behaviour.

Rehearse the complete process on staging and time it. That timing is what lets you size the production maintenance window honestly rather than guessing. Note every manual fix required, because those become part of your production runbook. If the rehearsal fails, you have lost nothing; if you skip it, you discover the same failure with customers watching.

Magento upgrades follow a specific command order, and deviating from it causes most of the “upgrade broke everything” reports. The sequence below is the canonical path for a Composer-based upgrade — the core of any Magento upgrade checklist.

# 0. backup FIRST - database + media + code
mysqldump -u user -p dbname | gzip > backup-$(date +%F).sql.gz
tar czf media-$(date +%F).tar.gz pub/media

# 1. maintenance mode on
bin/magento maintenance:enable

# 2. update the metapackage to the target version
composer require magento/product-community-edition=2.4.9 --no-update
composer update --with-dependencies

# 3. schema + data upgrade, then compile
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f

# 4. reindex + clear, then reopen
bin/magento indexer:reindex
bin/magento cache:flush
bin/magento maintenance:disable

Three ordering rules worth internalising. setup:upgrade must run before setup:di:compile, because compilation depends on the updated schema and module list. Static content deployment comes after compilation. And in production mode, never run compilation or static deployment against a live directory without maintenance mode enabled — customers will hit half-generated assets. Adobe’s upgrade guide documents the supported paths in detail.

Post-upgrade testing should follow the money. Work the complete purchase journey on staging: browse a category, filter with layered navigation, view a configurable product, add to cart, apply a coupon, and complete a real checkout with each active payment method. Payment integrations are the most fragile part of any Magento upgrade checklist because they combine third-party code with core checkout changes.

Then verify the operational layer: admin login and 2FA, order placement and invoicing, email delivery, cron execution (bin/magento cron:run and check schedules are running), indexer status, and search results. Check the logs in var/log/ for new errors that are not yet visible in the UI.

For the production window: schedule during genuine low traffic, communicate the window, keep the tested rollback immediately available, and have someone monitoring order flow for the first hours afterwards — a store that looks fine but has stopped taking orders is the failure mode that costs most. Finally, apply any outstanding security patches for the new version, since an upgrade does not automatically include isolated patches published after that release; our APSB26-73 guide shows how those work. Our Magento team plans and executes upgrades with tested rollback.