End of Life Software: A Yearly Checklist for Your Tech Stack

Most businesses find out a piece of their tech stack has reached end of life the way you find out your car insurance lapsed: after something goes wrong. An end of life software checklist run once a year, on a date you actually keep, turns that into a non-event. You find out a version is aging out of support months before it matters, while there is still time to plan the upgrade on your own schedule rather than someone else's.

This is written for the owner or manager who is not the one writing code, but who is responsible for the system staying secure and online. The check below does not require reading a line of code. It requires making a short list, finding six or seven version numbers, and comparing them against public support dates. Most businesses can do the whole thing in under an hour once they know where to look.

Why this needs to be a yearly habit, not a one time fix

Every piece of software in a modern web application, the programming language, the framework built on top of it, the database, the server operating system, the runtime for background jobs, and the third party APIs it talks to, has its own support clock. Each one runs on a different schedule set by a different organization, and none of them send you a personal reminder when the clock runs out.

A system built in 2023 was, at the time, running entirely supported software. By 2026, without a single line of code changing, several of those components may have quietly crossed into unsupported territory. Nothing breaks the day support ends. The application keeps running exactly as before. What changes is that any security flaw found in that version from that date forward never gets patched, by anyone, for as long as you keep running it. That gap grows every month you do not look at it, which is exactly why a one time check at launch is not enough. You need to look again every year.

What your end of life software checklist should cover

Run through these for your main production system. For each one, you want a current version number and the date that version stops receiving security fixes.

Component	Where to check	What tends to get missed
Programming language (PHP, Node.js, Python, Ruby, etc.)	Your developer, hosting panel, or server admin can report this in minutes	Security-only support windows that end years before most people expect
Web framework (Symfony, Laravel, Django, Rails, Next.js, etc.)	Framework's own release and support page	Framework support often ends earlier than the language it runs on
Database (MySQL, PostgreSQL, MongoDB, etc.)	Hosting provider's database dashboard, or SELECT version() run by your developer	Managed hosting sometimes auto-upgrades minor versions but not major ones
Server operating system	Hosting provider or server admin panel	Ubuntu LTS, Windows Server, and similar all have fixed, published end dates
Background job runtime (Node.js workers, Python workers, cron-based jobs)	Same place as your main language, but check separately, since workers sometimes run an older pinned version	A runtime quietly left on an old pinned version while the main app was upgraded
Third party APIs you depend on (payment processors, shipping, auth providers)	The vendor's developer documentation or changelog	API version sunset dates that arrive with far less warning than language or framework EOL

Six categories, six lookups. None of them require touching your actual codebase. If you have a developer or agency on retainer, this list is also a fair, specific set of questions to send them: "What version are we on for each of these, and when does that version's support end?"

Where to find the real dates

Framework and language maintainers publish their support timelines directly, and those pages are the only source worth trusting over a guess or a secondhand summary. endoflife.date tracks support windows for most major languages, frameworks, databases, and operating systems in one place and is a fast way to check several components at once before confirming against the vendor's own page. We've covered one specific and commonly missed deadline in detail, the end of PHP 8.2 support, and another on a framework support window that was extended further than most guides still report, which is a good example of why checking the primary source each year, rather than relying on last year's notes, actually matters.

Third party API sunset dates are different. They usually show up in a developer changelog or an email to registered API users, not in a central tracker, so that line item needs its own quick check with each vendor you depend on, at least for anything processing payments, handling authentication, or touching customer data.

Building the one page version

Once you have the six lookups done, put them on a single page: component, current version, end of life date, and days remaining. Sort by days remaining, soonest first. That sort order is the whole point. It turns six scattered facts into one obvious answer to "what do we need to deal with first."

Keep that page from one year to the next rather than starting over. The version numbers change, but the format does not need to, and a system that tracks its own history makes it easy to see which components keep sliding toward their deadline without ever getting addressed.

What to do with what you find

A component with more than a year of support left needs nothing beyond a note to check again next year. Something inside twelve months needs a line item on next quarter's planning, even if the actual upgrade work happens later. Anything already past its end date, or inside the next few months, needs a decision now: schedule the upgrade, or look into paid extended support as a bridge while the upgrade gets planned properly.

That last option exists for a reason. Sometimes the honest timeline for an upgrade runs longer than the time left on a support window, and a temporary, paid bridge from the vendor or a specialist provider is a reasonable way to avoid running an unpatched system while the real fix gets built. It is a bridge, though, not a destination. Treat it as a deadline extension, not a solution.

Where this fits into the bigger picture

An end of life software checklist is a maintenance habit, not a strategy document, but it tends to surface the same underlying question every time: is this system's technology stack a reasonable choice for where the business is headed, or is it quietly accumulating version debt that will eventually force a larger, less controlled decision? If your annual check keeps turning up multiple components near or past their support window, that pattern itself is worth a conversation with whoever owns your tech stack strategy, separate from the individual upgrades.

For the upgrades themselves, once you know what needs attention, a legacy system review can confirm what a safe upgrade path actually looks like for your specific application before you commit to a timeline.

Pick a date, put it on the calendar now, and run through the six lookups above once a year. If you would rather have someone else run this check and tell you plainly what needs attention and by when, reach out at hello@wolf-tech.io or visit wolf-tech.io. The businesses that never get caught off guard by an end of life deadline are, almost without exception, the ones who looked before they had to.