When Is PHP 8.3 End of Life and When Should You Upgrade

PHP 8.3 reaches end of life on 31 December 2027, not 31 December 2025 as some summaries suggest. The earlier date marks the end of active support, after which the branch moved to security fixes only for two more years. For anyone responsible for PHP upgrade planning for business websites, that leaves a little over a year to schedule the next move calmly rather than in a rush.

The confusion comes from the way the dates are displayed in search results. Search for the phrase and the endoflife.date PHP page appears high in the results, with a snippet that shows 8.3 as “Ended” next to 31 December 2025. That column refers to active support. The security support column on the same page runs to the end of 2027.

What Is the PHP 8.3 End of Life Date

The PHP 8.3 end of life date is 31 December 2027, as listed on the official PHP supported versions page. PHP 8.3 was first released on 23 November 2023. Its active support ended on 31 December 2025 and its security support continues until 31 December 2027.

Every PHP branch follows the same pattern of two years of active support followed by two years of security support. The table below sets out where each currently supported branch sits, using the dates published on php.net.

Once the four years are up, a branch receives no further fixes of any kind. The php.net page states that users of an end of life release should upgrade as soon as possible, because they may be exposed to unpatched security vulnerabilities. The guide to what happens if a website runs an end of life PHP version sets out those risks in detail.

Why Some Sources Say PHP 8.3 Has Already Reached End of Life

Some sources describe PHP 8.3 as having ended because they show the end of active support as the headline date. A quick scan of a search result or a version table can easily read that as end of life, especially where the security column sits further along the row.

The difference matters for planning. A website on PHP 8.3 is still on a supported branch today and will keep receiving security releases until the end of 2027. Treating 2025 as the end of life date would push a business into an unplanned upgrade it does not yet need, while treating 2027 as far away risks repeating the last minute scramble that many websites face with older versions.

The PHP.Watch overview of PHP 8.3 labels the branch as receiving security fixes only, which is the more accurate way to describe its status. That label is the one to use in internal reports and hosting reviews.

What Security Fixes Only Support Means in Practice

Security fixes only means the PHP project will still patch critical security issues in 8.3, but it no longer fixes ordinary bugs. Releases come out when they are needed rather than on a regular schedule, so there may be several in a month or none at all.

For most business websites this changes very little day to day. The hosting provider still applies new 8.3 point releases as they appear and the website keeps running as before. The practical difference is that a bug in PHP itself, such as a function behaving incorrectly in an edge case, will not be fixed in 8.3 unless it is also a security problem. Given how much of the internet runs on PHP, those point releases reach a very large number of websites.

Security only support also signals that plugin and theme developers will gradually shift their testing towards newer branches. That shift is slow, but it means new features in the software a WordPress website depends on will increasingly assume PHP 8.4 or later. None of that means the language is fading. The post on whether PHP is still relevant for business websites looks at that question in more detail.

For organisations working towards Cyber Essentials, the status of PHP is directly relevant. IASME’s Cyber Essentials myth busting guidance says software that is no longer in support must be removed or moved into a separately managed, segregated part of the network. It also expects high and critical security updates to be applied within 14 days. PHP 8.3 meets the support test until the end of 2027, after which a website still running it would fall outside that requirement.

Why WordPress Recommends PHP 8.3 as a Minimum

WordPress recommends PHP 8.3 or greater on its official requirements page. WordPress will still run on PHP 7.4 and above, but the same page warns that older versions have reached end of life and may expose a website to security vulnerabilities.

The recommendation lines up with the PHP support table. Once PHP 8.2 reaches end of life on 31 December 2026, PHP 8.3 becomes the oldest branch that still receives security fixes. Recommending it as the floor gives WordPress website owners the longest possible runway on a supported version without requiring the newest release.

WordPress core itself is tested against newer branches as they arrive. The PHP compatibility handbook page explains that the project aims to support each new PHP version in the major WordPress release that arrives around the same time each November. Plugins and themes are a different matter and need checking one by one, as the guide to WordPress and PHP compatibility explains. For anyone less familiar with the language itself, the guide to what PHP is and what it is used for covers the basics.

How PHP 8.3 Fits Alongside the PHP 8.2 Deadline

PHP 8.3 is the next deadline after PHP 8.2, which reaches end of life on 31 December 2026. Any website still on 8.2 has less than three months to move. The earlier post on what happens when PHP 8.2 reaches end of life covers that deadline in detail.

