Every winter I tell people to check their boiler before the first cold snap, not during it.
Websites are the same. Only quieter. Until they aren't.
Here's the date to put in the diary: PHP 8.2 reaches end of life on 31 December 2026. After that, the PHP team stops releasing security fixes for it. Your site won't fall over on New Year's Day. It just stops getting patched, and that's worse, because nobody notices.
The official dates are on the PHP supported versions page. As I write this, 8.3 gets security fixes until the end of 2027, 8.4 until the end of 2028 and 8.5 until the end of 2029.
Step 1: find out what you're actually running
You'd be amazed how many business owners don't know. Not their fault. Nobody tells you.
- On shared hosting, look in your control panel. Most hosts, Hostinger included, show the PHP version and let you change it from a drop-down.
- On a server or your own machine, run
php -vin a terminal. - From inside the site, a one-line test file does it:
<?php echo PHP_VERSION, PHP_EOL;
Delete that test file afterwards. There's no reason to tell the whole internet your version number.
If you'd rather your code checks for itself, version_compare(PHP_VERSION, '8.3.0', '<') returns true on anything older than 8.3. On 8.2.29, for example, it returns true. Time to plan.
Step 2: let PHP tell you what will break
This is the bit people skip, and it's the bit that matters most.
PHP doesn't usually remove something without warning. It deprecates it first, which means it still works but PHP writes a "Deprecated" message every time it runs. Those messages are your free to-do list.
The catch: if the messages aren't being logged anywhere, nobody reads them. So switch logging on in your php.ini, or the PHP settings in your hosting panel, not in the code itself:
error_reporting = E_ALLdisplay_errors = Off(visitors should never see errors)log_errors = Onerror_logset to a file outside your public folder
Why not just put ini_set() at the top of a script? Because some deprecations are raised while PHP is still reading the file, before your first line of code runs. I tested it. The setting in php.ini caught the warning. The ini_set() in the same file missed it.
In my book, PHP Done The Correct Way, the chapter on modernising old code puts it simply: log deprecations in production first, then upgrade. Fix what the log tells you, not what you guess.
Step 3: the classic one you'll probably find
Here's the warning I see most on older code moving to 8.4 or 8.5. A function like this:
function greet(string $name = null): string
works, but on PHP 8.4 and 8.5 it logs: Implicitly marking parameter $name as nullable is deprecated, the explicit nullable type must be used instead.
The fix is one character:
function greet(?string $name = null): string
Same behaviour, no warning. Call greet() with no argument and it works exactly as before.
The full list of changes for each version is in the official migration guides: 8.3, 8.4 and 8.5.
Step 4: move up in the right order
- Take a full backup of files and database.
- Copy the site to a staging area, or test locally.
- Switch the copy to the new PHP version.
- Click through every page that takes money, bookings or enquiries. Those are the ones that matter.
- Read the error log, fix, repeat.
- Switch the live site, then watch the log for a week.
If you can, go straight to 8.4 or 8.5 rather than stopping at 8.3. You'll buy yourself years, not months.
Why bother?
Because an unpatched website is an open back door with a sign on it. And because on a small, tidy site the upgrade is often an afternoon or two of careful work, not a rebuild.
I've got a simple rule: if it makes money, it makes sense. Your website takes enquiries and bookings. Keeping it patched protects that. Two months is plenty of time, as long as you start now and not on Boxing Day.
Which version is your site on? Have a look tonight. It takes about thirty seconds.
If you'd like the longer version, with tested examples, the PHP Done The Correct Way book page has the details.