Magento upgrades have a reputation for pain, and it is partly earned - but most upgrade disasters trace to process failures, not platform failures: untested extensions, no staging discipline, upgrades deferred for two years until they are archaeology. Upgrading little and often, with a repeatable process, keeps upgrades boring. Here is the process.
Step 0: The Pre-Upgrade Audit
Before touching Composer, inventory what you are upgrading:
- Extension list: every third-party module, its current version, and whether a compatible release exists for the target Magento version. The vendor’s changelog is your friend; “compatible” in a marketplace listing is marketing until tested
- Custom code: theme overrides (especially checkout), plugins on classes the release notes mention changing
- The release notes themselves: read the backward-incompatible changes section for every version between yours and the target. Jumping three minor versions means reading three sets
- PHP version: check the target’s requirements and plan the PHP upgrade alongside if needed (see our PHP 8.3 compatibility post)
The Composer Steps
On staging, never production-first:
composer require-commerce magento/product-community-edition 2.4.7 --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush
Read every Composer conflict rather than forcing past it - a conflicting extension requirement is telling you something real about compatibility.
The Staging Protocol
The staging environment must be production-like: same PHP, same services, a recent copy of the production database. Then test in order:
- Smoke: homepage, category, product, cart, checkout place-order, customer account
- Payment flows: every payment method, including refunds
- Admin: order processing, product edit, the integrations’ entry points
- Integration points: ERP sync, email dispatch, feeds - run them against staging
- Custom features: the checklist of everything your store does beyond core
Every failure gets fixed on staging and retested. “We’ll fix it after go-live” is how one-day upgrades become two-week incidents.
Go-Live
- Maintenance window in the quietest trading period; communicate to staff
- Database and media backup immediately before - not last night’s, now
- Deploy the tested code, run setup:upgrade, warm the caches, and run the smoke test in production within minutes
- Have the rollback ready: previous code deploy + the pre-upgrade database backup, and someone who has practiced running it
- Watch error logs, New Relic and order flow for the first hours; assign a person to it
The Sustainable Rhythm
The merchants with painless upgrades run them quarterly, each a small hop. The ones with horror stories run them biennially. Adobe releases security patches on a schedule - being one version behind is a strategy; being eight behind is a debt with compounding interest.
Upgrade discipline is deploy discipline plus testing discipline, repeated on a calendar. Build the process once and every future upgrade is a week of routine work instead of a quarter of firefighting.