When to run the Magento Open Source upgrade from 2.4.8 to 2.4.9
A store team on Magento Open Source 2.4.8 has to decide when to move to 2.4.9, and the answer depends more on its own calendar than on the release date. Magento Open Source 2.4.9 was released in May 2026. Standard support for 2.4.8 runs until May 31, 2028, so the team is not forced to move this quarter. Adobe's upgrade guide, however, recommends upgrading every patch cycle to stay secure and PCI compliant. That recommendation sets the default: the real question is how soon the team can run the upgrade without weakening its change control. Treat the support end date as the outer limit, not the target.
This section covers the direct move from 2.4.8 to 2.4.9, with no intermediate release line. Before scheduling, confirm the exact 2.4.8 patch level the store runs and compare it with the 2.4.8-p5 requirements and the 2.4.9 requirements. Those two lists are the baseline for the target stack. They cover PHP 8.4 or 8.3 on the 2.4.8 line against PHP 8.5 on 2.4.9, OpenSearch 3, Redis or Valkey 9 on 2.4.9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30. Check each server, container image and managed service against both lists. Any component that changes version becomes its own work item with its own testing and rollback plan.
Three checks should drive the timing. First, ask every extension vendor and the owner of each custom module for written confirmation of 2.4.9 compatibility. Adobe names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort, so a complete inventory of these items is the most useful input to the schedule. Second, check the team's freeze windows, peak trading periods and staffing for the test and cutover weeks. Third, check the release calendar. Adobe's released versions page lists 2.4.10-alpha1 as released on October 13, 2026, so the team should confirm whether its plan already accounts for a newer target.
Schedule the production cutover only after a staging run passes the checkout, payment, search and integration tests, and after the team has rehearsed a rollback. Set a clear owner for the go or no-go decision and write down what would stop the cutover. If the store runs on 2.4.8 past the point where it can receive the patches it needs, PCI DSS assessors will ask why, so record the reasoning behind the chosen date. Ask the implementation partner or internal lead to put the scope, the test plan and the cutover window in writing before work starts.
What changes between 2.4.8 and 2.4.9 for your stack
This table compares the platform components listed for Magento Open Source 2.4.8-p5 with those listed for 2.4.9, and the effect each change has on your stack. Read each row against your current versions and custom code, and plan the action column before you set the target. Adobe supports only the listed combinations, so every component needs a check against the 2.4.9 requirements, including the Varnish entry.
| Change | Impact | Action needed |
|---|---|---|
| PHP | 2.4.8-p5 lists PHP 8.4 or 8.3. Magento Open Source 2.4.9 lists PHP 8.5. | Test every custom module and third-party extension on PHP 8.5 and confirm each one supports it before cutover. |
| Symfony | The 2.4.9 release notes cite Symfony 7.4 LTS with official PHP 8.5 support. | Review custom code that calls Symfony components, then run regression tests on admin, checkout and cron jobs. |
| OpenSearch | OpenSearch 3 is listed on both 2.4.8-p5 and 2.4.9, so the required major version stays the same. | Confirm your cluster runs a supported OpenSearch 3 version and that every search plugin supports it. |
| Redis or Valkey | The listed version moves from Redis or Valkey 8.1 to Valkey 9. | Upgrade the cache and session store, then confirm cache and session settings still apply after the change. |
| MySQL or MariaDB | MySQL 8.4 stays listed. MariaDB 11.4 is not listed for 2.4.9. MariaDB 12.3 is recommended and 11.8 is also listed. | Choose the database target and rehearse a restore and migration. Stores on MariaDB 11.4 must move to 11.8 or 12.3. |
| RabbitMQ, Composer and nginx | Unchanged: RabbitMQ 4.3, Composer 2.10 and nginx 1.30 are listed on both lines. | Keep these versions, then confirm your Composer and nginx configuration still matches the 2.4.9 install steps. |
| clearCart GraphQL mutation | Previously Adobe Commerce only, the clearCart mutation is now available in Magento Open Source 2.4.9. | Decide whether storefront or integration clients should call it, and review who can reach it through GraphQL. |
| Resolved core code issues | The 2.4.9 release notes cite 580 resolved core code issues. | Scan the release notes for fixes that touch code you have changed, and retest those areas. |
| Varnish | 2.4.8-p5 lists Varnish 8. Its status on the 2.4.9 list must be confirmed before the target is set. | Check Varnish against the 2.4.9 requirements before you set the target version, and record the result. |
How the PHP, database and search versions move together
The PHP, database, search and cache versions move together because Adobe lists 2.4.9 against one set of combinations and states that it supports only those combinations. The 2.4.9 requirements name PHP 8.5, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64, alongside a Symfony 7.4 LTS framework update in the release. Moving one component out of step, such as keeping PHP 8.4 while adopting OpenSearch 3, can leave the store running on a combination Adobe does not support, even when the storefront appears to work. Plan the upgrade as one target matrix, and confirm every row of it before any code or configuration change begins.
The database is the component most teams treat as a default, and it should be a deliberate decision. The 2.4.9 requirements allow MySQL 8.4, or MariaDB 12.3 (recommended) or MariaDB 11.8. If you run MariaDB 11.4 or 11.8 on 2.4.8, confirm whether you will stay on your current line or move to 12.3, because a major database change needs its own migration and regression tests. Check the character set and collation defaults, SQL mode settings, backup and replication tooling, and any database-side customizations against the engine and version you select. Record the choice in the matrix so that the staging, performance and production environments all run the same database line.
OpenSearch 3 is the only search engine on the 2.4.9 list, so the search configuration, cluster version and plugins must be confirmed on OpenSearch 3 in your own environment. Ask your team to list every OpenSearch plugin, analyzer and index template the store uses, then confirm each one has an OpenSearch 3 build and works with the Magento indexers. Valkey 9 is the session and cache store on the 2.4.9 list, while the 2.4.8-p5 requirements listed Valkey 8.1, so the cache and session backend also changes version in this upgrade. Confirm the persistence, memory limit, eviction and session settings on the new Valkey version, and test checkout sessions under load before cutover.
The dependency check goes beyond the core platform. Confirm the PHP extensions your installation loads against the 2.4.9 requirements and the Composer requirements of the codebase, including any extension your custom modules depend on. Composer 2.10 is the required build tool, so update the build images and CI runners that run composer install and composer require-commerce. Review each third-party extension and custom module for Symfony components it uses, since the 2.4.9 release updates Symfony to 7.4 LTS. Varnish 8 appears in the 2.4.8-p5 requirements, so confirm with Adobe whether it remains part of your target configuration. Do not assume these versions from a base image or from the previous release. Verify each one in the environment that will serve production traffic.
Preparing your Magento Open Source upgrade before any code moves
Each area produces something you can check before the upgrade begins: a restorable copy of the store, a list of everything the upgrade touches, a staging copy that matches production, and a record of how the store behaves today. Work on them in parallel where possible, because findings from one area often change the plan for another.
Full backup with a tested restore
Back up the code base, the database and the media directory together so they represent the same point in time. A backup that has never been restored is an assumption, so restore it to a separate environment and confirm that the storefront loads, the admin can sign in, and product images display. Record how long the restore took and who performed it, because that is the rollback time you will actually have during cutover. Keep the copy outside the servers that will be changed.
Inventory of customizations and integrations
Adobe names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort, so list each one before anyone estimates the work. Record the vendor, the installed version, whether it arrived through Composer or was copied into app/code, and the owner who can answer questions about it. Note core rewrites, template overrides and direct database queries, since these usually fail first. Check the list against 2.4.9 with the Upgrade Compatibility Tool, and treat vendor compatibility statements as claims to test.
Staging that matches production
Build staging from production's current stack first, including PHP, the database, OpenSearch, Valkey and the web server at the versions production runs today. Once that baseline matches, change only the components the target release requires, and record each change. The 2.4.9 requirements list PHP 8.5, MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Valkey 9, nginx 1.30 and Composer 2.10. Confirm whether production uses Varnish, since Adobe documents it as the full-page cache for self-managed installations.
Baseline of checkout and integration behavior
Before any change, record how checkout, payment, search and integrations behave on the current 2.4.8 store. Place test orders through each payment method, run search queries that represent your catalog, and capture the messages sent to ERP, shipping and tax services. Keep these outputs so the upgraded store can be compared against them line by line. Include the Content Security Policy restrict mode that 2.4.7 enables by default on storefront and admin payment pages, and confirm that each payment provider's scripts and frames still load under the policy.
Magento Open Source upgrade sequence from 2.4.8 to 2.4.9
This sequence moves a customized Magento Open Source store from 2.4.8 to 2.4.9 in a fixed order, so each change is tested in staging, has a restore point, and ends with a rehearsed cutover. The output is a store on the 2.4.9 stack with a signed-off rollback path.
Prepare staging and confirm target versions
Build a staging environment that mirrors production in code, configuration, extensions, theme and data volume, and confirm the full 2.4.9 version set against Adobe's system requirements before any change is made. The team lists PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30, and confirms that your stack uses only supported combinations. Production stays untouched at this stage. The step closes when the team signs off a written version matrix and a staging build that matches production.
Take and verify production backups
Capture a consistent database dump, the media directory, env.php, the Composer files and any custom configuration, then restore the set to a separate host to prove it works. Store the snapshot where it can be restored independently of the production servers. This snapshot is the rollback point for every later database change, so it is taken before the database is touched. The step is done when the restore completes, the store loads on the test host, and the restore time is recorded for the cutover plan.
Update the codebase with Composer
On a dedicated branch, change the Magento Open Source version constraint to 2.4.9 and run the require-commerce steps described in Adobe's upgrade guide, using Composer 2.10. Review the diff for changed core dependencies, custom module constraints and any lock file changes before merging, and keep the previous lock file so the change can be reverted. The step is complete when composer validate and composer install succeed on a clean build and the diff has been reviewed by a second engineer. Rollback is a branch revert plus the previous lock file.
Upgrade runtime and services in staging
In staging, move the PHP runtime to 8.5, Valkey to 9, the database to a supported MariaDB or MySQL version from the 2.4.9 matrix, OpenSearch to 3, and RabbitMQ, nginx and Varnish to their listed versions. Take a fresh snapshot of the staging database before the database change, and change one service at a time so that failures are traceable. Confirm each service version and each application connection after its change. The step closes when every service reports the target version and the storefront and admin connect to all of them. Rollback is the staging snapshot plus reinstalling the previous runtime package.
Run setup upgrade, compile and reindex
Run the Magento setup upgrade, dependency injection compilation, static content deployment and cache flush in staging, then reindex all indexers. Review the command output and the application logs for module schema errors, missing classes and deprecation failures on PHP 8.5 and Symfony 7.4 LTS. The step is complete when the commands finish without errors, every indexer reports Ready, and a sample of catalog, price and stock data matches production. If the setup upgrade fails in a way that alters the schema, restore the staging snapshot and repeat the step from the Composer change.
Fix extension and theme conflicts
Inventory every third-party extension, the theme and each custom module, then test each one against PHP 8.5 and the 2.4.9 codebase. Pay close attention to integrations affected by the 2.4.9 changes: the OAuth library was replaced with native PHP functions, and CAPTCHA and reCAPTCHA enforcement now extends to REST and GraphQL APIs. Replace or patch abandoned extensions with the vendor or your developers, and keep each fix in version control. The step is done when all extensions and the theme pass the agreed test suite and the checkout, account and API regression tests pass in staging.
Rehearse cutover under production-like conditions
Run a full cutover rehearsal on a copy of production data with the same web, cache, search, queue and payment connections used in production. Time each maintenance step, verify the Varnish cache and Content Security Policy behavior on storefront and payment pages, and run regression tests on checkout, payments, ERP and other integrations. Record every issue and rerun the rehearsal until it passes with the go/no-go criteria agreed in advance. The step is complete when the rehearsal checklist is signed off and a restore from the production snapshot has been tested. This rehearsed rollback runbook is the basis for the production change window.
Regression testing checkout and integrations, and rolling back safely
Checkout and integrations decide whether the 2.4.9 upgrade can go live, so the regression scope should be written and signed off before the first test run. The scope needs to cover guest and registered checkout, each payment method the store enables, tax and shipping calculations, admin order handling, and cron jobs. It also covers search results served by OpenSearch 3, cache behavior on Valkey 9, message consumers on RabbitMQ 4.3, and every third-party integration, including the ERP, PIM and shipping connectors. Each item should have a named tester, a test script and an expected result taken from the current production store.
Some of these areas fail quietly, so the checks need to look past a page that loads. After reindexing, compare search results for a fixed set of queries against the pre-upgrade baseline, and confirm that product and price changes appear on the storefront after a save. Confirm that cache invalidation works after a catalog change, and check that queues drain and do not back up. Ask your integration owners to confirm the message formats and API versions their systems expect. Also confirm whether your stack uses Varnish, because Adobe documents it as the full-page cache for self-managed installations, and its version must match the 2.4.9 requirements you plan to use.
Rollback depends on the restore point, not on the code. Before cutover, take a database backup and a copy of the media directory, then store both where the rollback team can reach them. Reverting the code alone will not undo schema changes that the upgrade applied to the database, so the database restore is the only reliable way back. Rehearse the restore on a copy of production and confirm the store works afterward. Also decide what happens to orders, customer accounts and inventory changes made after cutover, because restoring the backup removes them unless someone reconciles them by hand.
The go or no-go criteria need to be agreed before the cutover window opens, not during it. Write down which failures stop the release, such as any payment method that cannot authorize, any tax or shipping quote that differs from the baseline, or any integration that cannot send or receive data. Name the person who makes the call, the people who must be consulted, and the time limit for a rollback decision once cutover starts. Keep the criteria in the change record so the team can apply them without debating them under pressure. Ask your partner to review these criteria against the regression results in writing before the window.
What drives Magento Open Source upgrade effort
This table lists the factors that change how much work a 2.4.8 to 2.4.9 upgrade takes, with the reason each one adds effort and what to check first. Since no single figure applies across installations, read each row as a question about your own store. Effort depends on these drivers, so the quote follows from a written inventory of them.
| Driver | Why it adds work | What to check |
|---|---|---|
| Custom modules and core coupling | Modules that override core classes or rely on internal APIs need review against the 2.4.9 code base. | Count custom modules, list overrides and preferences, and mark each one that depends on core internals. |
| Theme and frontend customizations | Custom themes and JavaScript depend on core front-end components and on Content Security Policy, which runs in restrict mode by default from 2.4.7. | Check inline scripts, third-party tags and payment page scripts against CSP rules, then test them in staging. |
| Extension count and 2.4.9 support | Each extension needs a release that supports 2.4.9. Extensions without one may block the upgrade or need replacing. | Ask each vendor in writing whether a 2.4.9 release exists and which PHP and OpenSearch 3 versions it supports. |
| Third-party integrations and API versions | ERP, payment, shipping and messaging connectors call Magento APIs and external services whose versions may change with the new stack. | List each integration, its API version and whether its vendor supports the 2.4.9 requirements. |
| Custom GraphQL and REST endpoints | 2.4.9 extends CAPTCHA and reCAPTCHA enforcement to REST and GraphQL and replaces the OAuth library, so custom endpoints may need changes. | Test each custom endpoint, token flow and API client with CAPTCHA enforcement enabled. |
| Data volume and reindexing | Larger catalogs and order histories lengthen data upgrade and reindexing steps, and search needs a new OpenSearch 3 index. | Measure catalog size, index counts and the duration of a full reindex on a copy of production data. |
| Environments and test coverage | Each environment must run PHP 8.5, Valkey 9 and the chosen database. Thin automated tests shift checking to manual regression. | Count the environments to rebuild, the automated checkout and integration tests available, and who signs off each run. |
Questions buyers ask before hiring help for the 2.4.8 to 2.4.9 upgrade
How is the cost of a 2.4.8 to 2.4.9 upgrade set?
Cost follows the written scope. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the scope is shaped by your inventory of custom code, the number of extensions and the number of third-party integrations. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort, so those are the first items to inventory. DeployOpen does not publish a price list and gives a quote from the written scope. Work usually falls into one-time items (inventory, environment preparation, Composer and PHP changes, search engine and database changes, regression testing) and recurring items, such as patch cycles or support if you retain them. Ask for each item to be priced or estimated separately, with the assumptions behind it.
How long does a Magento 2.4.9 upgrade take?
Duration depends mainly on the inventory and on your test coverage. A store with few extensions and automated checkout tests moves faster than one with custom modules, several payment or ERP connections and manual test scripts. Adobe's lifecycle policy sets the end of regular support for 2.4.8 on May 31, 2028, so plan backwards from that date. A rehearsed upgrade needs staging runs, fixes and business sign-off before cutover, and each of those steps adds time. Ask any provider to list the dependencies behind its timeline and the test coverage it assumes. Confirm the 2.4.9 release details on Adobe's released versions page before you set internal dates.
What does our team need to provide for the upgrade?
Your team provides decisions, access and people. Business owners must sign off test results for checkout, pricing, promotions and the integrations that carry revenue. You need access to staging and production-like environments, code repositories, deployment pipelines, and the server or cloud accounts where the store runs. Extension vendors must be reachable, because each extension needs a 2.4.9 compatible version or a replacement decision, and only the vendor can confirm compatibility. Name a technical owner who approves changes, and make sure someone holds the credentials for payment, ERP and shipping connections. Write these responsibilities into the scope so testing does not wait on availability.
Can our in-house team upgrade Magento to 2.4.9 without a partner?
Yes, if the team has the right skills. An internal team can run the upgrade alone with skills in Composer upgrades, PHP and database changes, search engine changes and regression testing of checkout and integrations. Headcount matters less than these skills. Read Adobe's system requirements for 2.4.9 first, and run Adobe's Upgrade Compatibility Tool against your code as an early check. Be realistic about test coverage: without automated checks, the regression pass becomes the largest task. A partner is a sensible choice when a required skill is missing or when the team cannot protect a release window. DeployOpen plans, implements, tests and documents upgrades inside the client's own infrastructure, so the work can stay with your team, with partial help, or with a fixed-scope engagement.
What should we ask for in a quote for this upgrade?
Ask for a quote built on a written scope. A useful quote lists deliverables for the inventory of custom code, extensions and integrations, environment preparation, PHP, Composer, database, Redis or Valkey and OpenSearch 3 changes, extension and theme compatibility decisions, a regression test plan for checkout and integrations, cutover and rollback steps, and handover documentation. Ask which environments are in scope, which client responsibilities the price assumes, how change requests are priced, and which test coverage the timeline depends on. Ask what is one-time and what recurs, such as patch cycles, support or a retainer. Finally, ask who signs off each phase in writing. Compare quotes against the same scope, not against headline totals.
Which PHP, database and search versions does 2.4.9 require?
Adobe's 2.4.9 requirements list specific combinations. Adobe's system requirements for 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30, all on Linux x86-64. Adobe supports only the listed combinations, so an unlisted version is a risk to confirm before you accept it. Stores on 2.4.8 may run PHP 8.4 or 8.3, Elasticsearch or older database versions, and each of those needs a planned change. Check your current versions against both release lists. Confirm the final list on Adobe's system requirements page before you lock the target, because requirements can change. The 2.4.9 release notes also cite Symfony 7.4 LTS and a replaced OAuth library, which custom code may touch.
What happens if we wait until 2.4.8 support ends?
Waiting shrinks your testing window. Adobe's lifecycle policy sets the end of regular support for 2.4.8 on May 31, 2028. Adobe's release schedule says full patches for the 2.4.x LTS line ship annually in May, and security patches ship at least annually for all supported release lines. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. A store that delays the move still faces the same work later, with more release changes to absorb and less time to rehearse. Plan the upgrade against your own change calendar, schedule time for a staging rehearsal and a rollback test, and confirm the dates on Adobe's lifecycle policy before you commit.
How DeployOpen scopes and delivers the Magento Open Source upgrade
DeployOpen scopes the move from Magento Open Source 2.4.8 to 2.4.9 as a fixed-scope engagement, with the written scope agreed before work starts. Adobe lists the combinations it supports for 2.4.9, so the build targets that matrix in infrastructure you control. Each step is tied to the upgrade drivers Adobe names, including customizations, extensions, third-party integrations and coding practices.
How we scope
- The written scope lists every module, extension, theme and integration on the 2.4.8 store that must work on 2.4.9.
- Stack review covers PHP 8.5, Symfony 7.4 LTS, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30.
- Fixed-scope terms set deliverables and timelines in writing before work starts, and ongoing support is available as a retainer.
How we build
- Build a staging copy on the target stack, then run the Upgrade Compatibility Tool against custom code.
- Review custom modules and themes against the PHP 8.5 and Symfony 7.4 LTS changes in the 2.4.9 release notes.
- Rebuild search on OpenSearch 3 and check checkout, payment and third-party integrations after the switch, using regression test scripts.
How we hand over
- Handover includes the updated composer require-commerce steps, configuration changes and a record of every version deployed.
- Regression results for checkout, catalog search and integrations are documented, with any open issues listed by owner.
- Runbooks cover rollback to the 2.4.8 backup, Varnish cache settings for self-managed hosting and CSP configuration.
How we support
- Post-upgrade fixes for issues traced to the upgrade are handled under the agreed written scope.
- Ongoing retainers can cover patch-cycle upgrades, since Adobe recommends upgrading every patch cycle to stay secure and PCI compliant.
- Security testing of the upgraded store, including its APIs, is available as a separate scoped engagement.
