What upgrades and support involve for Magento Open Source
Every Magento Open Source 2.4.x release has a fixed end of regular support date, and a store that stays on an unsupported line stops receiving the fixes it depends on. Adobe's lifecycle policy gives each release three years of standard support from general availability. The dates to plan around are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Confirm the current dates on Adobe's lifecycle policy page before setting a plan, because the schedule governs when the upgrade project must finish.
Routine maintenance is more than applying code. Adobe ships a full patch for the 2.4.x LTS line each year in May, and security patches arrive at least annually for every supported line. Each target release also fixes a set of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx versions that Adobe supports together. Check the system requirements for the exact target patch before you change any one component, because a PHP upgrade alone can break a store whose other services sit outside the supported combination.
Five events usually start the work: an approaching end of support date, a new release that requires a newer PHP version, a security advisory, an extension that stops working after an update, and a patch that fails in staging. Each trigger calls for a different response. A security advisory needs a patch window within days, while an end of support date allows planning time. Record which trigger started each change so the upgrade log shows why the store moved.
A team with deep Magento and PHP experience can run upgrades in-house, provided it has a staging environment that mirrors production and time to test checkout and payments. Teams without that depth often outsource the upgrade project, with the scope and extension compatibility review agreed in writing first, and keep routine patch application internal. This page covers Magento Open Source running in the client's own infrastructure. It does not cover Adobe Commerce cloud operations.
What the work includes
A fixed-scope upgrade produces a defined set of deliverables, while support covers recurring items that are priced and agreed separately. Both are confirmed in writing before work starts.
Baseline inventory
The starting point is a written inventory of custom code, installed extensions, third-party integrations, PHP and service versions, and the hosting layout. Check that it covers cron jobs, indexers, payment and ERP connectors, and any hand-edited core files, because these are the items most often missed and the ones that break first after an upgrade.
Target version and version matrix
The target is chosen against Adobe's published system requirements for the release, which list supported PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx combinations. Confirm each component's version against the matrix before committing, since Adobe supports only the listed combinations and a platform upgrade often forces service upgrades too.
Compatibility report
The report combines output from Adobe's Upgrade Compatibility Tool with a manual review of custom modules, themes and extension code. Automated results show known deprecations, while manual review catches patterns the tool does not flag. Ask for the report to list each finding with its owner, severity and proposed fix.
Extension remediation plan
Each third-party extension is marked keep, update, replace or remove, with the reason and the effort it implies. Ask whether vendor support exists for the target version, whether a replacement is maintained, and who approves a change in business behavior.
Rebuilt staging environment
Staging is rebuilt to match production topology, including the web, database, search, cache and queue tiers, and loaded with a recent copy of production data handled under your data protection rules. A staging environment that differs from production makes rehearsal results unreliable, so confirm how closely it matches before the rehearsal.
Upgrade rehearsal and regression testing
The upgrade runs on staging at least once with a timed log of each step, followed by regression tests on checkout, payments, customer accounts, catalog, search, and integrations. Each rehearsal result feeds back into the runbook. Ask which test cases are automated, which are manual, and who signs off each area.
Cutover runbook and rollback plan
The runbook lists every production step, its owner, the go or no-go checks, and the maintenance window needed. The rollback plan states the conditions for reverting, how database and file state are restored, and how orders placed during the window are reconciled. Confirm that the backup used for rollback has been restored successfully in a test.
Handover documentation
The handover pack covers the final architecture, configuration decisions, custom module and theme notes, extension register, runbook for the next patch cycle, and known open items. Check that it is written for your internal team, so that routine patching and troubleshooting do not depend on the people who delivered the upgrade.
Post-upgrade monitoring
Monitoring is set on error logs, checkout conversion signals, indexer status, cron health, and cache and search performance for an agreed period after cutover. Confirm what is watched, who is alerted, and how long the watch lasts. Ongoing monitoring of patches and security advisories is a separate support item.
One-time project versus ongoing support
The upgrade is a one-time project with defined deliverables and an agreed end. Support covers recurring items such as applying patch releases, monitoring security advisories, and retainer coverage for urgent fixes. Ask for each in a separate line of the quote so you can see what ends and what continues.
What drives upgrade cost and duration
This table lists the factors that raise or lower the effort of a Magento Open Source upgrade, why each one matters and what keeps it manageable.
| Driver | Why it raises effort | What reduces it |
|---|---|---|
| Customizations | Every custom module, theme change and checkout or catalog change must be retested against the new core release, and changes to core-adjacent behavior are the most likely to break. | Keep customizations in custom modules that use documented extension points, and keep a list of every override so the team knows what to check first. |
| Extension count | Each third-party extension has its own release cycle and compatibility with the target PHP and core versions, so more extensions mean more vendors to wait on and more regression testing. | Run an extension audit before the upgrade, remove unused or overlapping extensions, and confirm target-version support in writing from each vendor. |
| Third-party integrations | ERP, payment, shipping and tax connectors depend on API contracts, certificates and client libraries that may change alongside the platform, and each needs an end-to-end test after the upgrade. | Document each integration's endpoints, credentials and data flows, and pin or version client libraries so changes are deliberate. |
| Coding practices | Code that calls core classes directly, uses preferences to replace core classes or edits vendor files makes upgrades a rewrite instead of a review. | Use plugins, observers and preferences sparingly, follow the PSR-4 module structure, and avoid editing files under the vendor directory. |
| PHP, database, search, cache and queue version changes | Each change to PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ or Varnish between current and target release adds its own testing and possible configuration changes. Adobe supports only the listed combinations, so every combination must be checked against the target requirements. | Compare current versions with the target system requirements early, upgrade non-core services in a staging environment first, and confirm the exact supported combination before changing production. |
| CSP restrict mode from 2.4.7 | From 2.4.7, Content Security Policy runs in restrict mode by default on storefront and admin payment pages, so inline or third-party scripts that were allowed before can be blocked, which can break payment fields and tracking tags. | Inventory every script source on payment and checkout pages, add approved sources in policy configuration, and test payment flows in a staging environment that mirrors production headers. |
| Self-managed Varnish configuration | Varnish on self-managed installations uses its own VCL rules that often hold custom cache exceptions for cart, customer and block data, and these must be reviewed against new core cache tags and the target Varnish version. | Keep VCL changes in version control, document each custom exception, and run cache hit and cache-bypass tests on the target release before cutover. |
| Custom code reaching into core internals | Code that depends on protected methods, internal class names or undocumented behavior of core is the hardest to validate, because the breakage may be silent until a specific page or process runs. | Replace internal calls with public APIs, and record each remaining dependency so it can be reviewed first during the upgrade. |
| Data volume and index rebuild time | Large catalogs, order histories and customer tables lengthen database upgrade scripts, reindexing and cache warm-up, which extends the maintenance window and the time needed for rehearsal runs. | Measure the current database size and reindex duration on a copy of production, archive old data where the business allows, and schedule a full rehearsal on a production-sized clone. |
| Number of environments | Each environment such as development, staging, performance and production needs the upgrade applied, configuration synchronized and tests run, so more environments multiply the work and the risk of drift. | Keep environments built from the same infrastructure code and configuration, and limit the number of environments that need separate upgrade steps. |
| Test coverage | Without automated tests, every upgrade depends on manual checks of catalog, cart, checkout and admin workflows, which takes longer and misses regressions outside the paths someone thought to check. | Maintain automated functional and regression tests for checkout, pricing, integrations and admin tasks, and run them on every candidate release. |
| PCI DSS scope | If the store is in PCI DSS scope, the upgrade must preserve the controls and evidence an assessor expects, including patch timing, change records and retesting of payment-related components, which adds review steps. | Confirm scope with your assessor before the upgrade, keep change records and test results with the upgrade ticket, and choose payment integrations that keep card data out of your environment where possible. |
Project phases and outputs
The upgrade and support sequence moves a store from an inventory of what runs today to a tested, cut-over release and then into a steady patch rhythm, with a named output at each stage.
Inventory the store and record a baseline
Your team and ours list the running release, PHP and service versions, installed modules and themes, custom code, third-party integrations and cron and indexer jobs. The output is an inventory and baseline record covering code, configuration and performance measurements, and the step is done when you have signed off that it matches production.
Select the target release and version matrix
We compare the current 2.4.x line against Adobe's published support end dates and the system requirements for each candidate release, then agree a target. The output is a version matrix listing PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx versions, plus any Varnish requirement, and it is done when you approve the matrix in writing.
Assess compatibility and decide on extensions
We run Adobe's Upgrade Compatibility Tool against the custom code and each third-party extension, then record which extensions need a newer version, a replacement or removal. The output is a compatibility report with an extension decision register, and the step closes when each extension has a named owner and a decision you have accepted.
Remediate custom code
Our developers change custom modules and themes to work on the target release and the target PHP version, following the module structure Adobe documents. The output is a remediation log linked to the compatibility report, and the step is done when the code passes static checks and unit tests you have agreed on.
Rebuild staging and rehearse the upgrade
We rebuild a staging environment that matches production's version matrix and data, then run the full upgrade end to end at least once. The output is a rehearsal log with timings, errors and fixes, and the cutover runbook and rollback checklist are updated from what the rehearsal showed. The step closes when a rehearsal completes without open blocking issues.
Test functionality, performance and payments
Your testers run agreed scripts for catalog, search, cart, checkout, customer accounts, admin tasks and each payment method, and we compare performance against the baseline. The output is a signed test report with defects logged and resolved, and the step closes when payment flows and Content Security Policy behavior on payment pages are confirmed in staging.
Cut over to production and run hypercare
We execute the cutover runbook in a planned window, with the rollback checklist ready, then monitor errors, performance, orders and cron jobs during a hypercare period. The outputs are a cutover record and a hypercare report, and the step closes when the agreed exit criteria are met. Ongoing patch cycles then follow, with each security or full patch tested in staging before release.
What stays in-house and what goes to a partner
This table compares the upgrade tasks a store team usually keeps with the technical tasks it often hands to a partner, with the skill each one needs, so you can decide where your own staff should sit.
| Work item | Who usually owns it | Skill the work needs |
|---|---|---|
| Business sign-off on the target 2.4.x version and date | In-house | Commercial ownership of trading calendar, promotions and revenue risk, plus authority to approve go-live |
| Admin workflow testing | In-house | Knowledge of daily order, catalog and customer service tasks as staff actually perform them |
| Content and catalog checks after upgrade | In-house | Merchandising and content knowledge, including CMS pages, categories and pricing rules |
| Approving downtime windows | In-house | Understanding of peak trading periods and tolerance for checkout interruption |
| Applying routine patches on a tested runbook | In-house, with partner support available | Linux shell access, Composer commands and a documented rollback path |
| Version matrix planning for PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx | Partner | Reading Adobe system requirements per release and matching supported combinations to your hosting |
| Composer dependency resolution across core and extensions | Partner | PHP and Composer, including resolving version constraints and conflicts between packages |
| Custom module refactoring for the target release | Partner | Magento module architecture, PSR-4 structure, plugins, observers and dependency injection |
| Extension replacement or removal | Partner | Evaluation of third-party code for security and compatibility, plus knowledge of the replacement's design |
| Infrastructure version changes (PHP, database, search, cache, queue) | Partner, with your infrastructure team | Linux and database administration, service upgrades and configuration tuning |
| Automated regression suites for checkout and payments | Partner | Test automation and payment-flow knowledge, including tokenized and hosted payment paths |
| Cutover support and post-release monitoring | Partner, with in-house sign-off | Production runbook experience, log analysis and fast coordination during a release window |
What usually goes wrong
Most failed Magento Open Source upgrades trace back to a few predictable gaps. Each card names the risk and the prevention step that belongs in the scope.
Support dates and patch gaps unplanned
A release that passes its end of regular support date with no plan leaves the store without fixes. Adobe's lifecycle policy publishes these dates, including end of regular support on August 11, 2026 for 2.4.6. Map each store's version against those dates, and schedule the target line and a patch cadence in the scope so the gap never grows too wide to close.
Extensions and custom code left out
Abandoned extensions and custom modules tied to core classes often break on the target release, and the failures surface late. Inventory each third-party extension for maintenance status and compatibility with the target line, run the Upgrade Compatibility Tool against custom code, and scope any replacement or refactoring before the upgrade starts.
Stack versions outside supported combinations
Adobe supports only the listed combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx for each release. The 2.4.9 requirements list PHP 8.5, while 2.4.8-p5 lists PHP 8.4 or 8.3. Confirm the full stack against the system requirements for the target version and treat runtime upgrades as build tasks.
CSP restrict mode breaking scripts
From 2.4.7, Content Security Policy runs in restrict mode by default on storefront and admin payment pages. Payment, analytics and tag scripts loaded from unlisted domains can stop working without an obvious error. Inventory every third-party script, agree the policy with each payment provider, and test checkout and analytics in staging before go-live.
Caches, indexers and cron not retested
Varnish cache rules, indexers and cron jobs often pass a smoke test and then fail under real traffic. Stale pages, backlogged indexers or stopped cron jobs can stay hidden until peak hours. Include Varnish configuration, indexer status, cron execution and queue health in the post-upgrade test script, with a cache purge step and monitoring after cutover.
No rehearsal or tested rollback
An upgrade run once on a small dataset, with no rollback path, is an untested change to a live store. Rehearse the full upgrade on a copy of production-sized catalog and order data to measure runtime, and restore a backup to confirm it works. Scope a documented rollback plan with restore checkpoints and a named go or no-go decision.
How the work differs by starting point
A store on a 2.4.x release that is close to or past its end of regular support date usually needs a larger jump, because each release line has its own PHP, database, search and cache requirements. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, so the end date is the first thing to check.
- Confirm the current release line and its end of regular support date in Adobe's lifecycle policy.
- Identify the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and nginx versions the store runs today and the versions the target release requires.
- Plan whether the move goes to the newest supported line or to a patch on the current line, and confirm the target with the release notes.
- Expect extension compatibility work to grow with the number of releases crossed.
- Ask your partner to scope the upgrade in stages if the gap is large.
A store that has skipped several patch cycles on a supported line is often on a release that still receives security fixes, but it has accumulated changes that later patches assume. The work is usually less about the platform and more about catching up on code, configuration and extensions in a controlled order.
- Compare the installed release and patch level against the current patch for the same line.
- Review custom code and extension changes made since the last applied patch, since patches may touch the same files.
- Confirm whether the Upgrade Compatibility Tool can run against your code base before you commit to a path.
- Test each patch in a non-production environment before moving to the next one.
- Ask whether your partner will apply patches in a single step or in sequence, and what that choice does to testing time.
Hosting model changes how patches reach production and where the full-page cache sits. Adobe documents Varnish as the full-page cache accelerator for self-managed installations, so a VM or container deployment needs its cache layer planned as part of the release, not as an afterthought.
- On a virtual machine, confirm how configuration, code and static content are deployed, and whether each node is patched in place.
- On Kubernetes or containers, confirm how images are built, tagged and rolled out, and how a new image is tested before it reaches production.
- Confirm the Varnish version listed for your target release and how its configuration changes with the upgrade.
- Check that session storage, search and queue services are reachable from every web node during a rolling change.
- Ask your partner who owns the image pipeline and the rollback path.
Mage-OS is a community-owned distribution built on Magento Open Source and run by the Mage-OS Association. Its upgrade and patch path follows the distribution's own releases, so Adobe's release schedule does not set the timing for your store. Confirm the path with the distribution before planning dates.
- Confirm which Mage-OS release your store runs and which Magento Open Source release it is built on.
- Check the distribution's published release list for the ports of Adobe security patches and the dates they arrive.
- Confirm the compatibility claims for your installed extensions with both the extension vendor and the distribution.
- Decide whether your team follows Adobe's patch cadence, the distribution's cadence, or both, and document the choice.
- Ask your partner to verify the target distribution release against your own extension list before work starts.
On an air-gapped or restricted network, the server cannot pull packages or Composer dependencies during the upgrade. Every package, dependency and container image needed for the target release must be mirrored in advance, and the mirror must be refreshed before each patch.
- Build an internal Composer repository or mirror that holds the exact packages for the target release.
- Mirror operating system packages, PHP extensions, container images and the search, cache and queue service builds listed for your release.
- Record the checksum of every artifact so the change can be verified inside the restricted network.
- Plan the transfer process through your approved media or data diode, and confirm its lead time with your security team.
- Confirm which extensions can be installed from the mirror and which need outside access during setup.
A multi-store or headless setup adds consumers that an upgrade can silently break. GraphQL clients, storefront front ends and other integrations depend on schema and response shape, so regression coverage must reach beyond the traditional theme.
- List every GraphQL consumer, including front ends, mobile apps and integration middleware, and the queries each one uses.
- Build regression tests for those queries and mutations and run them against the target release before cutover.
- Confirm how each store view, website and currency is configured, and test checkout and pricing for every one.
- Check that Content Security Policy headers and caching rules still apply to each front end after the change.
- Confirm with your partner which tests run in the pipeline and which need manual sign-off from business owners.
What you need to provide
Before we can write a fixed scope for a Magento Open Source upgrade, we need the material that shows what is actually running. The core items are read access to the code repository, the composer.json and composer.lock files, and a current list of installed extensions with their versions and licenses. Extensions usually drive more upgrade effort than core code, so the list should include anything installed through Composer, copied into app/code, or patched by hand. Also provide infrastructure details for PHP, the database, OpenSearch, Redis or Valkey, RabbitMQ, the web server and any Varnish layer, including current versions and how they are deployed.
We also need a staging environment, or written permission for us to build one in your cloud account or data center. Pair it with a recent copy of the production database, handled under your data policy. Masking, access limits and retention rules should be agreed before the copy is restored. Ask your team for existing test cases or, if none exist, a short list of critical flows such as checkout, customer login, payment authorization and ERP order sync. These flows become the regression baseline that the upgrade must pass.
Scheduling needs your change windows and freeze periods, including any seasonal trading peaks. Name one owner each for business, technical and security sign-off. The business owner accepts functional behavior, the technical owner accepts the build and cutover plan, and the security owner accepts the patch level and any changes to payment page scripts or Content Security Policy. Your backup and rollback policy should be documented in advance, with the recovery point and recovery time you expect, so the rollback path is agreed before work starts.
Decide early who sets the target release. Usually your product owner chooses the 2.4.x line, based on the support end dates in Adobe's lifecycle policy, and your technical owner confirms that the required PHP and service versions are supported on your infrastructure. The same person or committee should accept the cutover in writing after staging sign-off. Confirm with Adobe's current release notes and system requirements before finalizing the target, because supported combinations change between releases.
Questions buyers ask about Magento Open Source upgrades and support
Can my Magento Open Source store stay on its current 2.4.x version?
It can stay on its current line only while that line is still in standard support. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The published end-of-regular-support dates are August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Check the lifecycle policy page for current dates before planning, because the dates may change. Once your line reaches its end date, you should plan a move to a supported line, and the work should start well before that date.
How often should Magento Open Source patches be applied?
Apply them every patch cycle. Adobe's upgrade guide recommends upgrading each patch cycle to stay secure and PCI compliant. Adobe's release schedule says a full patch for the 2.4.x LTS line ships annually in May, and security patches are released at least annually for all supported lines. Security fixes are what matter most, because unpatched known vulnerabilities are a common route into ecommerce sites. Ask your partner or internal team to show how each patch is tested in staging before it reaches production, and how the rollback path works if a patch breaks a checkout flow.
What drives the effort of a Magento Open Source upgrade?
The main drivers are the number of customizations, the number of installed extensions, the number of third-party integrations and the quality of the existing code. Adobe's upgrade guide names these same factors. A store with a clean theme, few extensions and well-structured custom modules usually moves faster than one with heavily modified core files or many abandoned extensions. Other factors include PHP and service version changes such as the PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions required by the target release. The Upgrade Compatibility Tool can help identify compatibility issues early in the assessment.
How long does a Magento Open Source upgrade take, and why can't you give a fixed duration?
A duration cannot be stated responsibly until the scope is written down. The time depends on the target version, the number of extensions to check or replace, the custom code to update, the number of integrations to retest and the volume of data and test coverage available. Ask for a written assessment that lists each of these items, then a schedule tied to that list. Fixed-scope engagements are agreed in writing before work starts, so the timeline and deliverables come from the agreed scope. Be cautious of any quote that gives a duration without first reviewing your codebase, extensions and integrations.
Can our internal team upgrade Magento Open Source without outside help?
Yes, many teams can, provided they have engineers who know Magento's module, theme and deployment structure, and who can run a full test cycle. The harder part is usually the time to find and fix compatibility issues across extensions and integrations, then retest checkout, payments and ERP sync. Ask yourself whether your team has done a major-line upgrade before, who owns test automation, and who will be available during the cutover window. An outside partner can take on the assessment, the fix list and the staging test cycle, while your team keeps ownership of the business rules and the sign-off.
What happens if our store stays on an unsupported Magento Open Source line?
After end of regular support, Adobe no longer provides the standard security patches for that line, so new vulnerabilities found in the platform are not fixed upstream for that version. Your store continues to run, but the risk grows over time, and the work to catch up gets larger as the gap between your code and the current release widens. Stores that take card payments also need to show that they apply security updates, so an unsupported line creates a compliance question as well as a technical one. Confirm the exact end-of-support dates in the lifecycle policy and ask your partner for a written risk and upgrade plan.
How DeployOpen scopes, delivers and supports upgrades
DeployOpen plans and carries out Magento Open Source upgrades inside your own infrastructure, from the current 2.4.x line to a supported target release. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- The written scope names your current 2.4.x version, target release, PHP and service versions, and environments in scope.
- It lists customizations, third-party extensions and integrations that need compatibility review before the upgrade starts.
- It states the deliverables, test coverage and handover items agreed before any work begins.
How we build
- Compatibility checks cover custom modules, themes, extensions and ERP or payment connectors against the target platform stack.
- Required changes to PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and nginx are applied and tested in a staging copy first.
- Upgrade steps, rollback points and regression tests for checkout, catalog and admin workflows are documented before cutover.
How we hand over
- You receive the upgrade runbook, configuration changes, test results and a record of every extension or module that was modified.
- Operating notes cover the patch routine, cache and indexer checks, and who on your team approves each future patch release.
- Knowledge transfer sessions walk your engineers through the environment so they can run the next patch cycle with confidence.
How we support
- Ongoing support is available as a retainer covering patch application, security release review and compatibility checks.
- Retainer scope, response expectations and included upgrade work are confirmed in writing before the retainer starts.
- Ask your DeployOpen contact to confirm which Adobe patch cycles, extension updates and environment changes the retainer covers.
