How to plan for a runtime reaching end of support before it bites

How to plan for a runtime reaching end of support before it bites

On 10 November 2026 Microsoft shipped the last patches for .NET 8 and .NET 9 and released .NET 11 on the same day, as our news desk reported. Python 3.10 reached end of life on 1 October. PHP 8.2 stops receiving security fixes on 31 December. None of these dates was a surprise: each was published years ahead on the project's own site. What catches businesses out is that nobody in the company owns the question "which of our systems run on something that is about to stop being patched?"

This guide sets out a method for answering it, in the order the work is done. It uses support dates that we read on each project's own page on 11 November 2026, and it says where a page left something out. It does not tell you which language to use. It tells you how to keep whatever you use inside a supported window, and how to make a supplier prove that it does the same.

Why running past the date costs more than the upgrade

End of support does not switch anything off. The software carries on running, which is exactly the problem: from the last release onward, a newly found flaw in the runtime gets no fix from its maintainers. Attackers read the same advisories that defenders do, and a flaw that is disclosed for the newer lines and silently present in the retired one is a documented route in. A runtime also sits under everything else. A web framework, a payment library or an ORM may be perfectly current while the interpreter beneath it has been orphaned for a year.

The cost shows up in other places before it shows up in a breach. Package maintainers drop old runtimes from their test matrices, so new library versions stop installing. Cloud platforms retire managed runtime versions on their own schedule. Customer security questionnaires ask for supported versions, and auditors tend to ask too. A business that waits for the date to arrive finds that the upgrade is now urgent, unplanned and competing with everything else on the same weekend.

Planning has a mundane advantage as well: runtime upgrades are cheapest when done a step at a time. A team that moves from .NET 8 to .NET 10 with a year in hand reads release notes and fixes a handful of warnings. A team that moves from .NET Core 3.1, which left support in December 2022 according to Microsoft's own table, faces several major versions of breaking changes at once.

Step one: find out what runs on which version

The inventory is the hard part, and it is hard because the answer lives in more places than a spreadsheet of servers. Work through five sources, and expect each to disagree with the others.

Start with the code you own. Every repository has a statement of its runtime somewhere: a global.json or target framework in a project file, an .nvmrc or the engines field in package.json, a pyproject.toml or runtime.txt, a composer.json platform requirement, a Maven or Gradle toolchain block. A script that walks your repositories and prints one line per project is a day's work and replaces weeks of asking around. Run it from the build system rather than from a laptop, so that it sees what is actually compiled.

Then look at what is deployed, which is often different. The version a repository declares and the version a production host runs drift apart when a server is built once and never rebuilt. Ask each host or platform what it executes. For servers that is a package query; for serverless functions and platform-as-a-service apps it is a setting in the provider's console that is easy to forget because nobody has touched it since the first deploy.

Container images need their own pass. An image carries two lifetimes: the language runtime and the operating system layer beneath it. A team can update its application on schedule and still ship an image whose base distribution left standard support a year ago. List every base image tag in every Dockerfile, including the ones in CI jobs and in the internal tooling nobody counts as production.

The fourth source is everything you did not write. Commercial software and software-as-a-service products embed runtimes, and some of them make you install and patch that runtime yourself: an on-premises reporting tool that needs a particular Java, a plug-in host that bundles an old Node, a line-of-business application that still wants an old PHP. Your asset register should record, for each of these products, the runtime it requires and who is responsible for patching it. If the answer is "the supplier", that goes in the contract questions later in this guide. If it is "us", it belongs in the calendar.

Finally, check the places where people run code outside the main estate: scheduled jobs on a spare server, a finance team's automation scripts, a marketing site built by an agency three years ago and hosted on its own plan. These are where the oldest runtimes usually hide, because nobody is paged when they stop being patched. Record, for each item, an owner, a runtime and a version, and the date you last confirmed it.

Step two: read each project's own policy correctly

Support wording looks similar across projects and means different things. Three habits prevent most misreadings.

Read the phase names as that project defines them. Node.js has "Active LTS" and "Maintenance" phases; its release repository describes Active LTS as receiving audited new features, fixes and updates, and Maintenance as critical fixes and security updates only (page read 11 November 2026). Python distinguishes "bugfix" from "security" status in a similar way. PHP says it in plainer words: each branch gets two years of active support, then two more years for critical security issues only. A line in a security-only phase is supported, but it will not get the bug fixes your application might be waiting for, and the date to plan against is the end of the final phase, not the start of the quieter one.

Check whether the dates are fixed or forecast. The Python developer guide notes that dates shown in italics are scheduled and can be adjusted. Oracle marks some entries in its Java roadmap with footnotes, and lists Java SE 29 as a future long-term-support release. Treat a forecast as a planning input and re-read the page each quarter.

