The budget template arrives the week after Labor Day, and your website is one row on it. Last year you entered roughly what you entered the year before, because nothing had visibly changed and nobody asked you to defend the number. This year that number is wrong, and it is wrong for reasons that have nothing to do with anything your association decided.
Four dates between now and the end of December were set by Pantheon, Microsoft, the Drupal project and the PHP development team. None of them consulted you. All four land inside the window you are budgeting for right now, and between them they will shape more of next year's website spend than any strategy conversation your board is going to have.
What Is Actually on the Calendar
Four dates, in the order they arrive. Each is a published lifecycle date from the organization that controls the software, not an industry projection or a vendor's sales timeline.
- September 30, 2026, Pantheon removes PHP 5.6 through 8.0 from its platform. Sites still running a removed version are upgraded automatically to the oldest version still available, whether or not the code is ready.
- November 10, 2026, Microsoft ends support for .NET 8 and .NET 9. This is the one most likely to be misapplied to you; more on that below.
- December 9, 2026, Drupal 10 reaches end of life. Drupal 12 and Drupal 11.5 are both released the week of December 7, so the deadline and the upgrade target land in the same seven days.
- December 31, 2026, PHP 8.2 loses security support. On the same day, PHP 8.4 drops out of active support into security-only maintenance.
None of these are predictions. Pantheon, Microsoft, the Drupal project and php.net all publish these dates themselves, and they have been on the calendar long enough that nobody involved is going to be surprised into moving them. That is what makes them budgetable. You are not estimating the odds of something happening; you are scheduling work against a date somebody else already committed to.
Most of Them Are Not Your Problem
The point of listing all four is not that you owe money against all four. It is that you can find out in about twenty minutes which ones apply, and the answer is usually one or two. Working through them in order:
The Pantheon date applies only if you host on Pantheon. It is also the easiest to check, your PHP version is on the dashboard, and if it starts with 8.1 or higher this date is somebody else's problem. If it starts with 7, put the compatibility work in the current fiscal year rather than next, because the deadline is three weeks out.
The Drupal date applies only if you are on Drupal 10. Drupal 11 sites are already past it. What the date actually costs you depends on how much contributed code you run and how much of it has a Drupal 12-compatible release, which is a question you can answer now rather than in November.
The PHP date applies to almost everybody, and usually costs nothing. Most managed hosts move you between PHP minor versions as a routine platform operation. The budget line is not the upgrade; it is the compatibility testing on whatever custom code and premium plugins you run, and the possibility that one of them turns out to be abandoned.
The .NET date probably does not apply to you at all. This is the one worth being careful about, because it is the one a vendor is most likely to put in front of you. Sitecore XP and Sitefinity in their current shipping versions run on .NET Framework 4.8, which is a component of Windows and carries no end-of-support date of its own. If somebody has quoted you a re-platform against the November date, ask which runtime your installation actually targets before you agree that the deadline is yours.
The Line Items That Are Not Deadlines
Dates are the easy part of a budget because they argue for themselves. The items that get cut first are the ones without a date attached, and those are usually the ones that turn into an emergency eighteen months later. Four worth naming explicitly:
- Certificate automation. Maximum TLS certificate lifetimes stepped down to 200 days in March 2026 and go to 100 days in March 2027, on a schedule the CA/Browser Forum has published through 2029. If anyone at your organization still renews a certificate by hand, that becomes three or four interruptions a year instead of one, and eventually it becomes an outage.
- Accessibility remediation. If your association receives HHS financial assistance and has fifteen or more employees, WCAG 2.1 Level AA is a requirement on May 11, 2027. Remediation is slow work with a fixed deadline, which is the worst combination to discover late.
- Integration maintenance. Every connection between your website and your AMS, payment processor or event platform has an ongoing cost that nobody quoted you when it was built. It shows up as somebody's afternoon, repeatedly, until it shows up as a broken renewal flow.
- Premium licenses you have stopped thinking about. Plugin and module subscriptions renew quietly. The ones worth auditing are not the expensive ones; they are the ones nobody can explain the purpose of, which are often also the ones nobody has updated.
Why the Deadlines Cluster in December
It is not coincidence and it is not conspiracy. The PHP project ships a release every November and supports it for four years, which puts every end-of-life date at the end of December. Drupal times its major releases against the Symfony release cycle, which lands in the same part of the year. Microsoft's .NET releases land in November. Everybody is on a similar annual rhythm, so the dates pile up in the same eight weeks.
The practical consequence is that November and December are the worst months to discover any of this. Development capacity is scarce in that window, your own staff are running the year-end appeal and the annual meeting, and the people who could help you are working through the same list for everyone else. Work scheduled in September costs what it costs. The same work in December costs whatever the last available developer charges.
Presenting This to a Board
Boards are reasonable about infrastructure spending when it is framed as a date rather than as a preference, and unreasonable about it when it arrives as a general plea for more technology money. The version that works is short: here is the date, here is who set it, here is what happens if we are not ready, here is what being ready costs. Three of the four items above fit that shape exactly, because somebody else set the date and you are simply reporting it.
The item that does not fit that shape is the maintenance line. There is no date on it, so it has to be argued on its own terms, that the alternative to routine maintenance is not zero cost but deferred cost, paid later at emergency rates. That argument is easier to make in the same memo as four real deadlines than in a memo of its own.
If Somebody Already Handles This
If you are on a maintenance agreement that covers platform upgrades, most of this belongs to your partner rather than to your budget, and the useful exercise is confirming that in writing rather than assuming it. Ask specifically whether major version upgrades are in scope or quoted separately, because that is the line where most agreements actually sit, and it is the difference between a December that is handled and a December that is an invoice.
Find Out Which Ones Are Yours
Tell us where your site is hosted and what it runs on, or give us read access and we will find out ourselves. We will come back with which of the four dates apply to your association and which do not, what the compatibility work looks like for the ones that do, and which items on your current maintenance agreement already cover it. If the honest answer is that none of the four are yours, that is a short conversation and a useful thing to be able to tell your finance director in September rather than in December.