“It still works” does not prepare you for the next emergency
A business application has been running for years. Users know it, jobs complete and nobody wants to start a migration. Then a significant vulnerability appears. The team discovers that the branch no longer receives fixes from the project and the provider requires a major upgrade first. A security issue becomes an application project precisely when there is least time for testing.
Tracking software end of life lets you prepare that decision before an incident. You can reserve a maintenance window, identify incompatibilities, consult your supplier and fund the work. The value lies in choosing when to make the transition, with the right people and information.
Distinguish active support, security support and end of life
Vendor policies often distinguish several periods. A branch may still receive security fixes after routine bug fixes end. Beyond that point, fixes may depend on a distribution or a specific contract. Support status therefore belongs to the exact product, its branch and the provider that actually maintains it.
PHP illustrates the distinction. As checked on 30 October 2026, the project lists PHP 8.1 as having reached end of life on 31 December 2025. PHP 8.2 remains under security support until 31 December 2026. A team using 8.2 therefore needs a migration plan alongside its handling of current vulnerabilities.
Sources: PHP supported-version schedule, PHP end-of-life branches
Connect each deadline to the services that depend on it
A date in a spreadsheet becomes useful when it leads to a concrete portfolio: applications, servers, container images, accountable teams and suppliers. Add business criticality, blocking dependencies and the last observation date. You can then see whether one support deadline affects a minor internal tool or several essential services.
A component supplied by a maintained distribution may receive backported fixes. An extended-support contract may also change the plan. These situations need evidence from a vendor advisory or a verified contractual scope. A “supported” label without provenance provides too little information for a maintenance decision.
Build a plan teams can act on
For each branch to replace, assign a target and an owner. Identify applications to test, extensions to check and providers to involve. Separate straightforward upgrades from migrations that require application changes. Six-, twelve- and twenty-four-month horizons can structure planning; adapt them to your change cycles and commitments.
When a transition slips, retain an explicit decision: exposure-reduction measures, the dependency to resolve, an owner and a review date. This keeps the intended exit visible. NIST likewise treats updates and upgrades as preventive maintenance to organise with business owners.
Sources: NIST SP 800-40 Rev. 4, planning maintenance and patching
Track the versions actually deployed
After migration, reconcile new versions with inventories and affected applications. Check deployment images and recovery environments too: an old base can reintroduce the retired branch during the next rebuild. Tracking retains outstanding occurrences and their decisions until they are resolved.
Put CyberLifeCycle in charge of deadlines and follow-up
You provide inventories or SBOMs. CyberLifeCycle tracks support lifecycles, assesses vendor-specific situations and connects deadlines to your known estate. You receive the alerts, priorities, metrics and reports needed to manage the work. Your teams get a clear plan for preparing and carrying out transitions, while your organisation retains budget and risk decisions.
Sources consulted
- PHP supported-version scheduleAccessed on 30 October 2026.
- PHP end-of-life branchesAccessed on 30 October 2026.
- NIST SP 800-40 Rev. 4, planning maintenance and patchingAccessed on 30 October 2026.