Why a 2.4.6 or older store needs a planned upgrade to upgrade Magento Open Source safely
A store running Magento Open Source 2.4.6, 2.4.5 or 2.4.4 should move to 2.4.8 or 2.4.9 as a staged project, with the target, the environment and the test plan agreed before any production change. These release lines are past standard support, so Adobe no longer provides regular fixes for them, and under Adobe's lifecycle policy 2.4.6 reached its end of regular support date on August 11, 2026. Confirm the end dates for 2.4.5 and 2.4.4 in the same lifecycle policy before you set the timeline, because the risk position depends on which line you run today. Staying on an older line is still a decision, and it should be recorded with its security and compliance cost.
Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. A store that has fallen several minor lines behind cannot follow that advice in small steps, because each security patch depends on a release line whose surrounding components may already have moved on. The practical question is which target to choose. The 2.4.9 release is the newest line in the researched facts, with end of regular support on May 31, 2029, and 2.4.8 remains supported until May 31, 2028. Choose between them based on the PHP version, search engine and extensions your team and your vendors can support for the period you plan to run the store, and write that choice down with its reasons.
Plan the path in general terms first: which intermediate release lines Adobe documents as supported steps, which code, configuration and data changes each step brings, and where the Upgrade Compatibility Tool fits in the assessment. Confirm the exact sequence in Adobe's upgrade guide for your starting version before you schedule anything. A jump across several minor lines is a rebuild of the environment as well as a code change. The target line can require a newer PHP runtime, a different database server, OpenSearch in place of Elasticsearch, a newer Valkey or Redis, RabbitMQ, Composer and nginx, and Adobe supports only the combinations it lists. Each of these is a server build, a configuration change and a test cycle, and the cache and search layers may need redesign too.
Start with an inventory the upgrade can be measured against. List every custom module, theme, third-party extension and integration, the Magento and PHP versions each depends on, and whether its vendor supports the target line. Adobe names customizations, extension count, third-party integrations and coding practices as the main drivers of upgrade effort, so these items will set the schedule and the quote. Ask any implementation partner for a written scope that lists the environment build, the code changes, the test runs and the cutover rehearsal as separate deliverables, so you can compare it with an internal estimate. The compliance side needs an owner too. PCI DSS v4.0.1 is the only active version, and the PCI SSC does not enforce compliance itself. Your payment brands and acquirer decide which obligations apply, so ask them how an unsupported platform will appear in your next assessment and whether any compensating or customized approach would be accepted while the upgrade runs.
What changes between 2.4.6 and 2.4.9 and what each change means for your store
This table lists the platform changes between 2.4.6 and the 2.4.8-p5 and 2.4.9 targets, with the impact on a self-managed store and the action each one needs. Read each row against your current stack, and check Adobe's system requirements for the exact supported combinations. The main takeaway is that the PHP, database and search engine changes usually drive the most work, because they affect code, data and reindexing.
| Change | Impact on your store | Action needed |
|---|---|---|
| PHP version | 2.4.9 requires PHP 8.5. 2.4.8-p5 supports PHP 8.4 or 8.3. Older custom code and extensions may fail on the new runtime. | Run custom modules and third-party extensions on the target PHP version in a test environment before cutover. |
| Database: MySQL or MariaDB | 2.4.9 lists MySQL 8.4, or MariaDB 12.3 (recommended) or 11.8. 2.4.8-p5 lists MySQL 8.4 or MariaDB 11.4 or 11.8. | Plan the database engine choice, then rehearse a data export and import. Confirm the exact version pairing in Adobe's requirements. |
| Search engine: OpenSearch 3 | OpenSearch 3 is the only search engine listed for 2.4.9. Stores still on Elasticsearch are not covered by the 2.4.9 requirements. | Migrate to OpenSearch 3 before the upgrade, then run full reindexing and search relevance checks. |
| Cache and sessions: Redis or Valkey | 2.4.9 lists Redis or Valkey 9. 2.4.8-p5 lists Redis or Valkey 8.1. | Upgrade the cache and session service to the listed version, then retest cache flushes and session behavior. |
| Queue, Composer and nginx | 2.4.9 and 2.4.8-p5 both list RabbitMQ 4.3, Composer 2.10 and nginx 1.30. | Update the message broker, build tooling and web server configuration, then check queue consumers and deployment scripts. |
| Varnish for full-page cache | 2.4.8-p5 lists Varnish 8 for self-managed installations. Cloud-hosted Adobe Commerce uses Fastly instead. | Confirm Varnish 8 fits your target stack, then retest page caching rules and cache purging. |
| Content Security Policy restrict mode | From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages. | Review inline scripts and third-party payment and analytics sources, then test payment pages before go-live. |
| Symfony 7.4 LTS | The 2.4.9 release notes cite support for Symfony 7.4 LTS, which custom code that uses Symfony components should be checked against. | Review custom code and extensions that depend on Symfony components for compatibility with the 7.4 LTS line. |
| clearCart GraphQL mutation | On 2.4.9 the clearCart mutation, previously Adobe Commerce only, is available in Open Source. | If your storefront or integrations need it, plan its use and test cart clearing through GraphQL. |
What an unsupported Magento store means for PCI DSS obligations
An unsupported Magento store does not fail PCI DSS by itself, but it changes what your assessor examines and how difficult the assessment becomes. PCI DSS applies to any entity that stores, processes or transmits cardholder data, and to any entity that could affect the security of that cardholder data environment. A merchant running Magento Open Source for checkout falls inside that scope whether or not the platform still receives vendor support. The PCI Security Standards Council maintains the standard but does not enforce it or impose penalties. The payment brands decide which entities must validate compliance and run enforcement programs, and your acquirer applies those decisions to your merchant account.
Confirm which version of the standard your assessment uses. PCI DSS v4.0.1 is the only active version, because v4.0 was retired on 31 December 2024 and v3.2.1 was retired on 31 March 2024. Of the 64 new requirements introduced in v4.0, 51 were future-dated and took effect on 31 March 2025. Any requirement that was optional before that date now applies to your store. Assessments are documented either on a Report on Compliance completed by a Qualified Security Assessor or on a Self-Assessment Questionnaire with an Attestation of Compliance. A certificate of compliance is not accepted as validation, so ask which document your acquirer expects to receive.
The upgrade does not produce a PCI result on its own. Moving from 2.4.6 to a supported release line removes an unpatched platform from your environment, but the assessor will still test the full cardholder data environment. That includes the web server, PHP runtime, database, search service, cache layer, admin accounts and the payment integration. Adobe's upgrade guide recommends taking every patch cycle to stay secure and PCI compliant, so treat patch cadence as a recurring control. Keep records of each patch applied, the test run that preceded it and the date it reached production.
Before the cutover, put three questions to your QSA or acquirer in writing. First, how an out-of-support platform is handled in your current assessment, and whether it will be recorded as a finding that requires a remediation plan and date. Second, whether a compensating control or a customized approach is acceptable for any requirement the platform cannot meet, and what evidence they expect, such as a documented risk analysis and a stated objective for each control. Third, which target release line and patch level your evidence must cover, and how staging and test environments are scoped. Get these answers before the build starts, because they shape the upgrade plan and the test evidence.
Preparing the store before the first upgrade build
Before any build runs against the target release, four records should exist and be signed off. Together they show what the store runs, how it can be restored, where it is tested and why each change was made. Each card names what to produce and who approves it, so the upgrade is planned from evidence and checked against it.
Inventory of custom and third-party components
List every custom module, theme and third-party extension in the codebase, with its vendor, installed version and the Magento Open Source release lines it has been tested against. Run the Upgrade Compatibility Tool that Adobe references in its upgrade guide, then record each component as compatible, needing changes or due for replacement. Extension count, custom code and third-party integrations are the main drivers of upgrade effort, so this inventory sets the size of the work. Output: a dated inventory with one status per component. Sign-off: the store owner and the lead developer.
Backup plan for data, code and configuration
Back up the database, the media directory, the custom code under version control and the settings for search, cache and queues. Record where each copy is stored, who may restore it and how long a restore takes, measured in a rehearsal. Search indexes can be rebuilt, but the configuration that points the store at its search engine, Redis or Valkey cache and RabbitMQ queues must be captured exactly. Keep at least one copy outside the production network. Output: a backup and restore runbook backed by a successful restore test. Sign-off: the infrastructure owner and the store operations lead.
Production-like test environment with governed data
Build a staging environment that matches production in PHP, database, search, cache, queue, web server and Varnish versions, so test results carry over to live. Load a copy of live order and catalog data only after personal data is masked or removed under your data protection rules, and document the basis for any personal data you keep. Card data should not enter this environment at all. Access should follow the same controls as production. Output: an environment record with component versions and a data handling statement. Sign-off: the privacy lead and the platform owner.
Decision log for replacements and customizations
Record every extension replacement, removal and customization in one log. Each entry names the original component, the chosen replacement or custom work, the reason, the owner and the test evidence that supports it. Keep each custom module and theme as a PSR-4 compliant module or theme in its own package, so the target release reads the same structure as the rest of the codebase. Link every entry to the inventory row it resolves. Output: a versioned decision log. Sign-off: the product owner for business decisions and the lead developer for technical design.
Upgrade sequence from 2.4.x to 2.4.9 with checks and rollback points
This sequence moves a self-managed Magento Open Source store from an older 2.4.x release to 2.4.9 with a parallel build, a rehearsed cutover and a named rollback point. Each step ends with a check that must pass before the next one starts.
Freeze the codebase and verify backups
Stop non-emergency code changes and merchandising releases, then take a full backup of the database, media directory, codebase and environment configuration. Restore that backup into a scratch environment and confirm the store loads, the admin signs in and the indexers and cron jobs can run. Output: a restore-tested backup and a documented baseline. Rollback point 0: production stays on the current release and nothing has been changed, so the store can continue as it is at any time until cutover.
Build the target stack in parallel
Provision a new environment that matches Adobe's system requirements for 2.4.9: 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 on Linux x86-64. Confirm each combination against Adobe's list, since Adobe supports only the listed combinations, and confirm with Adobe's current guidance whether your full-page cache will run Varnish. Check: a version report from every service, a clean install of an empty 2.4.9 project and the environment configuration recorded in version control. Rollback point 0 still applies because production is untouched.
Replace or port extensions and custom modules
Inventory every third-party extension, theme, language package and custom module, and record each vendor's support status for 2.4.9. Run Adobe's Upgrade Compatibility Tool against the codebase, replace extensions that have no 2.4.9 path and port custom modules to the PSR-4 structure and current APIs where needed. Resolve compatibility notices in the test environment and rerun the tool until no blockers remain open. Check: every module and theme installs and compiles on the new stack, and each replacement has a documented owner and test case. Rollback point 0 still applies.
Run the code upgrade in the test environment
Apply the upgrade to a test copy using the Composer and setup commands Adobe documents for the target release, then run the schema and data upgrade, dependency injection compilation and static content deployment. Keep the output of each command in the change record so any failure can be traced to a single step. Check: every command completes without errors, the admin and storefront load and the test database and code are snapshotted at this point. Rollback point 1 is this snapshot, which returns the test environment to its pre-upgrade state so the sequence can be rerun.
Reindex, rebuild cache and switch search
If the source store still uses Elasticsearch, point catalog search at OpenSearch 3, which Adobe lists for 2.4.9, then run a full reindex of every indexer. Clear and rebuild the cache and confirm Redis or Valkey is serving sessions and cache as configured. Check: all indexers report ready, product counts match the source catalog, sample searches return expected results and the merchandising team has reviewed relevance. Record the search engine change so it can be reversed in the test environment. Rollback point 1 still holds.
Test checkout, payments and integrations
Run end-to-end test orders for every payment method, shipping method, tax rule and promotion the store offers, covering both guest and logged-in checkout. Test each integration with ERP, tax, shipping, messaging and analytics services using test credentials, and confirm webhooks and queued messages are processed. Content Security Policy runs in restrict mode by default on payment pages from 2.4.7, so check that payment scripts still load and document any policy changes. Check: every test order reaches the expected status in the back office and downstream systems record it. Rollback point 1 still holds.
Repeat the full rehearsal on fresh data
Restore a recent copy of production data into a rehearsal environment and run the complete sequence again from the frozen baseline, using the same runbook, commands and checks. Record the duration of each step, every deviation from the runbook and every defect, then correct the runbook and repeat the rehearsal until a run completes with no failed checks. Check: a signed-off runbook, a defect list with no open blockers and a rehearsal log the cutover team can follow without improvising. Rollback point 1 remains the test snapshot.
Cut over and retain the old environment
Put the store into maintenance mode, take a final backup of production, sync the latest data into the 2.4.9 environment, run the approved commands from the rehearsed runbook, switch traffic and reopen the store. Rollback point 2 is the last moment before the switch, when the old environment is still the system of record and production data is unchanged. After the cutover is confirmed, the old environment becomes read-only and is retained intact. Check: smoke tests, a live test order, cron and queue processing and admin sign-in all pass.
How staged test runs and rollback protect the cutover
Staged test runs make the production cutover a repeat of steps the team has already executed, so the night of the move carries no unknowns. Plan three runs. The first run, on a copy of the store built on the target release, exists to find blocking errors: dependency conflicts, extensions that fail during setup or compilation, configuration that does not load, and cron jobs that stop. The second run repeats the upgrade with a full copy of production data, because reindex time and cache warm-up depend on data volume and cannot be read from a small sample. The third run is a rehearsal that follows the cutover runbook line by line, using the same commands, the same order, the same people and the same timing checkpoints. Run lengths depend on catalog size, extension count and integration count, so the team should measure each run in its own environment and treat any general figure as a starting point to verify, not a plan.
Regression testing for an upgraded store should focus on what loses money or orders if it breaks. Checkout comes first: guest and logged-in purchases, coupons, shipping method selection and any multi-currency or multi-store paths the business uses. Payment callbacks and webhooks from each gateway must be tested end to end, including refunds and declined payments, because they often fail silently. Tax and shipping calculations should be compared against the current production store using a fixed set of reference baskets, with the totals recorded before and after. Admin workflows such as order editing, product saves, invoice and shipment creation, and customer management need scripted checks. Finally, test the ERP and order feeds by confirming that exported orders and imported stock or price data carry the same fields, identifiers and formats. Content Security Policy deserves its own pass: from 2.4.7, CSP runs in restrict mode by default on payment pages, so a missing policy entry can block a hosted payment script or frame. Check the browser console on each payment page in staging.
Rollback triggers should be written down before the cutover starts, with a named decision owner for each. Triggers might include checkout failures that persist after the first fixes, payment callbacks that do not complete within an agreed window, tax or shipping totals that differ from the reference baskets, or an ERP feed that stops accepting orders. The thresholds are the team's decision, and they should be agreed with finance, operations and the payment provider in advance. Rollback also needs a tested path. Keep a verified database snapshot, the previous code release, media files and environment configuration, and confirm that the previous PHP and database versions can still run the old code. Schema changes made during an upgrade are not always reversible by simply restoring code, so the restore itself belongs in the rehearsal.
Data written after cutover must remain recoverable if the team rolls back. Orders, customer accounts, payment transactions and stock movements created on the new stack after the move are the records most at risk. Define a short freeze window for writes if the business can accept it, and decide how post-cutover data will be captured: a delta export of orders, customers and payment records, or an event feed to the ERP that runs during the cutover period. Assign an owner for reconciling those records against the payment provider's reports and the ERP after any rollback, and rehearse that reconciliation with sample transactions. Ask any implementation partner to show how the delta capture, rollback and reconciliation steps are documented, tested and timed in the written scope, and confirm with your own finance and operations teams which records they need to see first.
What makes a Magento Open Source upgrade take longer
This table lists the drivers that most often set how long an upgrade from Magento Open Source 2.4.6 or older takes, why each one adds effort, and how to size it. Ask a partner to size each driver from your own inventory and test results, so the estimate reflects your store. The main takeaway is that custom code, extensions and integrations usually shape the schedule more than the core upgrade steps.
| Driver | Why it adds effort | How to size it |
|---|---|---|
| Custom modules and theme overrides | Each module and override must be checked against 2.4.9 APIs, PHP 8.5 and Symfony 7.4 LTS, then tested in every affected flow. | Count modules and overrides by age and last change date. Flag any that touch core classes, checkout or payment flows. |
| Third-party extensions | Each extension needs a release that supports the target PHP and Magento version, or a replacement with its own configuration and tests. | Export the full list with installed and latest versions. Confirm 2.4.9 support in writing from each vendor. |
| ERP, payment, shipping and search integrations | Each connector has its own API versions, credentials and test accounts, and may need vendor sign-off before cutover. Search moves to OpenSearch 3 for 2.4.9. | List each connector, its owner, sandbox availability and vendor contact. Note every Elasticsearch connection that must change. |
| Catalog, order and customer data volume | Larger datasets lengthen reindexing, data patches and the staged test runs that measure cutover time. | Record row counts for products, orders and customers. Measure reindex duration on a recent production copy. |
| Coding practices in custom code | Adobe's upgrade guide names coding practices as an effort driver. Direct SQL, core file edits and deprecated patterns force rework. | Run the Upgrade Compatibility Tool and review a sample of custom code. Count findings by severity and by module. |
| Environments and approval gates | Each environment, such as development, staging, performance and production, repeats the upgrade. Each sign-off step adds scheduling time. | List every environment and approver. Confirm how long past approvals took and plan the cutover window with the partner. |
Questions buyers ask before upgrading a Magento Open Source store
How much does it cost to upgrade Magento Open Source from 2.4.6?
The price is set by the written scope, and no fixed figure applies to every store. Most of the cost is skilled labor, so the quote should break the work into phases.
One-time costs include discovery and inventory, PHP and database upgrades, extension and theme compatibility work, custom module changes, staged test runs, cutover and rollback rehearsal.
Recurring costs include each patch cycle, hosting and search or cache services, extension license renewals, and any retainer for ongoing support.
The main drivers are the number of customizations, extensions, third-party integrations and stores, plus the condition of the existing code. Ask for line items by phase, the assumptions about what your team supplies, and which items are fixed price and which are charged per change.
How long does a Magento Open Source upgrade usually take?
Duration depends on the scope, so no single duration applies to every store. The biggest factors are how much custom code exists, how many extensions and themes must be checked or replaced, and how many third-party systems the store calls during catalog, checkout and order flows. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of effort.
Other factors include the number of storefronts, the PHP and database version jumps, how many test cycles the business needs, and how quickly decision owners give sign-off. Ask for a phased schedule with the test cycles and cutover window written in, along with the dependencies that could move each date. Confirm the timing against the written scope before you commit to a launch date.
What does our team need to provide for an upgrade project?
Your team provides the facts and decisions the work depends on. These fall into four groups.
Inventory: installed modules and extensions with their versions, custom modules and themes, third-party integrations for payment, shipping, ERP and search, server and PHP configuration, and scheduled jobs and queues.
Access: source control, a staging environment, read access to production logs and configuration, and admin accounts for test runs.
Test data: anonymized or synthetic catalog, customer and order samples that cover your product types, tax rules and payment methods.
Decision owners: named people who approve the scope, extension replacements, the target release, the cutover window and the rollback criteria. Adobe's upgrade guide also references the Upgrade Compatibility Tool, which is a useful starting point for the inventory.
Can an in-house team upgrade Magento Open Source without outside help?
Often yes, if the team already maintains the store and has completed a major Magento upgrade before. An internal team can usually run the work if it has engineers who know Magento modules, PHP upgrades, database changes and search engine changes, and if it has time for repeated staged test runs. The harder part is usually capacity and separation of duties.
Check these points before you decide: whether the team has a rehearsed rollback, how it will test checkout and payment flows, who owns the PCI DSS evidence, and whether it can keep the store patched after launch. Ask any partner for the same inventory and test plan so you can compare the work you would take on with the scope a partner would deliver. DeployOpen plans, implements, tests and documents upgrades in infrastructure you control, under a written scope, so you can decide how much of the work to hand over.
Should we upgrade to Magento 2.4.8 or 2.4.9?
For most stores planning now, 2.4.9 is the stronger target if your extensions and infrastructure can support it, because it has the longest standard support window. Adobe's lifecycle policy gives 2.4.9 standard support until May 31, 2029, and 2.4.8 until May 31, 2028.
Adobe's 2.4.9 requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30. The 2.4.8-p5 requirements list PHP 8.4 or 8.3, MySQL 8.4 or MariaDB 11.4 or 11.8, OpenSearch 3, Redis or Valkey 8.1, RabbitMQ 4.3, Composer 2.10, nginx 1.30 and Varnish 8.
Choose 2.4.8 if a critical extension or theme cannot yet run on PHP 8.5. Confirm each extension's compatibility, and confirm your full-page cache plan, before you decide, because the 2.4.9 requirements list does not include Varnish.
Does upgrading Magento Open Source make our store PCI DSS compliant?
No. An upgrade does not make a store compliant by itself. PCI DSS applies to entities that store, process or transmit cardholder data, or that could affect the cardholder data environment. The payment brands decide who must validate and run any enforcement. Validation is documented either through a Report on Compliance completed by a Qualified Security Assessor or through a Self-Assessment Questionnaire, each with an Attestation of Compliance.
What the upgrade changes is your ability to meet requirements that depend on supported, patched software. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. Assessors will also examine configuration, access control, logging and the controls around your payment flow. DeployOpen prepares systems and evidence for an assessment, but independent assessors issue the reports and attestations. The current version is PCI DSS v4.0.1, and v4.0 was retired on 31 December 2024.
What risk does staying on Magento 2.4.6 create after end of support?
Adobe's lifecycle policy set the end of regular support for 2.4.6 on August 11, 2026, so the line no longer gets the standard support window that newer lines receive. Risk grows over time because PHP, database and search components keep moving forward, and extensions that stop working on newer PHP versions can block a security patch.
Ask three questions to size your exposure. Which security patches does your edition still receive on this line? Which extensions have an upgrade path, and which are abandoned? Do your payment and checkout flows depend on components that are no longer supported? Confirm the patch coverage directly with Adobe or your licensing terms, since the lifecycle policy sets the dates but not your specific entitlements. Document the decision and the interim controls so auditors and leadership can see the plan.
How DeployOpen scopes, delivers and supports a Magento Open Source upgrade
DeployOpen plans, implements, tests, documents and supports self-hosted Magento Open Source upgrades inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For stores on 2.4.6, 2.4.5 or 2.4.4, the work starts with a written scope that sets the target release, PHP and database changes, and extension replacements before any build begins.
How we scope
- The written scope names the target release, such as 2.4.8 or 2.4.9, and the reason for that choice.
- It inventories custom modules, themes, extensions and third-party integrations, since these drive upgrade effort.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- PHP, database, search and cache changes are mapped against Adobe's system requirements for the chosen release.
- Custom modules and themes are ported to the target release, following the PSR-4 structure Adobe documents for extensions.
- Staged test runs cover checkout, payments, search and integrations before a rehearsed production cutover.
How we hand over
- Handover includes the upgrade runbook, rollback steps and the verified configuration of each environment.
- Test results, extension decisions and changes to cache, search and PHP settings are documented for your team.
- Where a PCI DSS assessment follows, DeployOpen prepares the evidence and does not issue audit reports or attestations.
How we support
- Ongoing support, patch application and upgrades to later release lines are available as a retainer.
- Patch cycles are monitored so that security fixes in each release line can be applied on Adobe's schedule.
- Continuous testing can run alongside the store after go-live, under the retainer or a separate written scope.