Websites leaving 8.2 now face a choice. Moving to 8.3 is the smallest step, but it buys only one more year before the same work is needed again. Moving straight to 8.4 or 8.5 takes slightly more testing up front and pushes the next deadline back by one or two years.

The wider picture of how branches are numbered and supported is set out in PHP versions explained. That post is a useful reference for anyone who needs to brief colleagues on why the version number on a hosting dashboard matters.

Laid out like this, the pattern is easy to see. A deadline arrives every December. A website that only ever moves one branch at a time will be dealing with an upgrade every single year.

Should You Move From PHP 8.3 to PHP 8.4 or PHP 8.5

For a website on PHP 8.3, the better target in most cases is PHP 8.5, provided its plugins and theme support it. PHP 8.5 is in active support until 31 December 2027 and security support until 31 December 2029, which gives the longest runway of any released branch.

PHP 8.4 is a reasonable choice where a plugin or theme is not yet ready for 8.5. Its active support ends on 31 December 2026, though, so a move to 8.4 during 2027 lands on a branch that is already receiving security fixes only. That still leaves two years before its end of life at the close of 2028.

The release plan for PHP 8.6 is published on the PHP wiki. A new branch released in November is rarely the right target for a live business website straight away, because the plugins it depends on need time to test against it. The guide to what is changing in PHP 8.6 covers the next release.

What Changes When Moving From PHP 8.3 to PHP 8.4

The move from PHP 8.3 to 8.4 is a minor version upgrade, so most well maintained code runs without changes. The official guide to migrating from PHP 8.3 to 8.4 lists the backward incompatible changes, deprecations and removals to check.

A few items are worth flagging for WordPress websites. Implicitly nullable parameter types, where a parameter accepts null only because its default value is null, are now deprecated. That produces warnings in the logs of older plugins rather than outright failures, but it is a sign of code that has not been updated recently.

The IMAP, OCI8, PDO_OCI and PSpell extensions were also moved out of the core PHP distribution. Most websites will not use any of them. Any website that reads a mailbox through IMAP, for example to import enquiries, needs checking before the switch because the extension may no longer be installed on the server.

Moving to 8.5 adds its own list of changes in addition to these, so a jump from 8.3 to 8.5 means working through both migration guides. Testing on a staging copy of the website first remains the safest approach. The guide to common WordPress update problems covers the usual failures and how to recover from them.

How to Budget and Schedule PHP Version Moves

The simplest way to budget for PHP upgrades is to plan one version move every two years and put it in the website maintenance plan alongside other routine work. The PHP end of life table shows the pattern in action, with PHP 8.1 reaching end of life on 31 December 2025 at the close of its four year support window. Moving every two years keeps a website on a branch with plenty of support left.

A website that moves from PHP 8.3 to 8.5 during 2027 would, on the same two year rhythm, next need to move in 2029. That predictable cycle makes it much easier to agree time with developers and to set aside budget in advance rather than finding money at short notice.

Scheduling the work early in the year leaves room for surprises. If an older plugin turns out to be incompatible, there is time to find a replacement or commission a fix before the December deadline arrives. A full PHP upgrade checklist sets out how to test what breaks.

It also helps to agree who owns the task. Many businesses assume their hosting provider will handle PHP upgrades, when in practice the host changes the server and the website owner is responsible for making sure the code still works.

The timing of hosting changes deserves a check as well. Managed hosting providers set their own dates for retiring old PHP branches. Those dates do not always match the PHP project’s own end of life dates.

Making PHP Upgrades a Routine Part of Website Care

PHP upgrades are least disruptive when they are treated as routine maintenance rather than emergency projects. A website that is kept current with WordPress core, plugin and theme updates is far easier to move between PHP branches than one that has been left alone for several years. Businesses weighing a rebuild rather than an upgrade can compare PHP, Python or Next.js for a business website first.

Priority Pixels includes PHP version upgrades in its WordPress support retainer, alongside managed UK hosting, uptime monitoring, security hardening and malware scanning. Bundling the work with other maintenance means version moves are planned in advance rather than triggered by a warning from a host.

Hosting is the other half of the equation. A managed WordPress hosting setup in the UK keeps the PHP version, server software and backups under the same roof, which makes it simpler to test and switch versions on a schedule.

For a website on PHP 8.3 today, the sensible next step is to check plugin compatibility with PHP 8.5 and pencil the move into the first half of 2027. That leaves plenty of time before 31 December 2027 and sets up a two year rhythm that keeps every future deadline predictable.