Membership site on PHP 7.4, 22 plugins
Audit finds 3 abandoned plugins and one theme function using create_function(). Two plugins replaced, one patched, theme fixed.
Estimate: audit + €690 package + ~€300 plugin replacement work.
PHP 8.1 stopped getting security fixes on 31 December 2025 and PHP 8.2 follows on 31 December 2026. When a critical bug like PHP2Shell lands, supported branches get a release the same day — end-of-life branches wait for someone's backport, or never get one. We move your application to a supported PHP version with a fixed-price audit, a staged rollout and a rollback plan.
PHP 8.1 and older get no security releases. PHP 8.2 reaches end of life on 31 December 2026.
Quick Answer
Optimum Web upgrades PHP applications from 5.x, 7.x, 8.0 and 8.1 to supported versions (8.3, 8.4 or 8.5). We start with a fixed-price readiness audit (€390 / $429, 3 business days) that scans your code, dependencies and extensions and returns a fixed price for the upgrade. Typical prices: WordPress or WooCommerce sites from €690, framework applications (Laravel, Symfony, Yii) from €2,400, legacy custom code quoted after the audit. Every upgrade runs on staging first, ships with a rollback path and a 14-day warranty.
Security-support end dates per php.net/supported-versions, status as of 25 October 2026. Highlighted: the branch most sites are still on.
| Version | Security support ends | Status on 25 Oct 2026 |
|---|---|---|
| 5.6, 7.0–7.3 | Ended 2018–2021 | End of life |
| 7.4 | 28 Nov 2022 | End of life |
| 8.0 | 26 Nov 2023 | End of life |
| 8.1 | 31 Dec 2025 | End of life |
| 8.2 | 31 Dec 2026 | Ends in about two months |
| 8.3 | 31 Dec 2027 | Security fixes only |
| 8.4 | 31 Dec 2028 | Supported — our default target |
| 8.5 | 31 Dec 2029 | Supported — target when your framework supports it |
Since PHP 8.0 many internal functions throw TypeError instead of warning. Since 8.1, passing null to non-nullable internal parameters is deprecated — legacy code does this everywhere (strlen(null), trim(null)).
PHP 8.0 changed string-to-number comparisons (0 == "abc" is now false). Login checks, filters and imports built on loose comparison change behaviour silently.
create_function(), each(), money_format(), the old mysql_* API and mcrypt are gone. Code that "worked for years" fails at runtime only on the path that calls them.
Deprecated in 8.2 — floods logs in older frameworks and plugins and becomes a hard error later.
Your framework, Composer packages and WordPress plugins each have their own minimum and maximum PHP versions. One abandoned package can block the whole upgrade.
New FPM pools, different php.ini defaults, new extension builds, OPcache and session settings — plus cron jobs and CLI scripts that run on a different PHP than the website.
Static analysis with PHPCompatibility and PHPStan, Rector dry-run, Composer constraint check (composer why-not php 8.4), plugin/theme compatibility for WordPress, extension inventory, cron/CLI inventory. Output: list of required changes, risk rating, fixed price and timeline.
Copy of production on the target PHP version, side by side with the current one.
Rector for mechanical changes, engineers for logic changes (comparisons, null handling, removed functions). Every change in a reviewable pull request.
Your existing tests plus smoke and regression checks on critical flows (login, checkout, forms, imports, admin). Where there are no tests, we write characterisation tests for the critical paths first.
New PHP-FPM pool runs alongside the old one; switch traffic, watch error logs, switch back in seconds if needed.
14-day warranty, deprecation log review, and an optional maintenance plan to keep minor versions current.
€390 / $429
from €690 / $749
from €2,400 / $2,590
after audit; typically €4,000–12,000
Estimates from comparable upgrades; your audit gives a fixed number.
| Starting point | Target | Typical effort |
|---|---|---|
| WordPress, 15–30 maintained plugins, PHP 7.4 | 8.3 / 8.4 | 1–3 days |
| WooCommerce with custom theme and 2–3 custom plugins, PHP 8.0 | 8.4 | 3–6 days |
| Laravel 8 on PHP 8.0 (framework upgrade to Laravel 11/12 needed) | 8.3 / 8.4 | 2–4 weeks |
| Symfony 4.4 / 5.4 application | 8.4 | 2–5 weeks |
| Custom PHP 5.6/7.0 code, ~30k lines, mysql_* calls, no tests | 8.3 / 8.4 | 6–10 weeks |
| Magento 2.4.x on PHP 8.1 | 8.3 (per Adobe's matrix for your 2.4 release) | 2–6 weeks |
Illustrative scenarios built from the stacks we maintain. Not client case studies.
Audit finds 3 abandoned plugins and one theme function using create_function(). Two plugins replaced, one patched, theme fixed.
Estimate: audit + €690 package + ~€300 plugin replacement work.
Upgrade path Symfony 4.4 → 5.4 → 6.4 with PHP 8.3. Rector handles most deprecations; the remaining work is in custom form types and Doctrine mappings.
Estimate: 3–4 weeks.
mysql_* → PDO, mcrypt → OpenSSL with data re-encryption plan, loose comparisons in permission checks fixed and covered by tests.
Estimate: 6–8 weeks, phased so the CRM stays in use.
We have run PHP in production for 27 years — Symfony, Laravel, WordPress and custom code.
Page load time cut on a Symfony news portal with 50,000+ daily visitors — see the case study below.
Handled on the same portal without downtime after the rebuild.
Fixed-price patching of CVE-2026-109618/109619 with a per-host report.
Learn More50,000+ daily visitors, 60% faster page loads, no downtime in traffic spikes.
Learn MoreBuild and extend PHP applications with senior engineers.
Learn MoreSymfony applications, upgrades and long-term support.
Learn MoreMove legacy applications to a modern, supported stack.
Learn MoreKeep PHP and dependencies current after the upgrade.
Learn MoreUsually 8.4: supported until the end of 2028 and widely supported by frameworks and plugins. 8.5 if your stack supports it. We do not recommend 8.2 as a target — it reaches end of life on 31 December 2026.
Yes for PHP itself; the audit covers all intermediate changes. Frameworks sometimes need stepwise upgrades.
Normally a few seconds at cutover, or none. The old PHP stays installed until you sign off.
The backport fixes one bug. The next critical PHP vulnerability will again ship as releases for supported branches first, and EOL branches may not get one at all.
Yes, it is often required and included in the quote after the audit.
We write characterisation tests for the critical flows before changing anything, so we can prove behaviour did not change.
Yes, via maintenance plans or dedicated engineers.
Whether you need a dedicated team, a single specialist, or a complete digital transformation — we're here to help.
Or email us directly: info@optimum-web.com