PHP 8.2 end of life is December 31, 2026: after that date, the PHP project stops shipping security fixes for 8.2 (PHP supported versions). If your app runs on 8.2, you have about three months to move to 8.3 or 8.4, and the realistic plan takes about six weeks of focused work. Start in October and you finish with room to spare. Start in December and you're shipping a runtime upgrade during the holidays.
Key Takeaways
- PHP 8.2 security support ends December 31, 2026. After that, new vulnerabilities in 8.2 don't get patched.
- Upgrade to PHP 8.4, which gets security fixes until December 31, 2028. PHP 8.3 only buys you until the end of 2027.
- Scope it in three pieces: a dependency audit, the version jump, and tests on your critical paths.
- One dedicated senior engineer for about six weeks beats squeezing the upgrade between features.
PHP 8.2 End of Life Date, and Where to Go Next
Here's where each supported PHP branch stands, per php.net:
| Version | Status | Security fixes until |
|---|---|---|
| 8.1 | End of life | Ended November 25, 2025 |
| 8.2 | Security fixes only | December 31, 2026 |
| 8.3 | Security fixes only (active support ended December 31, 2025) | December 31, 2027 |
| 8.4 | Active support until December 31, 2026 | December 31, 2028 |
| 8.5 | Active support until December 31, 2027 (released November 20, 2025) | December 31, 2029 |
My default recommendation is 8.4. It gives you two years of security support after the jump, and it's been out long enough that most maintained libraries support it. Going to 8.3 means doing this again in about a year. 8.5 buys another year, but check that every package you depend on supports it before you commit.
Why This Upgrade Keeps Slipping
Nobody gets promoted for upgrading PHP. The work is invisible when it goes well, product managers can't see a customer benefit, and every sprint has something more urgent. Meanwhile the dependency tree drifts: libraries drop support for your old version, and the jump gets bigger each quarter you wait. The real cost of technical debt covers how that compounds.
A Six-Week PHP 8.2 Upgrade Plan
Weeks 1 and 2: dependency audit. List every Composer package, its version, and whether a release compatible with your target PHP version exists; `composer why-not php 8.4` lists the packages that block the jump. Abandoned libraries are the real risk, because they turn an upgrade into a replacement project. Check that your framework major supports the target version, since older Laravel and Symfony majors cap below the newest PHP, and some jumps go through intermediate framework versions. Check compiled extensions too (Redis, Imagick, and the like), because each one needs a build for the new PHP version.
Weeks 3 and 4: replace, scan, and test. Swap out abandoned packages and add tests around the critical paths, like checkout, auth, and billing, before touching the runtime. Read php.net's migration notes for 8.3 and 8.4, then run static analysis (PHPStan, or PHPCompatibility for PHP_CodeSniffer) against the target version; Rector can apply many of the mechanical fixes. The 8.4 change most codebases hit is the deprecation of implicitly nullable parameters: `function f(Foo $x = null)` needs to become `?Foo $x = null`. If you can't show the app behaves the same after the upgrade, you're shipping a guess.
Week 5: staging. Run the app on the new PHP version in staging with production-like traffic and background jobs, with deprecation notices logged so you see early what the next upgrade will break.
Week 6: production. Roll out gradually if your hosting allows it, keep the old runtime available for a fast rollback, and watch error rates for a week.
Other End-of-Life Dates Landing Soon
PHP rarely runs alone. If your stack includes any of these, plan them in the same quarter:
| Stack | What happens | Date |
|---|---|---|
| Python 3.10 | End of life (scheduled) | October 2026 (Python devguide) |
| .NET 8 and 9 | End of support | November 10, 2026 (.NET support policy) |
| Angular 20 | LTS ends | November 28, 2026 (Angular releases) |
| Node.js 22 | End of life | April 30, 2027 (Node.js schedule) |
Oracle's Premier Support for Java 17 ends this month, September 2026; Extended Support runs to September 2029 for customers with an Oracle Java SE support contract, and Oracle is waiving the Extended Support fee for 17 through that date (Oracle).
Who Should Do the Upgrade
| Situation | Who you want |
|---|---|
| On 8.2, decent test coverage | One senior PHP engineer for about six weeks |
| On 8.1 or older, thin tests | A senior PHP engineer plus a QA automation engineer |
| Abandoned dependencies and legacy code | A senior engineer with modernization experience; see hiring developers to modernize a legacy app |
In interviews, ask for an upgrade they led: what broke, how they rolled it out, and how they knew it worked. Good upgrade engineers are boring on purpose. They move in small steps, keep every deploy reversible, and upgrade one service at a time.
An outside engineer for a defined period fits this work well. With staff augmentation, a 90-day initial commitment covers a PHP upgrade plus the next item on the list, and month-to-month terms with 30 days' notice after that let you keep the engineer for the next deadline or roll them off.
A Concrete Version
It's late September 2026. A 25-person marketplace runs its main app on Laravel with PHP 8.2 and a fleet of background workers on Node.js 22.
The team brings in one senior PHP and Node engineer. They get a shortlist within 72 hours, pick in the first week of October, and the engineer starts on October 26.
Weeks 1 and 2: the audit finds 64 Composer packages, three of them abandoned: a PDF library and two payment helpers. Weeks 3 and 4: the engineer replaces the three and adds tests around checkout and payouts. Week 5: the app goes to staging on PHP 8.4. Week 6: after a week of soak time, it ships to production in the first week of December, about four weeks before the PHP 8.2 deadline.
January and February: the workers move from Node 22 to Node 24, one service at a time. The last one ships in mid-March, six weeks before Node 22's end of life. The product team shipped features the whole time.
The Honest Counterpoint
Not every end-of-life date is an emergency. An internal tool behind a VPN is a smaller risk than your public checkout. Buying time can be the rational choice if the app is being replaced within a year.
If the codebase is so tangled that the upgrade is really a rewrite, stop and have that conversation honestly before hiring anyone. Should you rewrite or refactor your app is a good frame, and the reality of legacy code is a useful reality check.
Frequently Asked Questions
What is the PHP 8.2 end of life date?
December 31, 2026. That's when security support ends, per php.net's supported-versions page. 8.2 is already in its security-fixes-only phase.
Should I upgrade from PHP 8.2 to 8.3 or 8.4?
8.4 in most cases. It gets security fixes until December 31, 2028, while 8.3 stops at the end of 2027. Check your dependencies first.
Can I keep running PHP 8.2 after end of life?
You can, but new vulnerabilities won't be patched by the PHP project. For anything internet-facing, that's a risk to accept deliberately and in writing, not by default.
The Bottom Line
PHP 8.2 end of life is December 31, 2026. Audit your dependencies this week, target 8.4, and give the upgrade dedicated hands with a deadline. Request a shortlist of senior PHP engineers, or browse senior backend developers in LATAM.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
