Why plan the Magento Open Source upgrade from 2.4.7 now
If your store runs Magento Open Source 2.4.7, the date that governs your plan is May 31, 2027, when Adobe's standard support for that release ends. That gives you a fixed window to move, and the window is shorter than it looks once you account for codebase review, extension checks, infrastructure changes and a rehearsed cutover. Starting the planning work now leaves room to choose a target and test it properly rather than discovering problems in the final months.
Magento Open Source 2.4.9 was released in May 2026, and Adobe's lifecycle policy gives it standard support through May 31, 2029. Release 2.4.8 runs to May 31, 2028. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, so the choice between 2.4.8 and 2.4.9 is mainly a question of how long you want the next upgrade to hold and how much platform change you can absorb in one project. Your team should compare the system requirements of each target before deciding, because the PHP, database, search and cache components differ between them.
Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. Staying on 2.4.7 until its end of support means that security fixes shipped after that date will not reach your store, and that position will need to be explained to your QSA or internal assessors. Confirm the supported upgrade path from 2.4.7 to your chosen target in the Adobe upgrade guide, and do not assume that a direct jump is supported until you have read the path for your exact versions.
The effort of the move depends on your own code. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers. Run the Upgrade Compatibility Tool against your codebase, not a sample, and record every flagged module, theme and integration. The output sets the scope for extension replacements, theme fixes and test cases, and it gives you the evidence to ask a partner or your own team for a realistic written estimate.
What changes between 2.4.7 and 2.4.9
This table compares what changes between Magento Open Source 2.4.7 and 2.4.9 and what each change asks of your team. Read each row against your current PHP, database, search, cache and payment setup, because the impact depends on which of those you run. The main takeaway is that the runtime, search and content security changes are the most likely to break a live store, so they need staging tests before cutover.
| Change | Impact | Action needed |
|---|---|---|
| PHP 8.5 and Symfony 7.4 LTS | The 2.4.9 release notes cite official support for both. Adobe's 2.4.9 requirements list PHP 8.5, while 2.4.8-p5 lists PHP 8.4 or 8.3. | Confirm your extensions, themes and custom code run on PHP 8.5 before cutover. |
| 580 resolved core code issues | The release notes count 580 resolved issues in core code. Overrides and patches to core files may conflict with these fixes. | Compare your overrides and patches against the 2.4.9 release notes and retest affected areas. |
| clearCart GraphQL mutation | Previously available only in Adobe Commerce, it is now available in Magento Open Source. | Decide whether your storefront or headless front end will call it, then test cart behavior. |
| 2.4.9 software requirements | Adobe lists 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. | Build target servers only on the listed combinations, since Adobe supports only those. |
| Linux x86-64 only | Adobe's 2.4.9 requirements apply to Linux x86-64 in the listed combinations. Other operating systems fall outside that support statement. | Confirm your host operating system and architecture before ordering or building infrastructure. |
| Elasticsearch no longer listed | The 2.4.9 requirements list OpenSearch 3 for search, so Elasticsearch is not a listed target. | Provision OpenSearch, reindex the catalog and check search relevance before cutover. |
| CSP restrict mode from 2.4.7 | Restrict mode runs by default on storefront and admin payment pages, so custom payment and admin scripts may be blocked. | Inventory inline and third-party scripts, then test payment and admin pages in restrict mode on staging. |
| Varnish not listed for 2.4.9 | The 2.4.9 requirements do not show Varnish, while 2.4.8-p5 lists Varnish 8 for self-managed installations. | Confirm with Adobe whether your full-page cache stays in scope and which version you must run. |
| Your 2.4.7 starting point | Your current PHP, database and search versions determine how far each component must move. | Confirm these versions in your environment and against Adobe's 2.4.7 requirements before planning the upgrade path. |
Choosing 2.4.9 or 2.4.8-p5 as the target release
The choice between 2.4.9 and 2.4.8-p5 turns on how far your PHP version and extension stack can move in one step. Adobe's released versions page lists both 2.4.9 and 2.4.8-p5 as released on May 12, 2026. Magento Open Source 2.4.9 is the target for this topic. Its system requirements list PHP 8.5, and Adobe's lifecycle policy gives it standard support until May 31, 2029. Magento Open Source 2.4.8-p5 lists PHP 8.4 or 8.3, and its standard support ends May 31, 2028. Both lines use OpenSearch 3, Valkey and RabbitMQ 4.3, so the real difference for most stores is the PHP runtime and the length of the support window that follows.
Extension compatibility with PHP 8.5 decides how far you can go. Before you pick a target, list every third-party module and theme in your codebase and record each vendor's written statement on support for Magento Open Source 2.4.9 and PHP 8.5. Also check any custom modules that depend on Symfony components, since 2.4.9 supports Symfony 7.4 LTS. Run Adobe's Upgrade Compatibility Tool against your custom code to surface deprecated calls and removed interfaces. If a payment, ERP or tax extension cannot run on PHP 8.5, 2.4.8-p5 on PHP 8.4 may be the only path for the cutover, but confirm the extension's support for that exact combination before you commit to it.
Your full-page cache setup also belongs in this decision. Adobe's documentation describes Varnish as the full-page cache accelerator for self-managed installations, and the 2.4.8-p5 requirements list Varnish 8. The 2.4.9 requirements in Adobe's system requirements page do not list Varnish, so ask Adobe and your hosting team whether your current Varnish version and VCL configuration stay supported on 2.4.9 before you assume the cache layer carries over unchanged. Record the answer in the same document as your extension audit, because a cache change can affect how you test checkout, catalog pages and the admin.
Preparing the store before the first upgrade run
Most failed Magento upgrades were decided before anyone ran the upgrade command. The four areas below set the baseline you need before a build starts, and each one feeds the next: a verified backup makes a rehearsal safe, an accurate inventory defines what the rehearsal must test, a mirrored environment shows what breaks, and a vendor list shows which integrations you cannot upgrade on your own timetable.
Full backup with a tested restore
Take a complete copy of the codebase, the database and the media directory, taken at the same point in time so the three match. A backup that has never been restored is a hope, not a rollback plan. Restore it into a separate environment, confirm the store loads, orders can be placed in a test payment mode, and the admin login works. Record how long the restore took, because that figure sets the real maintenance window for cutover.
Inventory of customizations and extensions
List every custom module, third-party module, theme and language package in the installation, and note which Composer package or folder each one comes from. Adobe's developer documentation describes modules, themes and language packages as the component types that extend Magento Open Source, and modules follow a PSR-4 structure. Flag any module that edits core files, overrides core classes or has no active maintainer. Those are the items that most often block a 2.4.9 build and drive the upgrade effort Adobe describes.
Test environment that mirrors production
Build a non-production environment with the same PHP, database, OpenSearch, Valkey and RabbitMQ versions as production, plus the same web server and caching layer. Adobe's 2.4.9 requirements list PHP 8.5, MariaDB or MySQL, OpenSearch 3, Valkey 9 and RabbitMQ 4.3, and Adobe supports only the listed combinations. Copy production data and configuration, then confirm that cron, indexers and message queue consumers all run. A test stack that differs from production in one service will hide the failures you most need to find.
Third-party integration and vendor compatibility list
Record every payment, shipping, ERP and tax integration, the module or API that connects it, and the vendor contact who owns it. For each one, obtain the vendor's written statement of compatibility with Magento Open Source 2.4.9, PHP 8.5 and the new search and cache services before the build. Some vendors certify a single release line, and some require a connector update that must be scheduled. Treat any integration without a confirmed statement as a blocking item on the project plan.
How the search, cache and queue services change under 2.4.9
The 2.4.9 requirements list OpenSearch 3 and no Elasticsearch, so a store still on Elasticsearch has to provision an OpenSearch cluster and reindex the catalog as part of the move. Treat this as its own workstream with its own cutover decision. Run the new cluster alongside the existing Elasticsearch service until the index passes relevance checks, then switch the catalog search engine setting. Follow the sibling Elasticsearch to OpenSearch migration page for the provisioning, setting change, full reindex and relevance steps. This section explains where search fits in the overall sequence.
Cache and session storage move to Valkey 9 or Redis, both of which appear in the 2.4.9 requirements. Confirm which one your hosting provider or platform team runs, and confirm that the exact version is on the Adobe list before you order or build it. Session storage and the cache backends both point at this service in the environment configuration, so a version change here affects logins and cart state as well as performance. Test with a flushed cache and sessions observed under realistic load, and keep the previous service available until checkout and admin login have been verified.
RabbitMQ 4.3 carries the message queues used by asynchronous operations and bulk tasks. Check every consumer and any custom publisher your extensions register, because queue names and consumer configuration live in module code that you are upgrading along with the platform. The database move is a separate change: the requirements list MySQL 8.4, MariaDB 12.3 (recommended) or MariaDB 11.8. Choose one target, then confirm that your extensions, your hosting environment and your backup tooling support it before the test environment is rebuilt.
Each of these is a separate change with its own rollback point. Changing search, cache, queue and database in one window makes it hard to tell which component caused a failure, so schedule them as distinct steps with a verified backup taken before each one. Adobe supports only the combinations listed for 2.4.9, so confirm the full set of PHP, database, search, cache, queue, Composer and nginx versions against the Adobe system requirements page for the exact release you are targeting. Record that matrix in the upgrade plan, and ask your hosting or platform team to confirm they can roll back each service independently.
The upgrade sequence from 2.4.7 to 2.4.9
This sequence moves a Magento Open Source 2.4.7 store to 2.4.9 in eight ordered steps, each with a verification and a rollback point. The production cutover repeats a rehearsed runbook, so the team is not testing the process for the first time on live traffic. Exact commands come from the Adobe upgrade guide for 2.4.9.
Freeze the codebase and take backups
The store owner and the project lead agree a code freeze on the 2.4.7 codebase, with no direct changes to the live store until cutover. Take a full backup of the codebase, the database, media files and environment configuration, including env.php, and store copies outside the server. Restore the backup to a separate host to confirm it is usable. The step is done when a restore has been tested and the freeze is recorded in writing.
Run the Upgrade Compatibility Tool
Run Adobe's Upgrade Compatibility Tool against your custom modules, themes and extensions to list findings for the target version. Assign each finding either to a fix in custom code or to a vendor update, and record each decision in the project backlog. Developers resolve custom code findings on a branch and rerun the tool until no open findings remain for custom code. The step is done when the report is clean for custom code and every extension has a confirmed compatibility statement for 2.4.9 from its vendor.
Upgrade runtime and backing services in test
In the test environment, move the stack to the versions Adobe lists for 2.4.9, including PHP 8.5, Composer 2.10, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Valkey 9, RabbitMQ 4.3 and nginx 1.30 on Linux x86-64. Restore the database onto the chosen engine, point the cache at Valkey and the search engine at OpenSearch 3, and confirm your Varnish version against Adobe's list if you use it. The step is done when every service starts, accepts connections and logs no errors. Rollback: rebuild the test environment from the frozen backup.
Update composer requirements and resolve conflicts
Update the codebase with the Composer requirements that Adobe specifies for 2.4.9, using the exact commands in the upgrade guide for that version. Resolve dependency conflicts by updating or replacing extensions, and document each replacement along with the vendor's compatibility statement. Commit the updated composer.json and composer.lock to version control. The step is done when Composer resolves on a clean checkout without errors and the lock file is committed. Rollback: revert the commit and return to the frozen codebase.
Run setup upgrade, compile and reindex
Run the setup upgrade, compile and reindex commands from the Adobe upgrade guide for 2.4.9 in the order given there, on a restored copy of production data. Review the output for module errors and failed schema or data scripts, and fix those in custom code before continuing. Check that the admin loads, the indexers report ready and a storefront product search returns results from OpenSearch. The step is done when all commands finish without errors and the full reindex completes. Rollback: restore the test database from backup and rerun.
Apply theme and CSP changes
Recompile theme assets and resolve the theme's compatibility findings against 2.4.9. Content Security Policy runs in restrict mode by default on storefront and admin payment pages from 2.4.7, so review every third-party script, tag, payment widget and analytics tag. Add approved sources to the policy configuration and keep the policy enabled. The step is done when checkout and payment pages show no blocked resources from approved vendors and the browser console reports no policy violations.
Run regression and load checks, then rehearse
Run the regression suite across catalog, cart, checkout, payments, shipping, customer accounts, admin order handling and each integration, and fix failures before load testing. Run load checks on a staging copy sized to match production, using traffic patterns agreed with the business. Rehearse the full cutover at least once on a copy of production, timing each step and recording every command. The step is done when the regression suite passes, load results meet targets agreed in writing and the rehearsal ends with a documented runbook.
Perform the production cutover with rollback
Place the store in maintenance mode, take a final backup of the database and media files, and apply the rehearsed runbook in its recorded order. Run the same health checks used in rehearsal, including test orders through checkout and payment, storefront search and admin access. Set the rollback trigger before starting: if any check fails, restore the final backup and the 2.4.7 codebase snapshot, then reopen the store. The step is done when all health checks pass on 2.4.9 and post-cutover monitoring is active.
Testing checkout, integrations and rollback before cutover
Cutover should happen only after a rehearsed test plan has passed on a copy of production, and the go or no-go decision should be written down before the first rehearsal starts. For a move from Magento Open Source 2.4.7 to 2.4.9, the plan has to cover the storefront, the admin, the connectors and the search layer, because a change to PHP 8.5, OpenSearch 3 or Valkey can fail in any of them even when the code upgrade itself succeeds. Start with functional regression across catalog, cart, checkout, payment, tax, shipping and admin workflows. Use the same test scripts for every rehearsal so that results are comparable. Run integration tests for each ERP, payment and shipping connector against sandbox endpoints, and confirm that order export, stock updates, refunds and tracking numbers still flow in both directions. If the store uses the clearCart GraphQL mutation, test it explicitly. The 2.4.9 release notes describe it as newly available in Open Source after being limited to Adobe Commerce, so a storefront that calls it through a custom or third-party client should be checked against the new build. Search needs its own checks. Compare relevance for a fixed set of queries (brand names, misspellings, category terms and filtered searches) before and after the move to OpenSearch 3, and record how long a full reindex takes on your catalog. Also run Content Security Policy checks on storefront and admin payment pages. Adobe's developer documentation states that CSP runs in restrict mode by default from 2.4.7, so any inline script or third-party payment frame that worked before may now be blocked and must be reviewed.
The rehearsal cycle should repeat the full sequence (backup, code and dependency upgrade, database upgrade, reindex, test run) until two consecutive runs produce the same results. Each run should produce a timing log for every step. How long these steps take depends on your catalog size, order history, index volume and the number of extensions to recompile, so the duration must be measured in your own environment on a copy of production data. Treat any estimate from a vendor, a partner or a community post as a starting point only. Define the go or no-go criteria before the rehearsal begins. Typical criteria include: zero open severity-one defects in checkout and payment, every connector passing its integration suite, search relevance within a threshold the merchandising team has agreed, a full reindex completing inside the cutover window, CSP violations resolved or formally accepted, and a restore drill that has been completed successfully. The thresholds are your decisions, and they should be signed by the business owner, not left to the engineering team alone. Rollback must restore code, database and search indexes together. Restoring only the code leaves a database schema the older release cannot read, and restoring the database without the matching OpenSearch snapshot leaves product search pointing at the wrong data. Take a consistent backup of all three before cutover, record the exact versions of PHP, MariaDB or MySQL, OpenSearch and Valkey, and rehearse the restore on a separate environment until it completes within the window you have agreed.
What makes the upgrade take longer or cost more
This table lists the factors that usually lengthen a 2.4.7 to 2.4.9 upgrade or raise its cost. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of effort. Read each row as a question to answer in your own codebase and environments before you request a quote.
| Driver | Why it matters | What to check |
|---|---|---|
| Custom modules and core overrides | Modules that replace core classes through preferences or rewrites must be re-tested against 2.4.9 code, and each override adds review work. | List every custom module, its version and each di.xml preference or core class rewrite. |
| Number of extensions and 2.4.9 support | Each third-party extension needs a release that declares 2.4.9 compatibility, or a replacement that does. | Ask each vendor for its 2.4.9 release date and check Composer constraints for PHP 8.5. |
| Themes and frontend changes | Custom themes, Page Builder content and inline scripts must work under Content Security Policy restrict mode, the default on storefront and admin payment pages since 2.4.7. | Test checkout, payment pages and third-party scripts under the CSP settings you run in production. |
| Third-party integrations | ERP, payment, shipping and messaging connectors depend on vendor support for the new PHP, database and search versions. | Confirm each vendor supports 2.4.9 with PHP 8.5, OpenSearch 3 and Valkey 9 as listed in Adobe's requirements. |
| Coding practices in custom code | Direct object manager calls, raw SQL, hard-coded paths and deprecated APIs take longer to locate and fix when they sit outside dependency injection. | Run the Upgrade Compatibility Tool and a static analysis scan, then count findings by module. |
| Catalog and order data volume | Large catalogs and order histories extend full reindexing, data patches and rehearsal runs, and those steps scale with row counts. | Record product, customer, order and index row counts per environment and time a full reindex on a production copy. |
| Number of environments and rehearsal cycles | Each environment and each rehearsal repeats the build, data refresh and test pass, so a short rehearsal plan usually carries more cutover risk. | Agree how many staging environments and rehearsal runs the plan needs, and who owns each one. |
| Varnish or Fastly decisions | Self-managed stores typically use Varnish, which needs VCL and cache rules checked for the new release, and a move to another cache layer is a separate project. | Confirm the Varnish version in the 2.4.9 requirements, review custom VCL and decide whether to keep Varnish. |
Questions buyers ask before upgrading Magento Open Source
How much does a Magento Open Source 2.4.7 to 2.4.9 upgrade cost?
The cost follows from a written scope, so no single figure applies to every store. The quote is built from the work each component needs. DeployOpen is paid for planning, module and theme changes, integration rework, test support and cutover. Your team carries store-side sign-off time and any fees for extensions you keep or replace. One-time costs include the upgrade project, staging environments and any extension replacements. Recurring costs include hosting for the new stack and any patching or support you retain afterward. The main drivers are the number of custom modules and themes, the extension count and whether each extension has a release compatible with 2.4.9, the third-party integrations (ERP, payment, shipping), and the number of environments. Ask for line items per component, the stated assumptions, the exclusions and the test plan behind each line.
How long does a Magento Open Source 2.4.9 upgrade take?
Duration depends on the scope you agree, mainly on how much custom code and how many extensions must be ported, tested and verified again. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main effort drivers. Other factors include how many integrations need their own test window, whether the PHP 8.5 move and the switch to OpenSearch 3 are scheduled together, how quickly extension vendors release compatible versions, and how many test rounds your business owners need. Plan for at least one full rehearsal of the cutover on a copy of production data. The end of standard support for 2.4.7 on May 31, 2027 is the external deadline, so work backward from it. Ask for a phased schedule with milestones and a list of dependencies that could move the dates.
What does the upgrade need from our store and development teams?
Three groups carry most of the effort. Store owners sign off test scenarios such as checkout, promotions, tax, returns and catalog views, and they approve the cutover. Developers own custom modules and themes, review compatibility fixes and merge the changes. Integration owners for ERP, payment, shipping and messaging confirm endpoints, credentials, test accounts and reconciliation reports. Name one accountable decision maker and one rollback approver as well. Plan availability for these people across the test rounds and the cutover window, since a missing sign-off is a common cause of delay. Record who owns each acceptance step in the written scope so that sign-off responsibility is clear before work begins.
Can our internal team upgrade Magento Open Source to 2.4.9 without a partner?
Yes, an internal team can run the upgrade alone if it has the skills and time for the work. Adobe's upgrade guide and the Upgrade Compatibility Tool are the starting points. A documented plan and a tested rollback are what make the upgrade safe to attempt. Your team needs Magento and PHP skills, Linux and nginx administration, database and search cluster experience, and someone who can run performance and regression tests. Before starting, confirm three things: whether your extensions have 2.4.9 compatible releases, whether you can provision the required PHP, database, OpenSearch and Valkey versions in your environments, and whether you have a staging copy of production data. If any of these is missing, a fixed-scope engagement with a partner may reduce rework.
What happens if our store stays on Magento 2.4.7 after May 31, 2027?
Standard support for 2.4.7 ends on May 31, 2027, and after that date Adobe's regular support and fixes for that release line stop. Adobe recommends upgrading every patch cycle to stay secure and PCI compliant. PCI DSS expects you to protect system components from known vulnerabilities, which in practice means applying security patches within the timeframe your assessor accepts. A store on an unsupported line has to find that protection elsewhere, and it may struggle to pass an assessment. Ask your QSA or acquiring bank how they treat an unsupported release and what evidence they expect. Start the move before the deadline so that security patch releases can still be tested and applied during the project.
Is Mage-OS a viable alternative to upgrading Magento Open Source?
Mage-OS may be an option if you want a community-maintained path. It is a community-owned distribution built on Magento Open Source and run by the Mage-OS Association. Its project describes it as upstream compatible with Magento 2 extensions and lists releases that port Adobe security patches. Moving to it changes who you depend on for releases, advisories and the upgrade path, so the decision belongs in your vendor and risk review. Confirm the fit for your store before choosing it: that each extension you rely on is supported on the Mage-OS release you would target, that your payment connectors, ERP integrations and any Adobe-specific features work there, the release cadence and security advisory process, and how your hosting and support contracts apply. Ask for a written compatibility check.
What usually breaks during a Magento Open Source 2.4.7 to 2.4.9 upgrade?
The most common failures come from the platform stack and from custom code. Extensions and custom modules that rely on PHP behavior removed by PHP 8.5 fail first, so run static checks and the Upgrade Compatibility Tool early. Search is the next risk: moving from Elasticsearch to OpenSearch 3 requires a new cluster, a full reindex and relevance checks, and reindex time can surprise teams. Valkey 9 cache settings, MariaDB or MySQL configuration and Composer dependency conflicts also cause build failures. Content Security Policy already runs in restrict mode by default on payment pages from 2.4.7, so test payment iframes and third-party scripts carefully. For self-managed installations, check Varnish configuration as well. Ask for regression results covering checkout, payments and integrations before approving cutover.
How DeployOpen scopes and delivers the upgrade
DeployOpen plans the move from Magento Open Source 2.4.7 to 2.4.9 as a fixed-scope engagement inside your own infrastructure. The work starts with a written scope covering PHP, database, search, cache and extension changes, then moves through a rehearsed cutover with documented handover and optional ongoing support.
How we scope
- Inventory your current 2.4.7 stack, including PHP, database, search engine, cache and message queue versions
- Map every custom module, theme and third-party extension against 2.4.9 compatibility and flag replacements
- Confirm the target stack against Adobe's 2.4.9 system requirements, including PHP 8.5 and OpenSearch 3
- Agree in writing which environments, test runs and cutover rehearsals the engagement includes
How we build
- Stand up staging copies of production with sanitized data and the target PHP, database and OpenSearch versions
- Run the Upgrade Compatibility Tool and resolve code findings in custom modules and themes
- Rebuild the search index on OpenSearch 3 and verify catalog search relevance against baseline results
- Test checkout, payments, shipping, admin workflows and integrations in repeated rehearsal runs
How we hand over
- Deliver a written runbook with the exact cutover order, rollback steps and go or no-go criteria
- Document the final version of every module, extension and configuration change made during the upgrade
- Provide test evidence from each rehearsal so your team and any assessor can trace what was verified
- Walk your operations and development staff through the new stack, patch process and monitoring
How we support
- Agree post-cutover monitoring and bug-fix windows as part of the written scope before cutover begins
- Offer ongoing support, upgrades and testing as a retainer if you want continued help with Adobe's patch cycles
- Plan the next patch review so 2.4.9 security releases are applied on the schedule your team agrees
- Confirm with your team and Adobe's release schedule how long your store stays on each supported line
