There are 66 days left. I did the math last night, almost by accident, while looking at the calendar for something else. On December 31, 2026, PHP 8.2 stops receiving security fixes from the official project, and from that point on, the branch is dead. Version 8.2 was released in December 2022, lost active support at the end of 2024, and has been getting by on security patches alone ever since. 8.1 already bit the dust at the end of 2025, with 8.1.34 as its final send-off. First common misconception: nobody wakes up on January 1st with their website on fire. Nothing breaks, there is no kill switch, and the server keeps serving pages with the exact same face as always. That is precisely what makes it dangerous. End-of-life is an absence, and absences do not trigger alerts. What actually happens is slower and uglier. A vulnerability appears—say, in a parsing function or in file upload handling. The PHP team fixes it in the active branches (8.3, 8.4, 8.5) and publishes the diff. That diff is public. Anyone hunting for outdated servers reads it, figures out what changed, and goes to test if the same hole exists in 8.2, where no one is going to patch it. It is a second-order effect that is rarely explained: end-of-life turns every future fix into a map to attack the old version. The more time passes, the fatter that map gets. Honestly, I think the real risk in January or February is low, but staying on 8.2 until the summer is a completely different story. There is an exception worth knowing about, because it confuses the numbers. Some Linux distributions package a PHP version and maintain the security patches themselves; Debian 12 ships with 8.2, and the Debian security team will port fixes for a while. There are also companies that sell paid extended support. That is not the same thing as the official project providing coverage; it is a different contract with different fine print, and anyone on shared hosting has zero access to it. Those on shared hosting depend on one thing only: the version their provider lets them choose from a menu. And here comes the part that annoys me. The menu. Anyone who has ever tweaked the PHP settings on shared hosting knows that selector with versions ranging from 7.4 all the way to 8.4 or 8.5, all available, all looking like legitimate options. They aren't. The fact that a version is on the list only means the provider can still compile and serve it, not that anyone is monitoring it. I have seen 7.4 available for years after it died, and I am certain 8.2 will hang around long past December, because removing a version generates support tickets, while leaving it generates silence. The provider does the math and chooses silence. In their shoes, I would do the same. Moving on to the practical side, which is where December is won or lost. I have two projects running on PHP and a third, smaller one for video, and not one of them has ever undergone a properly executed major version update. I just kept kicking the can down the road. The first thing I did this week was the most boring and the most useful: I created a copy of the site on a staging subdomain, set that subdomain's PHP to 8.4, and turned on error logging with everything active. In production, `display_errors` stays off, of course, but on the copy, I wanted to see every single warning bleed into the log. The first run gave me 63 lines of `Deprecated`, and 41 of them were the exact same class creating properties it had never declared. The error we have all seen by now, *"Creation of dynamic property,"* which 8.2 started warning about and which continues to warn in subsequent versions. Code written in 2019 by someone in a hurry—and that someone was me. A quick digression. Years ago, with a client I don't even have anymore, I caught a site stuck on PHP 5.6 because of a booking plugin whose author had vanished off the map. I spent two weeks trying to convince the owner that the plugin was the problem, not me. We ended up rewriting the booking section by hand over a weekend, and the final bill was three times what it would have cost to migrate on time. I never left a dead component inside a system I needed to update again; yet here I am, repeating the pattern on a smaller scale with a class from 2019. Back to the test. When you upgrade versions, errors fall into two worlds: the ones the language warns you about (the `Deprecated` ones) and the ones that crash things completely. Going from 8.2 to 8.4, there are very few of the second type, but 8.4 brought a deprecation that catches a lot of people by surprise: parameters with a default value of `null` without the type being marked as nullable. The message is *"Implicitly marking parameter $x as nullable is deprecated,"* and adding a question mark to the type is all it takes to fix it. It is annoying because it pops up in dozens of places, even though the fix is mechanical. If you have third-party libraries in `vendor`, it isn't your problem to fix, but the log fills up all the same and hides the errors that actually matter. For those libraries, I use two commands I rarely see mentioned. The command `composer why-not php 8.4` tells you, plain and simple, which package is blocking you from upgrading, and `composer check-platform-reqs` verifies whether the environment meets what the project requires. Before discovering them, I used to do that manually by opening the `composer.json` of each dependency. I learned out of desperation. If the blocking package is abandoned, you have a decision to make, and there is no point in putting it off because the deadline is December 31st and it isn't moving. For your own code, before doing the real test, a simple loop that iterates through all `.php` files and runs `php -l` on each one will catch syntax errors that the new version won't forgive. It won't catch logic or behavior bugs, but it saves you from discovering a misplaced comma in production. It ran through 187 files in less time than it takes me to make a coffee. Now for the question people keep asking me, and that I keep asking myself: 8.3, 8.4, or 8.5? I would go for 8.4 without much hesitation. 8.3 is safe until the end of 2027, which sounds like a lot until you realize it is only a one-year buffer, and we will be having this exact same conversation twelve months from now. Skipping to an intermediate version just to postpone the problem is, in my experience, the most expensive way to save work. 8.4 covers you until the end of 2028 and 8.5 until the end of 2029; 8.5 has been out for almost a year already, meaning most decent libraries have tested it by now. That said, slightly contradicting myself, if any of your packages only declares compatibility up to 8.3, you stop at 8.3 with zero shame and move forward when the package does. The goal isn't to be on the newest version; it is to get off 8.2 without breaking anything. A side note on performance, because someone will ask. The speed gain from one minor version to the next is real, but small. In my case, time to first byte dropped from around 410 milliseconds to about 360, and no one notices that with the naked eye. Anyone selling the upgrade as a massive performance boost is selling snake oil. The reason to upgrade is security—everything else is just a bonus. There was one thing that almost fooled me and is worth sharing. After changing the version in the panel, I opened the site and the layout looked completely broken. For ten minutes, I was convinced the new PHP version had messed up something in the template. It was CSS caching. The browser and the CDN were serving an old stylesheet, and having a `style.css` without a version number at the end did the rest. Clearing the cache and adding `?v=` with a number fixed it. It had nothing to do with PHP, but when you are nervous, everything feels like the fault of the last thing you touched. It is also worth reviewing what you have in `.htaccess`. I once had a line with `php_value` that worked under one configuration and returned an unexplained 500 error under another, and during a version change, hosting providers might swap the underlying handler. If the site throws a 500 error immediately after the change, that is the first thing I would open. On my page time tracker, which writes to log files instead of using a database, the `.htaccess` hardening remains the same, but I manually verified that the files are still inaccessible via URL. It takes five minutes and is worth a good night's sleep. And now the elephant in the room: the VPS. I have been thinking about leaving shared hosting. The 200 GB disk is barely touched, and the database is just a few megabytes, so migrating data would be trivial—a dump that runs in seconds. Even so, I tell you that the end-of-life of 8.2 is a terrible reason to switch infrastructure. On shared hosting, upgrading versions means opening a menu and picking another option. On a VPS, you become the sysadmin: automatic updates, fail2ban, php-fpm pools, a firewall someone has to configure without locking themselves out. When PHP 8.4 reaches end-of-life, you will be the one updating it at 11 PM on a Friday with no one else to blame. Freedom is the good reason to move to a VPS; December panic is the bad one. But I also admit my mind is already halfway there, and I will probably end up switching anyway—just not for this reason. In practical summary, without making a summary: clone the site, bump the version on the copy, read the log calmly, fix what belongs to you, identify third-party issues, pick 8.4, and schedule the production switch for a Monday morning—never for Christmas Eve. I have already picked the day, but I haven't told my calendar yet. I still need to see what happens with that image library that hasn't been updated since 2023. I don't know yet.