How to Upgrade Magento 2 to the Latest Version (2.4.9)

Upgrading Magento 2 to the latest version helps keep your store secure, supported, and compatible with current PHP, database, search engine, and extension requirements. However, an upgrade can also cause dependency conflicts, extension issues, or downtime if the existing environment and upgrade path are not properly assessed.

Magento 2.4.9 is the latest minor release as of May 2026, but it may not be the right immediate target for every store. Your current Magento version, edition, deployment model, server environment, extensions, theme, and custom code all affect how the upgrade should be performed.

This guide explains how to prepare your store, upgrade a modern Magento 2 installation using Composer, handle legacy installation scenarios, and complete the required storefront, Admin, checkout, integration, and system checks before going live.

---

Why Should You Upgrade Magento 2?

Keeping Magento 2 on a supported release is important for maintaining store security, platform compatibility, and long-term stability. As Magento and its supporting technologies evolve, older installations may become incompatible with current PHP, database, search, Composer, extension, and integration requirements.

Magento Open Source 2.4.9, released in May 2026, updates the platform’s technical foundation and resolves 580 issues in the core code. Depending on your current version and store environment, upgrading can help you:

• Maintain access to current security and quality updates.
• Keep the store compatible with supported server technologies.
• Resolve core platform issues fixed in newer releases.
• Reduce compatibility risks with actively maintained extensions and integrations.

However, the latest Magento release is not automatically the right immediate target for every store. Review the supported release lines, system requirements, upgrade path, and extension compatibility before selecting your target version.

---

Which Magento 2 Upgrade Approach Should You Use?

The correct Magento 2 upgrade path depends on your current version, edition, installation method, and deployment model. Composer is the standard option for modern Magento Open Source and Adobe Commerce on-premises installations, while Adobe Commerce Cloud projects must follow the Cloud-specific branching and deployment workflow.

For most current on-premises Magento installations, follow the Composer method in this guide. If your store runs on Adobe Commerce Cloud, uses a legacy non-Composer codebase, or contains extensive custom development, confirm the appropriate upgrade path before changing application packages.

---

What to Prepare Before The Magento 2 Upgrade?

A successful Magento 2 upgrade starts with assessing your current store before changing any packages or running upgrade commands. You need to identify your current Magento version, select a compatible target release, confirm the required server stack, and check whether your extensions and custom code support that release.

Complete the following preparation steps in a staging environment before upgrading your production store.

1. Identify your current version and upgrade path

Start by checking your currently installed Magento version:

bin/magento --version

Then review the size of the version gap between your current installation and the target release. A store running a recent Magento 2.4.x version may follow a different upgrade path from one running Magento 2.3.x or an early 2.4 release.

Before proceeding, determine:

• Your current Magento version and patch level.
• Whether you use Magento Open Source, Adobe Commerce on-premises, or Adobe Commerce on Cloud.
• Whether the target release supports a direct upgrade from your current environment.
• Whether Composer, PHP, database, search engine, and other dependencies must be upgraded first.
• Whether an intermediate Magento version is required.

Do not assume that every Magento store can be upgraded directly to the latest version in a single step.

2. Backup your Magento store completely

Create a complete and restorable backup before making any changes. Your backup should include:

• The Magento database.
• The app, pub, generated, and media directories.
• composer.json and composer.lock.
• The app/etc/env.php and app/etc/config.php configuration files.
• Custom themes, modules, integrations, and deployment configuration.

Verify that the backup can be restored successfully. A backup that has not been tested may not provide a reliable rollback option if the upgrade fails. If you need a detailed walkthrough, follow our Magento backup and restore guide before continuing with the upgrade.

3. Check the system requirements for the target version

Each Magento version is accompanied by updated system requirements, particularly regarding PHP, database engines, and supported libraries. Upgrading without verifying these may result in critical errors or broken functionality.

Below is a planning overview of the system requirements for Magento 2.4.7, 2.4.8, and 2.4.9. Use it to identify the server and dependency changes that may be required before upgrading Magento 2 to your target version.

This table is a planning overview rather than a substitute for release-specific documentation. Check the official Magento system requirements for your exact edition, deployment model, and target patch before changing your server environment.

If you want to check your current environment, run these SSH commands:

php -v         # Check PHP version
mysql -V       # Check MySQL version
composer -V    # Check Composer version