Distinguish the project's own support from what a vendor offers on top. Ubuntu's standard security maintenance for a long-term release is one thing; its Expanded Security Maintenance, sold through Ubuntu Pro, is a separate service that extends cover for years beyond. Oracle's Premier Support, Extended Support and Sustaining Support are different tiers of one paid programme. Microsoft, by contrast, publishes .NET support as a free policy: its page says long-term-support releases get free support and patches for three years and standard-term-support releases for two. Knowing which kind of promise you are reading tells you whether a later date is free or needs a purchase order.

What the dates look like on 11 November 2026

The table gives the dates we verified for this piece, each read from the project's own page on 11 November 2026. Where a page gives a month rather than a day, the table does the same.

Runtime	Version	End of support	Source
.NET	8	10 November 2026 (out of support)	dotnet.microsoft.com support policy
.NET	9	10 November 2026 (out of support)	dotnet.microsoft.com support policy
.NET	10 (LTS)	14 November 2028	dotnet.microsoft.com support policy
.NET	11 (STS)	14 November 2028	dotnet.microsoft.com support policy
Node.js	20	30 April 2026 (out of support)	nodejs/Release schedule
Node.js	22 (Maintenance LTS)	30 April 2027	nodejs/Release schedule
Node.js	24 (Maintenance LTS)	30 April 2028	nodejs/Release schedule
Node.js	26 (Active LTS)	30 April 2029	nodejs/Release schedule
Python	3.10	1 October 2026 (end of life)	devguide.python.org/versions
Python	3.11	October 2027	devguide.python.org/versions
Python	3.12	October 2028	devguide.python.org/versions
Python	3.13	October 2029	devguide.python.org/versions
PHP	8.2	31 December 2026 (security fixes)	php.net supported versions
PHP	8.3	31 December 2027 (security fixes)	php.net supported versions
PHP	8.4	31 December 2028 (security fixes)	php.net supported versions
Java SE (Oracle)	17	Premier Support September 2026, Extended September 2029	Oracle Java SE support roadmap
Java SE (Oracle)	21	Premier Support September 2028, Extended September 2031	Oracle Java SE support roadmap
Ubuntu	22.04 LTS	Standard maintenance May 2027, ESM May 2032	ubuntu.com release cycle
Ubuntu	24.04 LTS	Standard maintenance May 2029, ESM May 2034	ubuntu.com release cycle

Two observations come straight from the table. First, the .NET and Node.js lines move on a yearly beat, so there is a new decision every autumn whether or not you wanted one. Second, the same calendar year can hold the end of a framework, a language and an operating system layer for one application. A service on PHP 8.2 on Ubuntu 22.04, for instance, faces a runtime date at the end of December 2026 and an operating system date in May 2027, and an upgrade plan that handles one while ignoring the other will have to be redone.

Step three: build a calendar with lead times

Put every inventory row into one calendar keyed by a single date: the day the version leaves the last free phase. Then work backwards.

The lead time is not the length of the upgrade. It is the length of the upgrade plus the queue before it starts. A reasonable rule of thumb, which you should adjust to your own record of delivery, is to measure how long the last runtime upgrade took from decision to production for each class of system, double the longest figure, and add the time to get budget approved. For a small internal service that might be six weeks; for a customer-facing platform with a regulated change process it can be nine months.

Mark three dates against each row. The first is the decision date, by which you will have chosen between the routes in the next section. The second is the cut-over date, the last day you will accept to be running the old version in production. The third is the hard stop, the end-of-support date from the table. The gap between cut-over and hard stop is your slack, and it should never be zero. Anything with less than three months of slack goes on a list reviewed weekly.

Notice also when a date is a trigger rather than a deadline. Node.js 24 moved from Active LTS to Maintenance on 20 October 2026, and Node.js 26 took the Active LTS slot on 28 October, according to the release schedule. Neither is an emergency, but a team choosing a line for the next three years has a reason to look at 26 rather than 24. In the same way, Python 3.15 had its first release on 9 October 2026, according to the developer guide, and reaches end of life in October 2031; a team on 3.11, which has security-only status and an October 2027 end of life, has about eleven months to move and a choice of three newer lines.

Give the calendar a named owner, make it visible to the engineers and to whoever signs purchase orders, and review it every quarter against the project pages, since projects do adjust dates. Where the jump is between a standard-term and a long-term line, write down which you chose and why. Microsoft's table is the clearest example: .NET 11 is a standard-term release and .NET 10 a long-term one, yet both show 14 November 2028 as their end of support on the page we read, so a team picking between them is choosing a feature set, not a longer life. Check that again before you commit, because it is the kind of detail that gets changed.

Step four: upgrade, buy more time, or replace

