Magento 2 Upgrade Guide for 2026
The checks to run before a Magento 2 upgrade: support dates, PHP, extensions, staging and rollback.
Key takeaways
- 01Check your Magento version's support end date before you plan anything else.
- 02Confirm the PHP version your target release supports, and test your extensions on it.
- 03Run the upgrade on staging with a full database copy and a tested rollback.
- 04Decide between upgrading and migrating based on custom code, extensions and hosting.
Why the support date comes first
Every Magento release has a support window. Adobe publishes its lifecycle policy, and staying on an unsupported version leaves a store exposed. Look up your version's end-of-support date before you plan the work. Adobe's security bulletins also show which patches apply to which versions; a recent bulletin, such as APSB26-153, can change the timing of an upgrade.
Step 1: check PHP
Each Magento release requires specific PHP versions. The PHP project publishes its supported versions, and older PHP releases stop receiving security fixes. Confirm that your hosting runs a PHP version the target release supports, and plan the PHP upgrade as a separate step where possible.
Step 2: audit extensions and custom code
List every third-party extension and every custom module. For each one, check whether it has a release for the target version. Extensions without a release are the most common blocker. Custom modules need a review for deprecated calls and for any core overrides.
Step 3: build a staging environment
Copy the production database and media to a staging environment that matches production as closely as possible. Run the full upgrade there first. Record every error, fix it in code, and repeat until the upgrade runs cleanly from start to finish.
Step 4: test before you switch
Run a regression checklist that covers the checkout, account pages, search, product pages, promotions and any integrations such as ERP, payments and shipping. Test on mobile as well as desktop.
Step 5: plan the rollback
Keep a tested rollback plan: a database backup taken just before the switch, the previous code release ready to redeploy, and a named person who can make the call. A rollback you have not rehearsed is not a plan.
Upgrade or migrate?
Upgrade when your custom code and extensions are mostly supported and the store is stable. Consider a migration when the codebase is heavily customised, the platform no longer fits the business, or the hosting setup needs a rebuild.
Frequently asked questions
How long does an upgrade take? It depends on the number of extensions and custom modules. The staging work usually takes the most time.
Can we upgrade without downtime? Some stores can, with careful planning and a short maintenance window for the final database step. Ask your team to test the window on staging first.