Also verify the versions of OpenSearch, RabbitMQ, Redis or Valkey, Varnish, and your web server if they are part of your Magento environment.

4. Review extensions, custom modules, and theme compatibility

Create an inventory of all third-party extensions, custom modules, themes, payment integrations, shipping integrations, and API connections. Confirm that each component supports the target Magento and PHP versions.

Before upgrading:

• Update compatible extensions to their required versions.
• Remove abandoned or unnecessary modules.
• Check custom code for deprecated Magento and PHP functionality.
• Review Composer dependency constraints.
• Test critical integrations in staging.

Do not rely only on whether a module can be enabled. Test its actual storefront, Admin, checkout, cron, API, and data-processing behavior after the upgrade.

5. Prepare a staging environment and rollback plan

Never perform the first upgrade attempt directly on your live store. Create a staging environment that closely matches production, including the PHP version, database engine, search service, extensions, custom code, and deployment configuration.

Define the rollback conditions before starting. If the upgrade causes unresolved dependency errors, database failures, checkout issues, or critical integration problems, the team should know when and how to restore the previous version.

6. Plan maintenance mode, cron, queues, and deployment

Plan how the store will be placed in maintenance mode and how background processes will be controlled during deployment. Depending on your Magento edition and infrastructure, this may include pausing cron jobs, message queue consumers, scheduled imports, and third-party synchronization processes.

Also estimate the required maintenance window and decide how validated changes will be deployed from staging to production.

7. Confirm SSH access and Composer availability

For a Composer-based Magento upgrade, confirm that you have:

• SSH access to the server.
• Permission to run bin/magento and Composer commands.
• Access to repo.magento.com.
• Valid Magento Marketplace authentication keys.
• Sufficient server memory and disk space.
• Access to application, PHP, Composer, database, and web server logs.

If Composer is not yet available in your project, review the Composer installation process in our Magento 2 installation guide before planning the version upgrade. If your store uses a Git-based or automated deployment pipeline, perform the upgrade through the same workflow rather than changing production files directly.

---

How to Upgrade Magento to Latest Version

Composer is the recommended upgrade method for current Magento Open Source and Adobe Commerce on-premises installations. The following steps cover the Composer workflow first, followed by guidance for legacy non-Composer installations and an explanation of why Web Setup Wizard can no longer be used for Magento 2.4.x upgrades.

Method 1. Upgrade Magento 2 Using Composer

Composer is the recommended upgrade method for current Magento Open Source and Adobe Commerce on-premises installations. It updates the Magento metapackage and resolves the PHP dependencies required by the target release.

The commands below provide a general upgrade sequence for Composer-based installations. Package names and deployment commands differ between Magento Open Source, Adobe Commerce on-premises, and Adobe Commerce on Cloud, so confirm your edition and deployment model before proceeding.

Perform the first upgrade attempt in staging and replace [target-version] with the exact Magento release you have validated for your store.

1. Verify Your Magento and Composer Versions

Check the currently installed Magento and Composer versions before changing any packages:

bin/magento --version 
composer --version

Compare the results with the requirements of your target Magento release. Also confirm that your PHP, database, OpenSearch, extensions, and custom modules are ready for the target version.

If the version gap is large, verify whether an intermediate Magento or Composer upgrade is required. Do not continue until the upgrade path has been tested in staging.

2. Enable maintenance mode

Enable maintenance mode to prevent customers from accessing the storefront while application packages and database structures are being updated:

bin/magento maintenance:enable

If developers need to access the store during the upgrade, allow their IP addresses:

bin/magento maintenance:enable --ip=<developer-ip-address>

Confirm that the maintenance page works correctly before proceeding.

3. Pause Cron Jobs and Queue Consumers

Running scheduled jobs or message queue consumers while Magento code and database structures are changing can cause incomplete processing or inconsistent data. Pause cron-driven tasks, scheduled imports, third-party synchronizations, and queue consumers before continuing.

For Magento Open Source installations using Magento-managed cron entries, run:

bin/magento cron:remove

Allow active queue consumers to finish their current messages before stopping them. Record the existing cron and consumer configuration so it can be restored after the upgrade.

(*) Note: Adobe Commerce Cloud uses its own deployment and cron-management workflow. Follow the Cloud-specific process instead of applying the Open Source command directly.

4. Back Up the Composer Configuration

