Skip to content
WinBookUnofficial

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

Verified 2 min read

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

Tested onStandard / Datacenter · Build 26100.33650 · x64
E1
Build
26100.33650
Edition
Standard / Datacenter
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Method

The short answer

Section titled “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 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

Section titled “Inventory first”

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

Terminal window
# 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

Section titled “Check EOL”
  1. Open 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

Section titled “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

Section titled “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

Section titled “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.

Runbook fields

Section titled “Runbook fields”
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

Section titled “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 and the official matrix before acting.

Sources