When a support window closes, you have four paths: upgrade, use extended support if the project or a third party offers it, isolate the system with compensating controls, or retire it. Choose by weighing exposure, migration effort and how long you need to keep the system, and write the decision down with an end date.
Does extended support exist for your stack?
Several projects mention it in their own policies. The Spring Boot page says commercial support, with an extended support period, is also available. The Node.js releases page notes that commercial support for versions past the Maintenance LTS phase is available through partners of the OpenJS Ecosystem Sustainability Program. Others, like Rails, say that once a series is unsupported, bugs and security issues are your own responsibility, and that backports may appear in git without a guaranteed release.
Check what is actually on offer, from whom and for how long, on the project page. Do not assume it exists.
The four paths
| Path | Best when | Main risk |
|---|---|---|
| Upgrade | Migration is moderate and the system has a long life | Effort and regression risk |
| Extended support | You need time, and an offer covers your version and the components you use | Cost, finite duration, scope gaps |
| Isolate | System is stable, internal and low value, or migration is blocked | Controls fail or erode |
| Retire | Little use remains | Business dependencies you did not map |
Questions that decide it
- How long must the system live? If it lives two more years, upgrade. If it is shutting down in three months, isolation may be enough.
- How exposed is it? An internet facing service handling sensitive data leans toward upgrade. An internal batch job with no external input can sometimes wait.
- Is the vulnerable code reachable? Reachability analysis tells you whether known flaws apply to your code.
- What does extended support cover? Read the scope. Some cover the core runtime but not every library you use.
- What blocks the upgrade? A single abandoned dependency may be cheaper to replace than to carry for years.
- What does it cost to wait? Include audits, customer questionnaires and incident response in your estimate, not only licence cost.
Compensating controls for isolation
If you isolate, document specific controls: network segmentation, no direct internet exposure, a web application firewall rule in front, tighter authentication, extra logging and alerting, and a restricted set of administrators. Test them. Isolation that has never been tested is an assumption.
Write the exception properly
An exception record should contain the system, the component and version, the end of support date, the reason for the exception, the compensating controls, the owner, the approver, the expiry date and the plan to exit. Review it monthly and close it when the upgrade ships. Auditors and customers who ask about end of life software will want to see exactly this.
Do not use extended support as a permanent state
Extended periods end. Treat them as a bridge that buys time for a funded migration, with a milestone date tied to the support end. If nothing is moving in the first quarter, escalate.
Quick check
Is isolating an unsupported system the same as fixing it?
No. It lowers exposure but leaves known flaws in place. It needs tested controls and an expiry date.
Can I rely on a security scanner to tell me an unsupported version is safe?
No. An unsupported version may have no advisories because nobody is reviewing it. Absence of findings is not proof of safety.
Safeguard inventories your components, flags end of support versions, and records evidence for exceptions. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