Create copies of both Composer files before changing the Magento package requirement:

cp composer.json composer.json.bak
cp composer.lock composer.lock.bak

These files record the project requirements and the exact dependency versions installed before the upgrade. Keep them together with the full store backup and rollback plan prepared earlier.

5. Update the Magento Package Requirement

Select the Magento package that matches your current edition:

• Magento Open Source: magento/product-community-edition
• Adobe Commerce on-premises: magento/product-enterprise-edition

For Magento Open Source, use:

composer require-commerce magento/product-community-edition [target-version] --no-update

For Adobe Commerce on-premises, use:

composer require-commerce magento/product-enterprise-edition [target-version] --no-update

Replace [target-version] with the exact release validated for your store, such as 2.4.9.

The --no-update option changes the package requirement without immediately installing dependencies. This allows you to review composer.json before running the full update.

Do not remove magento/product-community-edition unless you are intentionally converting Magento Open Source to Adobe Commerce. Edition conversion is a separate project from a standard Magento version upgrade.

If composer require-commerce is unavailable, verify that the required Magento Composer root update plugin is installed and compatible with the current project. Use --interactive-root-conflicts or --force-root-updates only after reviewing the affected root requirements.

6. Update Composer Dependencies

Review the package changes in composer.json, then install the Magento release and its required dependencies:

composer update

Read the complete Composer output before continuing. If Composer cannot resolve the target version, identify the package that blocks the upgrade instead of forcing the update immediately.

For Magento Open Source, you can investigate a version conflict with:

composer why-not magento/product-community-edition [target-version]

Update, replace, or remove incompatible extensions only after confirming their impact on the store.

Editing the name, version, or description fields in composer.json is optional project metadata and is not required to perform the Magento upgrade.

7. Clear Generated Files and Update the Database

Remove cached and generated files from the previous Magento version:

