Your association's site was rebuilt in early 2023 and it has been solid ever since. Nobody has had a reason to think about the language it runs on, which is exactly how it should be. On the last day of December, the version of that language stops receiving security fixes, and the countdown to your next unplanned project quietly begins.
PHP 8.2 reaches end of security support on December 31, 2026. On the same day, PHP 8.4 drops out of active support into security-only maintenance. Both dates come from the PHP project's published support schedule and have been fixed for years.
Why 8.2 Specifically Catches Associations
It was the sensible choice in 2023, which is precisely the problem. PHP 8.2 shipped in December 2022 and became the default on most managed hosts through 2023. Any association site built or replatformed in that window landed on it by default, and a site built in 2023 is now at the age where nobody is actively watching it and nobody has yet decided it needs replacing.
There is also a Sage and Roots angle worth naming. A number of association sites built by agencies in that period run the Sage theme framework with Acorn. Acorn version 5 requires PHP 8.2 or newer, so 8.2 is the floor for that stack rather than an arbitrary choice, which means moving forward is straightforward, but staying put has a hard bottom.
What End of Security Support Means
Nothing happens on January 1. Your site runs exactly as it did the day before. There is no kill switch, no warning banner, and no host that turns you off at midnight.
What ends is the supply of fixes. A vulnerability found in PHP after that date gets patched in 8.3, 8.4 and 8.5 and not in 8.2. Your exposure does not begin on the deadline; it accrues from it, one advisory at a time, and you have no way to close any of them without upgrading.
The second-order effect arrives faster than the first. Plugin and module authors drop support for end-of-life PHP versions on their own schedules. Within a few months of a version going end of life, you start seeing updates you cannot install, which is usually how organizations find out, not from a security advisory but from an update that refuses to run.
Which Version to Move To
There are three supported options at the end of this year, and for most association sites the choice is genuinely easy.
- PHP 8.3 , supported, boring, and the smallest possible jump from 8.2. A reasonable choice if you want the least disruption and expect to replatform within a year or two anyway.
- PHP 8.4 , our usual recommendation. It moves to security-only support on December 31, 2026, but that support runs through December 31, 2028, which buys you two years. It is mature, widely deployed, and every major CMS and plugin ecosystem has caught up with it.
- PHP 8.5 , released in November 2025, with the longest runway. Sensible if your site is actively maintained and your dependency list is current. Less sensible if you are running anything abandoned, because the newest version is where compatibility gaps show up first.
One version number to be careful about. PHP 8.6 has a general availability date of November 19, 2026. It is not the version to be planning a December migration onto, and it is worth noting because the numbering invites the assumption that newest is safest. For a production association site in December, newest is the opposite of safest.
How to Check, and What It Costs
Finding out where you stand takes minutes. The work that follows is usually smaller than people expect.
- Find your current version. In WordPress it is on the Tools then Site Health then Info screen, under Server. In Drupal it is on the status report. Your hosting dashboard will also tell you, and that is the one that governs.
- Check compatibility before changing anything. For WordPress, a compatibility checker plugin will flag code that will not run on a newer version. For Drupal, Upgrade Status covers both core and contributed modules.
- Change the version on a staging environment first. Then click through the parts that matter, member login, dues payment, event registration, any AMS handoff, rather than just loading the home page.
- Promote it, and note the date somewhere durable. Whatever version you land on has an end-of-life date too. Putting it in a shared calendar is the difference between a planned afternoon and an unplanned quarter.
If You Are on Pantheon, Read This With the Other Date
Pantheon removed six older PHP versions on September 30, automatically upgrading any site still running one of them. If that applied to you, you may already have moved recently and be in better shape than you think. If it did not, the December date is the next one on your calendar and the same staging-first approach applies.
When Doing Nothing Is Defensible
If your site is a small brochure site with no logins, no payments and no member data, running an end-of-life PHP version for a few extra months is a modest and quantifiable risk rather than an emergency. Plan the upgrade for a quiet month in the first half of 2027 and do not let anyone sell you urgency you do not have.
What is not defensible is a site that takes dues or donations sitting on unsupported PHP indefinitely. That combination, cardholder data flowing through software nobody is patching, is the one that turns a maintenance question into a compliance conversation.
The Version Treadmill, and How to Get Off It
PHP ships a new major version every November and supports each one for four years, two years of active support, then two of security fixes. That cadence is predictable, which means an organization can stop being surprised by it entirely.
The pattern that works is a standing annual check rather than a project. Once a year, in a month with no conference and no renewal cycle, somebody confirms which version each environment runs and when that version expires. If the answer is more than eighteen months out, the meeting is over in five minutes.
The pattern that does not work is waiting for a notification. Hosting providers email the account owner, and the account owner is frequently a developer who left, a vendor you no longer use, or a shared inbox nobody reads. The PHP project itself does not email anybody. There is no notification path that reaches your executive director by default, which is why these dates pass unremarked until something refuses to update.
For most associations this belongs to a maintenance retainer, and if you have one, this post should already be somebody else's problem. Confirm that PHP versions are inside its scope, a surprising number of retainers cover plugin updates and say nothing about the platform underneath them.
Which Version Are You Actually On
Send us your site address, or your hosting login if you would rather we look ourselves. We will tell you which PHP version each of your environments is running, which version we would move you to and why, which of your plugins or modules would need attention first, and roughly what the work involves. It comes back as a short summary with a recommendation next to each item, and a date for when the version you land on will need revisiting.