Every PHP version eventually reaches its End of Life (EOL) -- from that day on, no more security fixes are released, not even for critical, actively exploited flaws. That is exactly what happened to PHP 8.1 at the end of 2025 (endoflife.date). Yet 35.5 percent of all PHP websites still run on the EOL PHP 7.x branch (W3Techs, 2026), and PHP alone handles the server-side logic of 72.4 percent of all websites with a known programming language (W3Techs, 2026). Delaying the switch means running your store on software that nobody patches anymore. This guide shows how to deliver PHP upgrades in a predictable, controlled way -- with code audit, staging tests and rollback protection instead of a risky version jump on luck.
What End of Life Actually Means for PHP
Every major PHP version goes through a fixed lifecycle with three phases. During the active support phase (about two years), a version receives both bugfixes and security patches. This is followed by one year of security-only: only security corrections flow in, normal bugs remain open. At the end comes End of Life -- from that cutoff date, the PHP project releases no patches at all, not even for serious vulnerabilities (php.net).
The consequence is clear: an EOL version accumulates unpatched attack surface with every newly discovered flaw. PHP 7.4, for example, has received no security fixes since the end of 2022 (endoflife.date) and is therefore permanently vulnerable to several publicly documented CVEs. Cybersecurity researchers found at times more than 80,000 vulnerable PHP servers reachable on the internet (Cybernews, 2025). An outdated PHP version is therefore not a theoretical residual risk, but a concrete one that attackers actively scan for.
PHP 8.1 Has Been EOL Since 31 Dec 2025
The PHP Support Roadmap 2026 at a Glance
To plan upgrades sensibly, you need a clear view of the official support windows. As of 2026, only four PHP branches are maintained: 8.2, 8.3, 8.4 and 8.5 (php.net). Everything from PHP 8.1 downward is End of Life. The overview below shows how long each version receives security fixes -- which automatically defines the window by which an upgrade should be completed.
| PHP version | Status (2026) | Security support until | Recommendation |
|---|---|---|---|
| PHP 7.4 | End of Life | ended (2022) | Switch urgently |
| PHP 8.0 | End of Life | ended | Switch urgently |
| PHP 8.1 | End of Life | ended (31 Dec 2025) | Plan the switch |
| PHP 8.2 | Security-only | 31 Dec 2026 | Prepare upgrade |
| PHP 8.3 | Security-only | 31 Dec 2027 | Solid target |
| PHP 8.4 | Active support | 31 Dec 2028 | Future-proof target |
The dates come from the official sources php.net and endoflife.date (2026). This yields a simple planning rule: anyone migrating today should aim for at least PHP 8.3 -- this branch still receives security fixes until the end of 2027 and thus provides a buffer for the next cycle. PHP 8.4, as an actively supported version, is the more future-proof target, provided all installed extensions already support it.
Why Deferred Upgrades Get More Expensive
There is a common fallacy: as long as the store runs, a PHP upgrade seems unnecessary. In reality, the risk grows with every month an EOL version keeps running. The current Verizon Data Breach Investigations Report records a 34 percent rise in vulnerability exploitation as initial access and puts its share of all breaches at around 20 percent (Verizon DBIR, 2025). Unpatched software is therefore one of the most common entry points of all.
Add the time component: for new, critical vulnerabilities on exposed systems, the median time from publication to mass exploitation was recently zero days -- attacks began on the day of disclosure (Verizon DBIR, 2025). At the same time, organizations took a median of 32 days to close such gaps (Verizon DBIR, 2025). With an EOL version, the picture worsens further, because no official patch is released at all that could be applied.
Technically, deferring also gets more expensive. The larger the version gap, the more deprecations and breaking changes have accumulated, the more likely incompatible extensions become -- and the sooner a simple upgrade turns into an extensive migration project. Regular, smaller steps are more predictable and cheaper than the forced big jump when the host eventually shuts off an outdated PHP version.
The Rule of Thumb for Predictable Upgrades
Code Audit: Check Compatibility Before the Upgrade
A PHP upgrade does not begin with the version switch, but with an inventory of the code. Between major versions, PHP regularly removes deprecated functions, tightens type checking and activates previously announced deprecations. Code that ran flawlessly on PHP 7.4 can throw warnings or fatal errors on 8.3. The audit identifies these spots before they surface in live operation.
In practice, this step can be automated. Static analysis tools scan the entire source code -- including custom plugins, theme modifications and integrations -- for constructs that no longer work in the target version. The result is a prioritized list of necessary changes. Especially for Shopware stores with custom extensions, this report provides the basis for a realistic effort estimate.
Static Code Analysis
Tools check the entire source code against the target version and flag removed functions, deprecations and type conflicts before the upgrade.
Extension Matrix
For each installed extension, compatibility with the target PHP version is documented: compatible, update needed or replacement required.
Deprecation Report
Announced deprecations become visible early so changes are planned rather than made under time pressure during an incident.
Version Strategy
Instead of a jump from 7.4 to 8.4, a stepwise path over interim versions is defined, each verified individually.
Check Dependencies
Composer packages and libraries are checked against the new PHP branch and updated where necessary.
Effort Estimate
Audit and matrix produce a reliable plan with a time window, sequence and defined abort criteria.
Staging: Test the Upgrade Before Customers Notice
No code audit replaces a real test run. The staging environment is as exact a clone of production as possible: same data, same extensions, same server configuration. Here the new PHP version is installed first and the complete store is checked under realistic conditions -- without a single real customer being affected.
On staging, the upgrade first runs through in the environment: switch the PHP version, re-resolve dependencies, clear the cache, run database migrations. This is followed by the actual test of the business-critical functions. Only when checkout, search, cart, customer account and all interfaces work flawlessly is the target version approved. If an error occurs, it is fixed on staging -- not in production.
Data currency matters: a staging with data from six months ago has little informative value. Personal data must be anonymized during cloning to comply with GDPR and prevent accidental test emails to real customers. The database synchronization and maintenance is therefore closely interlocked with the upgrade planning.
# Check PHP version on staging and verify the upgrade
php -v # show current version
composer update --dry-run # test dependencies against target PHP
bin/console cache:clear # clear cache after version switch
bin/console dal:validate # check data model integrity
# Functional tests: checkout, search, cart, API
# Only after a green run -> schedule go-liveExtensions and Custom Code as a Stumbling Block
Extensions are the most common cause of failed PHP upgrades. Every plugin, every theme modification and every integration contains its own PHP code that must harmonize with the target version. A single extension that calls a function removed in the new version can take down the entire store. That is why every extension belongs in the compatibility matrix.
For extensions from the Shopware community, PHP compatibility is usually documented and maintained by the vendor. Custom developments are harder: in-house plugins, template overrides and tailored interfaces are the operator's responsibility and must be actively checked against the new PHP branch and adapted if needed. This is precisely where professional maintenance pays off, because the interactions require technical detail knowledge.
- Check every installed extension against the target PHP version and document its status
- Update extensions with an available update before the PHP switch
- Audit custom plugins and template overrides in the source code
- Reconcile Composer dependencies and libraries for compatibility
- Replace incompatible extensions or deactivate with an alternative solution
- Verify all changes on staging first, never directly in production
Go-Live with Rollback Protection
Once the target version is approved on staging, the controlled go-live follows. Even a carefully tested upgrade can reveal edge cases in production that did not appear in testing -- a specific cart constellation, a particular payment path, a rarely used interface. That is why a tested rollback plan is a mandatory component, not an extra.
Immediately before the version switch, a complete database snapshot and a filesystem backup are created -- not the nightly standard backup, but a fresh state. The rollback script that restores both was tested on staging beforehand. Anyone who has never rehearsed their rollback has no reliable rollback in an emergency. The actual maintenance window for the version switch is usually short, but should deliberately fall outside high-revenue times.
After go-live, heightened attention applies: monitoring observes error rates, response times and conversion in real time. Clearly defined thresholds decide on a rollback so that no time is lost on discussion in an emergency. One benefit ultimately outweighs the effort: newer PHP versions are significantly faster -- a WordPress setup runs around 20 to 40 percent faster on PHP 8.3 than on 7.4, without any code change (Kinsta, 2026).
An upgrade without a tested rollback is a gamble. With a snapshot, a rehearsed recovery path and real-time monitoring, the version switch becomes a routine operation.
Establish PHP EOL as an Ongoing Process
A one-off upgrade only solves the problem temporarily, because the next EOL date is already fixed. The German Federal Office for Information Security recommends in its IT-Grundschutz that patches and updates be evaluated, prioritized and applied promptly after release, and that decisions on this be documented in a traceable way (BSI IT-Grundschutz OPS.1.1.3). For PHP this means: actively track the lifecycle rather than wait for the host to shut it off.
In practice, this integrates into the regular maintenance rhythm. The installed PHP version is documented, upcoming EOL dates are noted in the calendar, and the next upgrade step is planned as soon as the current branch enters the security-only phase. This keeps the store permanently on a supported version, and each step stays small. A structured maintenance contract turns EOL management into a recurring routine instead of a firefighting exercise.
Note EOL Dates in the Calendar Early
Sources and Studies