rm -rf var/cache/*
rm -rf var/page_cache/* 
rm -rf generated/code/*

If the store uses Redis or another remote cache backend, clear the relevant cache through the appropriate infrastructure process as well.

Then apply the database schema and data changes required by the upgraded Magento modules:

bin/magento setup:upgrade

Stop and review the upgrade output if this command reports a module, schema, or data patch error. Do not reopen the storefront until the underlying issue has been resolved.

8. Compile Code and Deploy Static Content

For a production-mode store, compile dependency injection code and deploy the required static assets before disabling maintenance mode:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento indexer:reindex
bin/magento cache:clean
bin/magento cache:flush

Stores with multiple languages, application nodes, or automated deployment pipelines may require additional deployment options. Follow the same process previously validated in staging.

9. Verify the Upgrade and Restore Store Operations

Confirm that Magento reports the expected target version:

bin/magento --version

Before reopening the store, complete an initial smoke test of:

• The storefront and Magento Admin.
• Category and product pages.
• Search, cart, and checkout.
• Payment and shipping methods.
• Critical extensions and integrations.
• Magento, PHP, database, and web server logs.

Once the initial checks pass, restore the required cron jobs and queue consumers, then disable maintenance mode:

bin/magento maintenance:disable

Continue with the full post-upgrade checklist below and monitor the store closely after traffic resumes. If a critical issue cannot be resolved, use the rollback plan prepared before the upgrade.

Method 2: Manually Upgrade a Legacy Magento Installation

Manual file replacement is a legacy upgrade approach intended only for Magento installations that are not managed through Composer. It carries a higher risk of dependency issues, overwritten customizations, obsolete files, and human error.If your Magento store already uses Composer, follow Method 1 instead. Do not choose manual replacement simply to avoid using Composer or the command line.

Before proceeding, create a complete backup and test the entire upgrade process in a staging environment that closely matches production.

1. Back Up and Prepare the Staging Store

Create a restorable backup of the Magento database, application files, media, configuration, themes, and custom modules. Then create a staging environment that matches the production server as closely as possible.

Enable maintenance mode on the staging installation before replacing any Magento files:

php bin/magento maintenance:enable

2. Download the Target Magento Release

Download the target Magento release package selected during the preparation stage. Do not automatically choose the newest package unless its server requirements, extension compatibility, and upgrade path have already been validated for your store.

Extract the package into a separate temporary directory first. Do not extract it directly over the existing Magento installation.

3. Review and Replace Magento Files Carefully

Compare the clean release package with the existing Magento codebase before replacing files. Identify:

• Core files that were modified directly.
• Custom modules stored under app/code.
• Custom themes and frontend assets.
• Environment and deployment configuration.
• Files that existed in the old release but were removed from the target release.

Preserve custom code and configuration where appropriate, but do not copy outdated Magento core files into the new codebase. Deploy the reviewed files to staging only after the differences have been assessed.

Avoid selecting “replace all” without reviewing the affected files. This may overwrite customizations while still leaving obsolete files from the previous Magento version.

4. Run the Magento Upgrade Commands

Once the reviewed files have been deployed to staging, apply the Magento database and generated-code changes:

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento indexer:reindex
php bin/magento cache:clean
php bin/magento cache:flush

Monitor the command output and Magento logs for module, schema, compilation, or static content errors. Do not continue to production if any critical error remains unresolved.

5. Test and Deploy to Production

Test the storefront, Admin panel, catalog, search, cart, checkout, payment and shipping methods, extensions, integrations, cron jobs, and logs.

Once the staging upgrade passes the full post-upgrade checklist, repeat the validated deployment process in production. Disable maintenance mode only after the production store has passed its initial smoke tests:

php bin/magento maintenance:disable

If possible, plan to convert the project to a Composer-managed installation before the next Magento upgrade. Composer provides more reliable package and dependency management for current Magento releases.

Method 3. Magento Web Setup Wizard — Deprecated

Magento Web Setup Wizard was available in Magento 2.3.x for managing components and performing upgrades through the Admin panel. However, Adobe removed its upgrade functionality from Magento 2.4.0.

As a result, Web Setup Wizard cannot be used to upgrade a current Magento store to Magento 2.4.9 or another supported Magento 2.4 release. For modern Composer-based installations, follow Method 1 above.

If your store still runs Magento 2.3.x, do not rely on Web Setup Wizard as a direct path to the latest release. First assess the current codebase, Composer configuration, server stack, extensions, and customizations to determine the appropriate upgrade path.

(*) Note: Still using Magento 1? Moving from Magento 1 to Magento 2 requires a platform migration rather than a standard version upgrade. Follow our Magento 1 to Magento 2 migration guide for the appropriate process.

---

Perform Post-Upgrade Checks Before Going Live

The upgrade is complete, but you shouldn't assume your store is ready for customers right away. No matter which method you use, it's important to thoroughly test your store before switching traffic to the new version.

We recommend using the following checklist to verify that every critical part of your Magento store is working correctly:

If any critical test fails, keep the store in maintenance mode, review the relevant logs, and resolve the underlying issue before restoring customer traffic. The next section covers common Magento upgrade errors and their recommended fixes.

---

Common Magento Upgrade Issues and Fixes

Magento upgrade failures usually occur during dependency resolution, database updates, code compilation, static content deployment, or post-upgrade testing. The error message and logs from the stage where the process failed are the best starting points for diagnosis.

The table below summarizes common Magento upgrade issues, their likely causes, and the checks you should complete before rerunning the failed command.

---

Need Help with Your Magento Upgrade?

A Magento version upgrade involves more than updating the core package. Server requirements, Composer dependencies, extensions, custom code, themes, and third-party integrations must all remain compatible with the target release.

If your team does not have the technical resources to manage the entire process, LitExtension offers a dedicated Magento Upgrade Service.

Our specialists assess your current Magento version, store structure, customizations, extensions, and upgrade requirements to recommend a suitable approach and support the project through preparation, data migration, compatibility review, testing, and launch.

Your Magento Upgrade, Done Right!

---

Upgrade Magento 2 to Latest Version: FAQs

---

Final Words

Upgrading Magento 2 to the latest suitable version helps keep your store secure, supported, and compatible with current technologies. For most modern Magento installations, Composer is the recommended method, while manual file replacement should only be considered for legacy non-Composer setups.

A successful upgrade depends on more than running the correct commands. Check the target release against your server environment, extensions, themes, custom modules, and third-party integrations. Always create a restorable backup, validate the complete upgrade path in staging, and test all business-critical functions before reopening the production store.

If your Magento installation is outdated or heavily customized, resolve compatibility issues and prepare a clear rollback plan before deployment. A carefully tested upgrade is safer than moving directly to the newest release without understanding its impact on the store.