Quick answer
PHP 8.2 reaches end of life on 31 December 2026. After that date it receives no security fixes from the PHP project, so any Australian business still running it should upgrade, ideally to PHP 8.5. Your site or app will keep working, but newly found vulnerabilities will stay unpatched, and hosts, frameworks and packages will progressively drop support.
The upgrade follows six steps: check your current PHP version, audit your code and dependencies, update Composer packages and frameworks, fix deprecated code, test in staging, then deploy with a rollback plan. Most small to medium applications take one to six weeks, and there are under three months left, so start now.
What does PHP 8.2 end of life mean?
End of life means the PHP project stops releasing fixes of any kind for that version, including security patches. Each PHP branch gets two years of active support (bug and security fixes), then two more years of security-only support, then it is retired. PHP 8.2 was released on 8 December 2022. Its active support ended on 31 December 2024, and its security support ends on 31 December 2026.
| PHP version | Released | Active support ended or ends | Security support ends (end of life) |
|---|---|---|---|
|
7.4 |
2019 |
Ended |
28 November 2022 (ended) |
|
8.0 |
2020 |
Ended |
26 November 2023 (ended) |
|
8.1 |
2021 |
Ended |
31 December 2025 (ended) |
|
8.2 |
8 December 2022 |
31 December 2024 (ended) |
31 December 2026 |
|
8.3 |
23 November 2023 |
31 December 2025 (ended) |
31 December 2027 |
|
8.4 |
21 November 2024 |
31 December 2026 |
31 December 2028 |
|
8.5 |
20 November 2025 |
31 December 2027 |
31 December 2029 |
If you are on PHP 8.1 or older, you are already past end of life, and the upgrade is more urgent. Check the official php.net Supported Versions page for the latest dates.
Which PHP version should you upgrade to?
For most businesses, PHP 8.5 is the best target because it has the longest support runway: active support until 31 December 2027 and security fixes until 31 December 2029. PHP 8.4 is a reasonable stepping stone if a framework, plugin or extension is not ready for 8.5 yet, but be aware of the timing.
| Target | Best for | Watch out for |
|---|---|---|
|
PHP 8.5 |
Most applications, especially new work and anything you want to leave alone for years |
A few extensions or packages may not support it yet. Check before you start. |
|
PHP 8.4 |
Apps blocked by one or two dependencies that are not 8.5-ready |
Active support ends 31 December 2026, so you get security-only fixes from the new year. |
|
PHP 8.3 |
Apps where jumping further is risky right now |
Security support ends 31 December 2027, so you would be upgrading again within about a year. |
Upgrading to 8.4 in November buys only a few weeks of active support, then security-only patches until the end of 2028. That is still safe, but it means a second upgrade sooner than if you go straight to 8.5.
Your choice also depends on your stack. Check what your framework (Laravel, Symfony, CodeIgniter), CMS (WordPress, Drupal) and hosting provider support before committing. For frameworks, see our guide to Laravel microservices architecture for Australian businesses.
What happens if you stay on PHP 8.2 after 31 December 2026?
Your application keeps running, but it stops receiving security patches, and the ecosystem around it gradually moves on. The risk grows every month you wait.
- Unpatched vulnerabilities: new PHP security flaws are fixed in supported versions only. Attackers know which versions are retired.
- Hosting changes: hosts and Linux distributions stop packaging old PHP versions, and some remove them from their control panels, which can force a rushed upgrade.
- Dependency drift: Composer packages, frameworks and CMS plugins start requiring a newer PHP, so you cannot update them without upgrading PHP first.
- Compliance and insurance: unsupported software is hard to defend in a security audit, a client questionnaire or a cyber insurance renewal.
- Rising cost: the further behind you fall, the more changes you face in one go. A one-version jump is far cheaper than a three-version jump.
If you cannot upgrade in time, paid extended support from specialist vendors exists as a short-term stopgap. It costs money and does not fix the underlying problem, so treat it as a bridge, not a plan.
How do you check which PHP version you are running?
Run php -v on your server, or check the PHP version setting in your hosting control panel. For a website, you can also add a temporary page that calls phpinfo(), then delete it straight away so it does not leak server details.
Before you plan the upgrade, collect this information:
- PHP version: on the server, in staging and in production, since they are often different.
- Framework and CMS versions: for example Laravel, Symfony, WordPress or Drupal, and which PHP versions each release supports.
- Composer dependencies: run composer outdated and composer why-not php 8.5 to see which packages block the upgrade.
- PHP extensions: run php -m and check each one is available for your target version.
- Hosting limits: confirm your host offers PHP 8.4 or 8.5 and can run staging and production side by side.
- Test coverage: note whether you have automated tests. If not, plan more manual testing time.
If you are on a managed host or shared hosting, you may only need to switch the PHP version in the control panel, but test on a staging copy first.
How do you upgrade from PHP 8.2 to PHP 8.5, step by step?
Work through eight steps: back up, audit, update dependencies, scan the code, fix issues, test in staging, deploy, then monitor.
- Back up everything. Take a full backup of code, database and server configuration, and confirm you can restore it.
- Create a staging environment. Clone production onto a server running your target PHP version. Never test the upgrade on the live site.
- Update frameworks and packages first. Move your framework, CMS and Composer packages to versions that support your target PHP. Update in small batches and run your tests between each one.
- Scan the code. Use static analysis tools such as PHPStan or Psalm, a PHP compatibility checker, and Rector to find and automatically fix deprecated syntax.
- Fix deprecations and errors. Turn on full error reporting in staging, including deprecation notices, and clear them.
- Test thoroughly. Run automated tests, then manually check logins, forms, payments, emails, file uploads, scheduled jobs, APIs and admin screens.
- Deploy with a rollback plan. Schedule the release for a quiet period, keep the old PHP version available, and be ready to switch back quickly.
- Monitor after release. Watch error logs, performance and user reports for the first one to two weeks.
If you are two or more versions behind, upgrade one version at a time in staging. It is easier to find what broke.
What usually breaks when upgrading PHP?
The most common problems are deprecated code, outdated Composer packages, missing extensions and old custom plugins. Most are easy to find in staging if error reporting is switched on.
| Problem | What it looks like | How to fix it |
|---|---|---|
|
Dynamic properties (deprecated in 8.2) |
Deprecation notices about creating properties that were not declared |
Declare the properties on the class, or add the allow-dynamic-properties attribute as a temporary measure |
|
Implicit nullable parameters (deprecated in 8.4) |
Notices on functions with a typed parameter defaulting to null |
Add the nullable type explicitly |
|
Outdated Composer packages |
Install fails because a package requires an older PHP |
Update the package, replace it, or fork and patch it |
|
Missing or changed extensions |
Fatal error about a missing function or class |
Install the extension for the new version, or replace the feature |
|
Old custom plugins or themes |
White screen or warnings in the CMS |
Update, rewrite or retire the plugin |
|
Strictness changes |
New warnings or type errors in code that used to pass silently |
Add proper type handling and validation |
|
Stale server configuration |
php.ini settings or caching modules that no longer apply |
Review and update the configuration for the new version |
The more legacy code you have, the more likely you are to hit several of these at once. That is why a staging test and an audit pay for themselves.
How much does a PHP upgrade cost in Australia?
A PHP version upgrade in Australia typically costs from about AUD $2,000 for a small site to $30,000 or more for a large legacy application. These are indicative estimates. A fixed quote needs a code audit first.
| Application type | Typical scope | Timeline | Indicative cost (AUD) |
|---|---|---|---|
|
Small site or simple app |
Few custom plugins, up-to-date framework, one version jump |
1 to 2 weeks |
$2,000 to $8,000 |
|
Medium custom application |
Custom code, several integrations, framework upgrade needed |
3 to 8 weeks |
$8,000 to $30,000 |
|
Large or legacy system |
Multiple version jumps, old framework, little test coverage |
8 to 20+ weeks |
$30,000+ |
Four things push the price up: how many versions you are behind, whether your framework needs a major upgrade at the same time, how many custom plugins and integrations you have, and how much automated test coverage exists.
PHP development rates vary by location and team. Our PHP development pricing guide puts agency rates at roughly AUD $80 to $200 per hour.
Waiting makes it more expensive. After 31 December, hosts and tools start dropping older versions, and a rushed emergency upgrade usually costs more than a planned one.
What should Australian businesses consider about unsupported PHP?
Australian businesses should treat an end-of-life PHP version as a security and compliance issue, not only a technical one. If your application holds customer data, running unsupported software is difficult to justify.
- Privacy Act 1988: the Australian Privacy Principles require organisations to take reasonable steps to protect personal information. Unsupported software weakens that position, and the Notifiable Data Breaches scheme applies if personal information is compromised.
- ACSC Essential Eight: patching applications and operating systems is a core control. Software that no longer receives patches makes it hard to meet.
- Card payments: if you take card payments, PCI DSS expects systems to be kept patched against known vulnerabilities.
- Client contracts and audits: government, finance, health and enterprise customers often require supported software in contracts and vendor reviews.
- Cyber insurance: insurers increasingly ask about patching and end-of-life software on renewal questionnaires.
- Hosting and data location: if you are changing servers as part of the upgrade, confirm where data will be stored.
This is general information, not legal advice. Confirm your specific obligations with your legal or compliance adviser.
Frequently asked questions
When does PHP 8.2 reach end of life?
PHP 8.2 reaches end of life on 31 December 2026. Active support already ended on 31 December 2024, so it currently receives security fixes only.
What happens when PHP 8.2 reaches end of life?
The PHP project stops releasing security fixes for it. Your application continues to run, but new vulnerabilities will not be patched, and hosts, frameworks and packages will gradually drop support.
Which PHP version should I upgrade to in 2026?
PHP 8.5 is the best target for most businesses, with active support until 31 December 2027 and security fixes until 31 December 2029. PHP 8.4 is a reasonable stepping stone if a dependency is not ready for 8.5.
Is PHP 8.1 still supported?
No. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.0 and 7.4 ended earlier. If you run any of these, upgrade as a priority.
How long does a PHP upgrade take?
Small sites often take one to two weeks, medium custom applications three to eight weeks, and large legacy systems eight weeks or more. The audit usually shows the real timeline.
Will my website stop working after 31 December 2026?
No. It will keep running, but it will no longer receive security patches from the PHP project, and the risks grow over time.
Can I upgrade PHP myself?
For a simple site, you may be able to switch the PHP version in your hosting panel and test on staging. Custom applications, frameworks with outdated packages and legacy code are safer with a developer.
Can PHP Professionals upgrade my PHP application?
Yes. PHP Professionals is an Australian PHP team that handles PHP migration and upgrade projects, from the initial audit through to testing, deployment and post-launch support.
Conclusion: plan your PHP upgrade before 31 December
PHP 8.2 stops receiving security fixes on 31 December 2026, so the safest move is to audit your application now and upgrade to PHP 8.5, or to PHP 8.4 if a dependency is holding you back. Start with a version and dependency check, test everything in staging, and deploy with a rollback plan.
If you want a clear scope, timeline and fixed-price quote, contact PHP Professionals for a PHP upgrade audit. You can also read about our PHP migration and upgrade services, custom PHP web application development and PHP website maintenance.