For each system that will hit its date, there are three routes. Choose deliberately; the default of "do nothing and hope" is a fourth route, and it is the expensive one.

Upgrading is the right answer when the application is still being developed, has tests, and sits on a runtime line that has a supported successor close to it. It is cheap when done early and in single steps. It is the route to prefer for anything customer-facing.

Paying for extended support is a legitimate bridge, and an honest one if you treat it as a bridge. Ubuntu Pro extends cover for long-term releases for years past standard maintenance. Oracle's roadmap lists Extended Support for Java SE 8 until December 2030 and for Java SE 11 until January 2032. The right use of purchased time is a system whose replacement is already funded and scheduled, or one that cannot be moved for a reason you can state, such as a certified medical or industrial configuration. The wrong use is an unfunded hope. Ask what exactly is covered: operating system packages in the main repository only, or the universe repository and language packages too, and for how long the vendor will keep fixing the version you run. Keep the cost of the extension in the same record as the upgrade estimate, so the comparison is made in money.

Replacing is the answer when an application's cost of staying current has outgrown the value it delivers. A runtime end date is a good moment to ask whether the application should exist. Retire it, or move its function to a supplier's product that is someone else's patching problem, and then write down which supplier owns which runtime, because that moves the risk rather than removing it.

Whatever you choose, record it with a date and an owner, and put any exception for running beyond the hard stop through a short risk acceptance signed by someone senior. The effect is that running out of support becomes a decision a person made, not a thing that happened.

Step five: test, roll out and prove it

Runtime upgrades are usually uneventful where there are tests, and miserable where there are not. Before the work starts, check what coverage you have for the paths that matter: payments, login, data export, scheduled jobs. If there are none, write a thin set first. They pay back immediately, and they make the next upgrade cheaper.

Run the new version in the pipeline alongside the old for a few weeks. Most runtimes publish release notes that list removed features and changed defaults; read them rather than discovering them in staging. Pay attention to the second-order dependencies: native extensions, database drivers, build plug-ins and container base images, which tend to break on a version boundary even when the application code does not.

Roll out in rings. Start with an internal or low-risk instance, then a small share of production traffic, then the rest, with a rollback that has been rehearsed rather than assumed. Update the container base image in the same change that moves the runtime, so that the operating system layer is not left behind, and rebuild images on a schedule so that patch releases reach you even when nobody is touching the code.

Close the loop by updating the inventory and the calendar the day the change lands, and by checking from outside that production reports the new version. A runtime upgrade that is merged but never deployed is the most common way for an old version to survive past its date. Keep the evidence, whether a screenshot of the version endpoint, a build log or a package listing, because an auditor or a customer will ask.

What to ask a software supplier or IT service provider

Everything above applies to systems you run. For systems that others run for you, the same questions belong in the contract and in the renewal conversation.

Ask which runtimes and operating system versions the product or service depends on, and request the list in writing, with version numbers. Ask for the supplier's own policy: do they commit to run only on versions inside the project's supported window, and how many months before an end-of-support date will they migrate? A supplier that says "as needed" has no policy. One that says "we move to the next long-term line within six months of its release, and we never run a version in its final six months of support" has one you can hold them to.

Ask who pays when a runtime goes out of support under their watch. For a hosted service the answer should be the supplier, and the contract should say so, including any extended-support purchase. For software you install, the contract should say whether new releases will support the current long-term lines of the runtimes in the table above, and by when. If the product needs an old runtime, ask for the date after which that stops being true.

Ask for notice, and for evidence. A supplier should tell you at least a year before a version you depend on leaves support, and tell you again if it decides to run past the date with a paid extension. Ask for the right to an annual statement of the versions in use, and for the right to terminate without penalty if the supplier lets a system run unsupported for more than a stated number of days after the project's end date.

For managed service providers and agencies, add one more question: who holds the inventory? If the provider runs your servers, it should keep and share the version list, not simply respond when you ask. Check that its patching scope names the runtime and the container layer, not just the operating system. The same applies to agencies that built a site and now host it: find out which PHP or Node.js version it runs on today, and who will move it at the next date.

Finally, put the dates in your own diary instead of trusting that a supplier will remember them. The project pages in the sources below are public and take a few minutes to read each quarter, which is the cheapest control in this guide.

Sources

• Microsoft .NET and .NET Core support policy, read 11 November 2026
• Node.js Release Working Group schedule (schedule.json), read 11 November 2026
• Node.js Release Working Group README, release phases, read 11 November 2026
• Python Developer's Guide, status of Python versions, read 11 November 2026
• PHP supported versions, read 11 November 2026
• Oracle Java SE support roadmap, updated 20 October 2026, read 11 November 2026
• Ubuntu release cycle, read 11 November 2026
• Our report: .NET 8 and 9 reach end of support on 10 November 2026, 11 November 2026