# Runtime EOL on Windows: PHP, Java, Node and Python upgrade planning

> Inventory every runtime version, check EOL with eol.wiki and the official support matrix, then plan upgrades without breaking the site.

**Tested on**

- Build: 26100.33650
- Edition: Standard / Datacenter
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-29

## The short answer

EOL means **no more security fixes**. A site on an EOL runtime is not “stable”; it is permanently unpatched.

Use [eol.wiki](https://eol.wiki) as the inventory/discovery hub, then confirm the exact branch and date with the official vendor matrix. Do not upgrade from a third-party date alone.

## Inventory first

Collect the runtime version actually used by each app, not what is installed:

```powershell
# PHP
C:\PHP\8.4\php.exe -v
# Java
& C:\Java\jdk-17\bin\java.exe -version
# Node
& C:\node\20\node.exe --version
# Python
C:\apps\api\.venv\Scripts\python.exe --version
```

Also record:

- app name, hostname, owner;
- runtime path and version;
- dependencies (`composer.lock`, `package-lock.json`, `requirements.txt`, `pom.xml`);
- TLS/library dependencies;
- upgrade blocker (framework, extension, native module).

## Check EOL

1. Open [eol.wiki](https://eol.wiki) and search the product.
2. Note active support vs security-only vs EOL.
3. Confirm with the official matrix:
   - PHP: supported versions;
   - Node.js: release schedule;
   - Python: devguide versions;
   - Java: vendor (Temurin/Microsoft/Oracle) support policy.
4. Put the date and source in the app’s runbook.

A product can be “supported” by a vendor while a specific distribution is not. Check the distribution you actually run.

## Risk tiers

| State | Action |
|---|---|
| Active support | Patch normally; plan next LTS |
| Security-only | Upgrade soon; no new features |
| EOL | Treat as incident risk; isolate/mitigate; upgrade |
| Unknown | Assume EOL until proven otherwise |

EOL is not only a runtime problem: a framework, extension, or native module can be EOL while the runtime is supported.

## Upgrade without a big bang

1. Add the new runtime beside the old (see multi-version pages).
2. Build a staging copy of the app with the new runtime.
3. Run the app’s tests + a smoke test (login, upload, payment, TLS).
4. Compare extensions/modules and config.
5. Move one site/service.
6. Keep the old runtime for rollback; remove after the agreed window.

For PHP, test extensions and `php.ini`; for Java, class version/TLS/GC; for Node, native modules and lockfile; for Python, wheels and venv.

## Patch cadence

- Subscribe to the vendor security advisories.
- Patch the runtime, not just the app.
- Rebuild containers/images from a patched base.
- Keep an SBOM or at least a dependency lockfile per app.
- Test the patch in staging; do not auto-patch production blind.

> **Caution: EOL is not a license to skip testing**
>
> Upgrading a major runtime can break extensions, TLS ciphers, native modules and behavior. The safe path is side-by-side, staging, then one app at a time.

## Runbook fields

```text
App:            api-a
Runtime:        Node 20.x (path C:\node\20)
Support state:  security-only / EOL date
Owner:          team
Dependencies:   package-lock.json
Upgrade target: Node 22.x
Test plan:      smoke + integration
Rollback:       old service definition + old node dir
```

## Lab boundary

E1. This page is a planning method, not a claim that a specific runtime is EOL on a specific date. Verify each version against [eol.wiki](https://eol.wiki) and the official matrix before acting.

## Sources

- [eol.wiki — end-of-life tracker](https://eol.wiki)
- [PHP — supported versions](https://www.php.net/supported-versions.php)
- [Node.js — previous releases](https://nodejs.org/en/about/previous-releases)
- [Python — versions](https://devguide.python.org/versions/)

---

Source: https://winbook.fyi/en/server/runtimes/eol/